"Guido van Rossum" <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
