On Fri, 1 Jul 2005, Mike P. wrote:
"Björn Lindström" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
"F. Petitjean" <[EMAIL PROTECTED]> 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?
--
http://mail.python.org/mailman/listinfo/python-list
