xrange

Raymond Hettinger vze4rx4y at verizon.net
Mon Jun 23 07:37:51 CEST 2003


"Bryan" <belred1 at yahoo.com> wrote in message
news:KKsJa.107828$YZ2.275985 at rwcrnsc53...
> oh no...
>
> >>> for i in enumerate(['a', 'b', 'c']): print i
> ...
> (0, 'a')
> (1, 'b')
> (2, 'c')
> >>> for i in zip(count(), ['a', 'b', 'c']): print i
> ...
> (0, 'a')
> (1, 'b')
> (2, 'c')
> >>> for i in izip(count(), ['a', 'b', 'c']): print i
> ...
> (0, 'a')
> (1, 'b')
> (2, 'c')



Oh please!  That's just silly.

>>> print 1
1
>>> print range(2)[1]
1
>>> print 22-21
1
>>> print str("1")
1

Of course, general purpose constructs can be made to emulate one
another (for instance, most looping constructs reduce to "if" and "goto").

So, to answer your implied point/question/taunt or whatever it is,
here is the purpose of each and why things are the way they are:

* enumerate(seqn) was added to the builtins to address a common for
accessing list values and list indices at the same time.  That need came
up in several PEPs designed to tackle the "loop counter" problem.

* itertools.izip() is designed to be a highly efficient replacement for
zip().  In some circumstances, it is substantially more memory efficient
and faster than zip() which has to be kept in its present form for backwards
compatibilty.  For Python 3.0, I'm sure there will be only one -- the relation
of zip() to izip() is about the same as that of range() to xrange().

* itertools.count() is like itertools.repeat() in that it was designed to supply
arguments to imap(), ifilter(), izip(), and other itertools.  It allows you to
do things you can't do with enumerate() like:

          for checkno, check in izip(count(1000), checks):  . . .

          tabulate = lambda func:  izip(func, count())


Before getting in a twist about these things, try using some of the tools
to get a sense of why they are important.  If there is some overlap with
existing tools, remember that they pre-date the iterator protocol which
has done so much to unify and simplify python.

Also, try to avoid a shallow reading of the Zen of Python.
Yes, it says there is there should be only one way to do things.
But the zen is a set of trade-offs.  Guido's thoughts on the matter
are well summarized in his keynote slides from PyCon in DC:
  http://www.python.org/doc/essays/ppt/pycon2003/pycon2003.ppt

'nuff said,


Raymond Hettinger















More information about the Python-list mailing list