[Python-bugs-list] [ python-Bugs-681003 ] itertools issues

[SourceForge.net]

Bugs item #681003, was opened at 2003-02-05 15:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=681003&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: itertools issues

Initial Comment:
I've been checking out the new itertools module.  It's a great 
addition; I look forward to using it.  However, I did notice a 
few things:

1) I believe islice should worry about overflow when it adds 
step to next.  Given a call like islice(seq, 1, 10, sys.maxint), 
it looks like islice will not stop after retrieving item 1 
because this:

  lz->next += lz->step;

will result in lz->next becoming negative.

2) I note that starmap_next passes the args obtained from 
PyIter_Next directly to PyObject_Call.  PyObject_Call 
assumes that its arg param is a tuple (and so do the various 
tp_call slots).  However, there is nothing to ensure that the 
args object obtained from the iterator in starmap_next is in 
fact a tuple.  I believe either a PyTuple_Check or a 
PySequence_Tuple call is in order before passing the args 
to PyObject_Call.

3) I don't think it's safe for imap_next to reuse the same 
argtuple for all the calls.  This tuple is passed directly to C 
functions, and there's nothing to stop them from saving a 
reference to it someplace (unless it's documented 
somewhere that you shouldn't save references to the args 
tuple).

4) I think count_next should worry about overflow also 
(consider count(sys.maxint)).


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

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