On Monday 29 April 2002 02:16, Raymond Hettinger wrote: ...
I posted this one separately because zip() eats memory like crazy and because a Python generator version crawls like a snail.
IMHO, This is a better way to loop over multiple sequences and has a chance at becoming the tool of choice. I scanned all of my
Just musing -- what should enumerate() do when called with N!=1 arguments? Right now it raises, maybe not the most useful thing. Shouldn't it return an iterator for tuples of N+1 items with zip-like behavior? That would neatly substitute for some of my uses of zip, main use cases left out being of the form dict(zip(s1,s2)). [And enumerate() called without arguments should return a "non terminating" iterator yielding 0, 1, 2, ... -- I have a lot of uses of xrange(sys.maxint) that have no real reason to stop at maxint, and other ways to build such an iter, which could go away. But this has little to do with iterzip]. This wouldn't replace all need for iterzip (but might in many cases) but in any case it would be a natural and useful generalization of enumerate's design. YAGNI doesn't seem to apply since looking at my own code with such a general enumerate in mind does show reasonable need (admittedly I crunch a lot of integers in various combinatorial ways and just love the iterator/unending-stream computing architecture/paradigm).
In general I'm not keen on increasing the number of builtin functions much.
Ditto. Any chance of moving functions like map(), reduce(), and filter() to a functional module; pow() and divmod() to the math module; or input() to oblivion?
The amount of code breakage would be appalling unless some easy way was provided for the programmer to assert "this (module/script/ package/entire Python run) needs the following well-known (names/ name sets) to be installed as built-in names", defaulting at least for now to functional.{math,reduce,filter}, etc. Quite apart from the math.pow issue (current builtin pow should need to go elsewhere than in math -- maybe a new module for "integral-oriented" arithmetic). site and optionally sitecustomize could perhaps help control such a hypothetical "easy way". Easiest in a sense would be do to it directly with import __builtin__ &c, but if that's to remain "strongly discouraged" then some fancy-dress for it, perhaps "unavailable after startup" in the same vein as sys.defaultencoding, could be provided. Perhaps too kludgey, but otherwise it seems to me that no removals from __builtin__ can happen before mythical Python-3000. Alex