[Python-bugs-list] [ python-Bugs-825247 ] Itertools imap and izip boundary cases

[SourceForge.net]

Bugs item #825247, was opened at 2003-10-16 20:55
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825247&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Itertools imap and izip boundary cases

Initial Comment:
It appears that itertools.imap cannot be applied to a
function f of
zero arguments: imap(f) raises a TypeError with the
message "imap()
must have at least two arguments".  Is there a reason
for this
restriction?  There's a logical and natural definition
for imap(f),
which fits with all the current documentation: it
should be an
iterator returning the sequence f(), f(), f(), .... 
Not only is this
natural but it's also useful: for example, imap(random)
is a handy way
to write down an iterator that returns a succession of
random floats
in [0, 1).  Is there a reason for treating functions
with zero
arguments differently from functions with one or more
arguments?

I'd also argue that the result of izip() is incorrect:
if it's going
to work according to the same rules as other calls of
izip, it should
return an infinite list of empty tuples; that is, it
should be
equivalent to repeat(()).  As the docstring states, the
.next() method
should continue until one of the iterables is
exhausted; with no
iterables, this never happens, so a strict logical
reading of this
statement is that the .next() method of izip() should
continue
indefinitely.  This definition of izip() also ensures
that natural
laws like

imap(f, *args) = starmap(f, izip(*args)) 

don't break in the boundary case (at least, given my
proposed
definition of imap(f) above).

(The above changes can be effected by simply removing 7
lines from the itertools.c source code.)



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-10-16 23:40

Message:
Logged In: YES 
user_id=80475

These are not bugs.  They were each thought about and
rejected during the design process.  At best they can be
considered feature requests for use cases that can be
already be satistified in other ways:
  * repeat(()) # gives an infinite list of tuples
  * starmap(random.random, repeat(())) # infinite series of
random numbers

FWIW, here is some of the rationale behind the current design.

imap() was kept as parallel as possible with map() which
also requires at least two arguments. The None fill-in
feature of map() was specifically discarded so that infinite
iterators could be freely mixed with finite iterators and
yield a finite result.  The design is to *not* trigger
infinite iteration unless specifically requested.  IMO, the
absence of arguments is most likely a programmer error and
should be flagged immediately.  

I did consider use cases like random() and ctime().  They
are foremost among the rare infinite functions with
meaningful outputs but no inputs.  They were not common
enough to warrant mucking-up imap() especially when the need
is already met by starmap(func, repeat()) or iter(callable,
impossibleSentinel).  Note, there are many useful
non-infinite functions with no arguments -- for these, use
iter(callable, sentinel)

In Py2.3.2 and beyond, izip() accepts zero arguments to keep
it consistent with zip() which, in Py2.4, will return an
empty list.  The rationale for the change was to complete
the boundary case for zip(*args) which is common definition
for a matrix transpose or for unzipping.   Like imap(),
infinite iteration needs to be explicitly requested.  izip()
is for lockstep iteration; if you want a infinite series of
empty tuples, use the tool designed for that need:  repeat(()).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825247&group_id=5470