[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/)