From: Raymond Hettinger [mailto:raymond.hettinger@verizon.net]
The docs and examples are a good place to start.
Just looked at the documentation for now... count: In the absence of any explicit statement, I'd expect it to work transparently with longs, not just integers. You should likely make this explicit. dropwhile: the definition doesn't mention an "invert" parameter, but the Python equivalent does (but doesn't use it). This parameter (I assume) would merge the functionality of "dropwhile" and "dropuntil". Maybe it would be more readable to have both (implemented internally via a single function and a flag, probably)? It's also probably worth pointing out that dropwhile could have a slow startup time - imagine from itertools import dropwhile, count for n in dropwhile(lambda x: x < 2**30, count(-2**30)): print "Hello!" The first iteration wouldn't happen for a long time... (This is true of most iterator functions, it's just more surprising in this case as all of the remaining iterations will be "fast") ifilter: "Evaluates to True" should probably just be "is true". The Python code accepts functions returning non-boolean values in the natural way. imap: The stop-on-shortest behaviour is reasonable (given the nature of iterators), but the fact that it's different from map is definitely a wart. That's the key reason for having zip as well as map, isn't it? It's nearly worth a different name, but I can't think of one :-( izip: No real problem, other than that the subtle differences between zip and map(None) are hard to remember. Add the subtle differences between zip and izip, and map and imap, and it all gets rather messy. I wish there was an easy way of unifying or differentiating these. But I can't offer one myself :-( starmap: Um, I see the point. Sort of. A usage example or two would help a lot - I can't think why I'd want this. And I hate the name. Isn't it basically iapply? takewhile: As with dropwhile, the issue of the invert parameter (or a function dropuntil) needs resolving. In the examples section, reimplementation of existing tools, nth is wrong (the definition doesn't use "s"!) Also, with the definitions of enumerate/iteritems, my initial thought was "but the builtins will be quicker". This makes the examples bad, as they associate the itertools functions with the idea that they are slow. (Of course, that isn't the point, nor is it true, but it's not a good impression to leave the reader with). One final point - I don't really like the i- form of the names. We already have this style with x- forms like range/xrange, and it bugs me because I'm not *really* comfortable with having 2 forms (it's the usual problem of why use one rather than the other - and the name gives no clue). The need is there with builtins, but for a module maybe it isn't. Could we not have itertools just defining map, zip, ... functions. Then a user can either use the qualified form, or use import from. So you have import itertools for x in itertools.zip(a,b): or from itertools import zip as izip for x in izip(a,b): On the other hand, maybe this will also end up causing confusion... Hope this helps, Paul.
From: "Moore, Paul" <Paul.Moore@atosorigin.com>
Just looked at the documentation for now...
Great. Any review at all is helpful
count: In the absence of any explicit statement, I'd expect it to work transparently with longs, not just integers. You should likely make this explicit.
Done.
dropwhile: the definition doesn't mention an "invert" parameter but the Python equivalent does (but doesn't use it).
Fixed the python definition in the docs.
It's also probably worth pointing out that dropwhile could have a slow startup time
Done.
ifilter: "Evaluates to True" should probably just be "is true".
Done.
imap: The stop-on-shortest behaviour is reasonable (given the nature of iterators), but the fact that it's different from map is definitely a wart.
It is one I'm willing to live with. A need for a None fillin doesn't come up in the use cases for iterator algebra and would more than likely lead to unexpected errors. I'm counting on documenting the difference; having a different name (imap vs map); knowing that its use with map() was already extremely rare (how many functions respond well to having a parameter suddenly switch type and become None); and having the domain itself be a guide (for example, __builtin__.pow and math.pow are not identical but in the domain of floats the idea of using raised-to-modulo just doesn't come up). Though it chafes my desire for "foolish consistency", it neatly parallels the SML/Haskell versions, works well with other itertools, and I don't expect a real problem to ever arise in practice.
izip: No real problem, other than that the subtle differences between zip and map(None) are hard to remember. I wish there was an easy way of unifying or differentiating these.
zip() and map(None) are already set in stone. izip() and imap(None) have no differences. zip() and izip() only differ in that they return an iterator. They are differentiated by their name (hence, the "i" in izip). So, the only difference is the None fillin feature for map(). The reasons for that are listed above.
starmap: Um, I see the point. Sort of. A usage example or two would help a lot. And I hate the name.
Expanded the docs with an example, clarified the usage, and put in an analogy to show why the name is appropriate: map() is to f(a,b) as starmap is to f(*c). While the name is reminiscent of a constellation chart, the use of the star names has a long history in functional languages. It also matches python's choice of an operator for f(*c).
I can't think why I'd want this.
If your data stream is already "pre-zipped", it's major PITA to unzip them just to feed imap().
takewhile: As with dropwhile, the issue of the invert parameter (or a function dropuntil) needs resolving.
Fixed.
In the examples section, reimplementation of existing tools, nth is wrong (the definition doesn't use "s"!)
Fixed.
Also, with the definitions of enumerate/iteritems, my initial thought was "but the builtins will be quicker".
There is a strong pedagological value in building off of existing knowledge when showing how itertools can be combined. But your point is well taken, so I rewrote the introduction to the section to indicate that it is just to show how the pieces fit together.
One final point - I don't really like the i- form of the names.
It is the module designer's perogative. Not only does it steal the pithy naming convention from MacIntosh marketing, it is helpful for indicating that each function returns an iterator. The x-functions pre-date iterators and generators and are all on their way out. I don't want any confusion with them.
Hope this helps, Paul.
Absolutely. Thank you again for contributing review time. Raymond Hettinger
participants (2)
-
Moore, Paul -
Raymond Hettinger