[Python-3000] map() Returns Iterator
Kurt B. Kaiser
kbk at shore.net
Tue Aug 7 07:02:12 CEST 2007
"Guido van Rossum" <guido at python.org> writes:
>> However, IMHO eliminating the strict versions of map() and filter() in
>> favor of the lazy versions from itertools kicks the degree of
>> sophistication necessary to understand these functions up a notch (or
> I wonder how bad this is given that range() and dict.keys() and
> friends will also stop returning lists?
Don't know. It's straightforward for us, but we use it every day. I'm
with you on the dict methods; I just view map() and filter() differently.
I'll get used to it. Let's see what we hear from the high schools in a
> I don't think you ever saw any of my Py3k presentations (the slides of
> the latest one at here:
Yes, I had dug them out. This link is the best so far, thanks!
> I've always made a point of suggesting that we're switching to
> returning iterators instead of lists from as many APIs as makes sense
> (I stop at str.split() though, as I can't think of a use case where
> the list would be so big as to be bothersome).
It's not your father's snake :-)
> I think you're overreacting due to your experience with conversion of
> existing code. I expect that new use cases where a list is needed will
> generally be written using list comprehensions in Py3k-specific
> tutorials, and generator expressions for situations where a list isn't
> needed (as a slightly more advanced feature). Then map() and filter()
> can be shown as more advanced optimizations of certain end cases.
I think you are correct.
> (Aside: Please skip the p3yk branch and use the py3k-struni branch --
> it's the way of the future.)
I was working on IDLE in p3yk because I expect a whole new set of
failures when I jump it to py3k-struni. Maybe I'm wrong about that.
It's mostly working now; I've been editing/testing Python 3000 with it
for several weeks.
> I tend to do manual conversion of the stdlib because it's on the
> bleeding edge. At times I've regretted this, and gone back and run a
> particular transform over some of the code. I rarely use the full set
> of transforms on a whole subtree, although others sometimes do that.
> Do note the options that help convert doctests and deal with print()
> already being a function.
I'll give it a shot. It probably would have helped me get IDLE going
sooner; I had to trace the interpreter failure through IDLE into
code.py. The biggest problem was those four map(print...) statements
which I'll wager you wrote back in your salad days :-)
I have my answer, thanks! See you in py3k-struni!
>> It's used only fifteen times in 2.6 Lib/ and four of those are
>> izip(). Eight are assignments, mostly to build dicts.
> I don't understand. What's an "assignment" to build a dict? Do you
> mean something like
> dict(zip(keys, values))
> ? That's an ideal use case for an iterator.
Yup, typical lines are
Lib/filecmp.py: a = dict(izip(imap(os.path.normcase, self.left_list), self.left_list))
Lib/mailbox.py: self._toc = dict(enumerate(zip(starts, stops)))
More information about the Python-3000