map vs. list-comprehension
no.spam at thanks.com
Thu Jun 30 16:49:47 CEST 2005
"Björn Lindström" <bkhl at stp.ling.uu.se> wrote in message
news:87irzxtqsp.fsf at lucien.dreaming...
> "F. Petitjean" <littlejohn.75 at news.free.fr> 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:
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. 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.
Also, I don't necessarily think list comprehensions are necessarily easier
to read. I don't use them all that much to be honest.
IMHO I'm not particularly happy with the way Python is going language wise.
I mean, I don't think I'll ever use decorators, for example. Personally, in
terms of language features and capabilities I think the language is fine.
Not much (if anything needs to be added).
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
I would love it if modules like PyOpenGL, PyOSG (Open Scene Graph), PyQt, a
graph library etc, were all part of the standard python library, and that
worked out of the box on all major platforms -Windows, Unix, Linux, Mac. All
these modules which are C/C++ based are all at different versions and at
different stages, requiring different versions of Python working on
different operating systems.
It's not as transparent as it should be. For example, why aren't PIL,
Numeric and a host of other fairly mainstream Python modules not part of the
standard library? Compare that with the huge SDK that comes with Java.
Then there is always issues of performance, better standard development
tools, better documentation. There are lots of things to do, to make the
Python programmers life better without touching the actual features of the
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.
I don't program in Python for it's own sake. I program in Python because it
lets me get my job done quicker and it saves me time. The proposed removals
are going to waste my time. Why? Because my team and myself are going to
have to go through all our code and change stuff like maps to ugly looking
list comprehensions or whatever when Python 3000 comes out. Sure some of you
will say you don't have to update, just stick with Python 2.3/2.4 or
whatever. That is fine in theory, but in practice I'm going to have to use
some third party module which will require Python 3000 (this happened to me
recently with a module which had a serious bug with the Python 2.3 version,
but worked with the Python 2.4 version - I had to upgrade every single third
party module I was using - I was lucky the ones I was using had 2.4
versions, but there are still a lot of modules out there that don't).
Sorry for the OT long rant.
More information about the Python-list