Re: map vs. list-comprehension

On Fri, 1 Jul 2005, Mike P. wrote:

"Björn Lindström" <bkhl@xxxxxxxxxxxxxx> wrote in message
news:87irzxtqsp.fsf@xxxxxxxxxxxxxxxxxx

"F. Petitjean" <littlejohn.75@xxxxxxxxxxxx> writes:

res = [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]

Hoping that zip will not be deprecated. 

Nobody has suggested that. The ones that are planned to be removed are
lambda, reduce, filter and map. Here's GvR's blog posting that explains
the reasons:

http://www.artima.com/weblogs/viewpost.jsp?thread=98196

That really sucks, I wasn't aware of these plans. Ok, I don't use reduce much, but I use lambda, map and filter all the time. These are some of the features of Python that I love the best. I can get some pretty compact and easy to read code with them. 

Same here.

And no, I'm not a Lisp programmer (never programmed in Lisp). My background being largely C++, I discovered lambda, apply, map and filter in Python, although I had seen similar stuff in other functional languages like Miranda and Haskell. 

Same here too!

Also, I don't necessarily think list comprehensions are necessarily easier to read. I don't use them all that much to be honest. 

And here!

However, i also felt that way about generator functions - until the other day, when i realised one was the best solution to a problem i had. That made me realise that the same was probably true of list comprehensions.

That said, i do still think that map etc are better than list comps, because they involve less language. Once you have the idea of a function and a list, you can understand map as a function that operates on lists; list comprehensions provide a whole new splodge of arbitrary syntax to learn. I guess you could say the same about lambda, which is really an essential part of the whole map way of life, but i don't think that's fair - list comprehensions are a structure for doing just one thing, whereas lambda is a construct of enormous general power.

I'd be happy for the lambda syntax to be tidied up, though - perhaps it could be merged with def? Like:

def name(args): # traditional form
	some_statements
	return some_expression

def name(args): return some_expression # one-line form

def name(args): some_statements; return some_expression

def name(args) = some_expression # shorthand one-line form

Then an anonymous form, which is an expression rather than a statement:

def (args):
	some_statements
	return some_expression

def (args): return some_expression

def (args) = some_expression

The latter form is like a lambda; i'm not sure how the former forms would work inside enclosing expressions; i think it would look pretty sick:

surfaceAreaToVolumeRatios = map(def (radius):
	area = 4.0 * math.pi * (radius ** 2)
	volume = 4.0 / 3.0 * math.pi * (radius ** 2)
	return area / volume
, radii)

It works, but i admit it's not hugely pretty. But then, i would't advise anyone to actually do this; it's just there for completeness.

You might also want to allow:

def name(args) = some_statements; some_expression

And the anonymous counterpart. But i'm not sure about that one. Multiple expressions inside lambdas would sometimes be useful, but you can get those with the shorthand form.

I think at this stage the Python community and Python programmers would be better served by building a better, more standardised, cross platform, more robust, better documented, and more extensive standard library. I would be happy to contribute in this regard, rather than having debates about the addition and removal of language features which don't improve my productivity. 

Same here.

Sorry, I've probably gone way off topic, and probably stirred up political issues which I'm not aware of, but, man when I hear stuff like the proposed removal of reduce, lambda, filter and map, all I see ahead of me is a waste of time as a programmer. 

Same here.

Sorry for the OT long rant.

Yeah, that was really off-topic for a python newsgroup. You didn't even mention regional accents once!

tom

--
How did i get here?

Relevant Pages