[Python-Dev] iterzip 'vs' enumerate

[Alex Martelli]

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