[Python-3000] map() Returns Iterator

[Kurt B. Kaiser]

"Guido van Rossum" <guido at python.org> writes:

> [...pushback...]
>
>> 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
>> three).
>
> 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
few years.

> I don't think you ever saw any of my Py3k presentations (the slides of
> the latest one at here:
> http://conferences.oreillynet.com/presentations/os2007/os_vanrossum.ppt).

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!

> [zip()]
>> 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)))

-- 
KBK