A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-April/023760.html below:

[Python-Dev] iterzip()

[Python-Dev] iterzip()Raymond Hettinger python@rcn.com
Sun, 28 Apr 2002 20:16:30 -0400
From: "Guido van Rossum" <guido@python.org>
> Hm, I'm not particularly enamored of the idea of adding 'iter'
> versions of everything under the sun.

I'm already working on a separate module for iterators galore
(and will cross-check to Haskell to make sure I didn't miss anything).

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
Python code and found that iterzip() was a better choice in every
case except a matrix transpose coded as zip(*mat).

>  I wish zip() could've been an
> interator from the start, but now that it isn't, I don't think it's
> such a big deal.  (An iterator version is easily written as a
> generator.)
> 
> 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?


Raymond Hettinger





RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4