Velocity Reviews > map vs. list-comprehension

# map vs. list-comprehension

Mandus
Guest
Posts: n/a

 06-29-2005
Hi there,

inspired by a recent thread where the end of reduce/map/lambda in Python was
discussed, I looked over some of my maps, and tried to convert them to
list-comprehensions.

This one I am not sure how to conver:

Given three tuples of length n, b,i and d, I now do:

map(lambda bb,ii,dd: bb+ii*dd,b,i,d)

which gives a list of length n.

Anyone have an idea what the equivalent list comprehension will be?

take care,
--
Mandus - the only mandus around.

F. Petitjean
Guest
Posts: n/a

 06-29-2005
Le Wed, 29 Jun 2005 09:46:15 +0000 (UTC), Mandus a écrit :
> Hi there,
>
> inspired by a recent thread where the end of reduce/map/lambda in Python was
> discussed, I looked over some of my maps, and tried to convert them to
> list-comprehensions.
>
> This one I am not sure how to conver:
>
> Given three tuples of length n, b,i and d, I now do:
>
> map(lambda bb,ii,dd: bb+ii*dd,b,i,d)
>
> which gives a list of length n.

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

Hoping that zip will not be deprecated.

=?utf-8?q?Bj=C3=B6rn_Lindstr=C3=B6m?=
Guest
Posts: n/a

 06-29-2005
"F. Petitjean" <(E-Mail Removed)> 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:

--
BjÃ¶rn LindstrÃ¶m <(E-Mail Removed)>
Student of computational linguistics, Uppsala University, Sweden

Mandus
Guest
Posts: n/a

 06-29-2005
29 Jun 2005 10:04:40 GMT skrev F. Petitjean:
> Le Wed, 29 Jun 2005 09:46:15 +0000 (UTC), Mandus a écrit :
>> Hi there,
>>
>> inspired by a recent thread where the end of reduce/map/lambda in Python was
>> discussed, I looked over some of my maps, and tried to convert them to
>> list-comprehensions.
>>
>> This one I am not sure how to conver:
>>
>> Given three tuples of length n, b,i and d, I now do:
>>
>> map(lambda bb,ii,dd: bb+ii*dd,b,i,d)
>>
>> which gives a list of length n.

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

aha - thanks! I wasn't aware of zip. Guess I have to put python in a
nutshell on my nightstand (again)

seem to be a tad slower than the map, but nothing serious. Guess it's
the extra zip.

>
> Hoping that zip will not be deprecated.

hopefully not...

--
Mandus - the only mandus around.

Carl Banks
Guest
Posts: n/a

 06-29-2005
F. Petitjean wrote:
> Le Wed, 29 Jun 2005 09:46:15 +0000 (UTC), Mandus a écrit :
> > Hi there,
> >
> > inspired by a recent thread where the end of reduce/map/lambda in Python was
> > discussed, I looked over some of my maps, and tried to convert them to
> > list-comprehensions.
> >
> > This one I am not sure how to conver:
> >
> > Given three tuples of length n, b,i and d, I now do:
> >
> > map(lambda bb,ii,dd: bb+ii*dd,b,i,d)
> >
> > which gives a list of length n.

>
> res = [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]
>
> Hoping that zip will not be deprecated.

Notice that zip doesn't do any functional stuff--it merely manipulates
data structures--so it ought not to be lumped in with map, filter, and
reduce.

Fear not, people: just as the BDFL does not indiscriminately add
features, also he does not indiscriminately remove them. zip, though
it feels a little exotic, is very useful and serves a purpose that no
language feature serves(*), so rest assured it's not going to
disappear.

(*) Excepting izip, of course, which is more useful than zip and
probably should also be a builtin.

--
Carl Banks

George Sakkis
Guest
Posts: n/a

 06-29-2005
"Carl Banks" <(E-Mail Removed)> wrote in message

> Fear not, people: just as the BDFL does not indiscriminately add
> features, also he does not indiscriminately remove them. zip, though
> it feels a little exotic, is very useful and serves a purpose that no
> language feature serves(*), so rest assured it's not going to
> disappear.
>
> (*) Excepting izip, of course, which is more useful than zip and
> probably should also be a builtin.

One of the envisioned changes in Python 3000
(http://www.python.org/peps/pep-3000.html) is to return iterators
instead of lists in several contexts (e.g. dict.keys(), dict.items()),
so perhaps zip will stand for what itertools.izip is today.

George

Scott David Daniels
Guest
Posts: n/a

 06-29-2005
Mandus wrote:
> 29 Jun 2005 10:04:40 GMT skrev F. Petitjean:
>
>>Le Wed, 29 Jun 2005 09:46:15 +0000 (UTC), Mandus a écrit :
>>
>>res = [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]

>
> seem to be a tad slower than the map, but nothing serious. Guess it's
> the extra zip.

You could try timing it using itertools.izip rather than zip.

--Scott David Daniels
http://www.velocityreviews.com/forums/(E-Mail Removed)

Terry Reedy
Guest
Posts: n/a

 06-29-2005

"F. Petitjean" <(E-Mail Removed)> wrote in message
news:42c27238\$0\$26269\$(E-Mail Removed)...
>res = [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]

> Hoping that zip will not be deprecated.

Cease worrying. Zip was added to replace the zipping behavior of map and
the idiom map(None, a, b, ...). It simultaneously altered the behavior for
unequal length inputs to stop with the shortest instead of padding to the
longest.

tjr

Mandus
Guest
Posts: n/a

 06-30-2005
Wed, 29 Jun 2005 08:33:58 -0700 skrev Scott David Daniels:
> Mandus wrote:
>> 29 Jun 2005 10:04:40 GMT skrev F. Petitjean:
>>
>>>Le Wed, 29 Jun 2005 09:46:15 +0000 (UTC), Mandus a écrit :
>>>
>>>res = [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]

>>
>> seem to be a tad slower than the map, but nothing serious. Guess it's
>> the extra zip.

> You could try timing it using itertools.izip rather than zip.

jepp - faster, but still slower than the map.

1000000 iterations:
zip+list-comprehension: 8.1s
izip+list-comprehension: 7.5s
map: 7.0s

--
Mandus - the only mandus around.

Mike P.
Guest
Posts: n/a

 06-30-2005

"Björn Lindström" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "F. Petitjean" <(E-Mail Removed)> 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
productivity.

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
language.

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.

Mike