[Python-Dev] iterzip()

[Raymond Hettinger]

----- Original Message ----- 
From: "Barry A. Warsaw" <barry@zope.com>
To: "Raymond Hettinger" <python@rcn.com>
Cc: "Guido van Rossum" <guido@python.org>; <python-dev@python.org>

> >>>>> "RH" == Raymond Hettinger <python@rcn.com> writes:
> 
>     RH> IMHO, This is a better way to loop over multiple sequences and
>     RH> has a chance at becoming the tool of choice.  I scanned all of
>     RH> my Python code and found that iterzip() was a better choice in
>     RH> every case except a matrix transpose coded as zip(*mat).
> 
> I'd much rather see a patch that just changed zip() to be an iterator
> instead of adding an iterzip().  I doubt that much in-field code would
> break because of it (but write the PEP to find out. ;).

I started down this road, by checking code in the Vaults of Parnassus
on the assumption that zip() is rarely used outside a for-loop.  What
may be the killer is the examples of zip() in Python books which 
demonstrate a stand-alone zip() returning a list -- in some ways,
textbook examples are just as important as in-field code.

I will write-up a PEP to see if the world cares.  For all I know, I may
be the only who uses zip() throughout my code.  Zip is just new enough
that it might not be too late to change it to an iterator.

> 
>     RH> Ditto.  Any chance of moving functions like map(), reduce(),
>     RH> and filter() to a functional module; pow() and divmod() to the
>     RH> math module; or input() to oblivion?
> 
> >>>>> "GvR" == Guido van Rossum <guido@python.org> writes:
> 
>     GvR> I wish.  Since they were there first, it's hard to get rid of
>     GvR> them.  (If you're truly masochist, write a PEP and post it to
>     GvR> c.l.py to find out how hard. :-)
> 
> The PEP would have to specify a migration plan, i.e. the builtins are
> identical to the functional module versions, and would a deprecation
> schedule, etc.

Will do.  I think the resistance to moving the functionals will be fierce.
Divmod probably has very few instances in real code.  I think __pow__
would need to be left in (as the ** that calls it), but the function itself
may be used only rarely.

Does anyone know of an automated what that I can scan a large body
of published Python code.  I would want some real usage statistics
in a PEP but hate pulling modules down one at a time and grepping
them.


Raymond Hettinger

> 
> -Barry