[Python-Dev] map() methods (was: Re: [Patches] Review (was: Please review before applying))

Guido van Rossum guido@python.org
Mon, 24 Apr 2000 09:03:56 -0400


[Moving this to python-dev because it's a musing 

> > The main point is to avoid string.*.
> 
> Agreed. Also replacing map by a loop might not even be slower.
> What remains as open question: Several modules need access
> to string constants, and they therefore still have to import
> string.
> Is there an elegant solution to this?

import string

> That's why i asked for some way to access "".__class__ or
> whatever, to get into some common namespace with the constants.

I dunno.  However, I've noticed that in many situations where map() could
be used with a string.* function (*if* you care about the speed-up and
you don't care about the readability issue), there's no equivalent
that uses the new string methods.  This stems from the fact that map()
wants a function, not a method.

Python 3000 solves this partly, assuming types and classes are unified
there.

Where in 1.5 we wrote

  map(string.strip, L)

in Python 3K we will be able to write

  map("".__class__.strip, L)

However, this is *still* not as powerful as

  map(lambda s: s.strip(), L)

because the former requires that all items in L are in fact strings,
while the latter works for anything with a strip() method (in
particular Unicode objects and UserString instances).

Maybe Python 3000 should recognize map(lambda) and generate more
efficient code for it...

--Guido van Rossum (home page: http://www.python.org/~guido/)