On 10 Jan 2006 00:47:36 -0800, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote:

>[Bengt Richter]
>> What about some semantics like my izip2 in
>>     
>> http://groups.google.com/group/comp.lang.python/msg/3e9eb63a1ddb1f46?hl=en
>>
>> (which doesn't even need a separate name, since it would be backwards 
>> compatible)
>>
>> Also, what about factoring sequence-related stuff into being methods or 
>> attributes
>> of iter instances? And letting iter take multiple sequences or 
>> callable/sentinel pairs,
>> which could be a substitute for izip and then some? Methods could be called 
>> via a returned
>> iterator before or after the first .next() call, to control various 
>> features, such as
>> sentinel testing by 'is' instead of '==' for callable/sentinel pairs, or 
>> buffering n
>> steps of lookahead supported by a .peek(n) method defaulting to .peek(1), 
>> etc. etc.
>> The point being to have a place to implement universal sequence stuff.
>
>ISTM, these cures are worse than the disease ;-)
Are you reacting to my turgidly rambling post, or to

 >>> from ut.izip2 import izip2 as izip
 >>> it = izip('abc','12','ABCD')
 >>> for t in it: print t
 ...
 ('a', '1', 'A')
 ('b', '2', 'B')

Then after a backwards-compatible izip, if the iterator has
been bound, it can be used to continue, with sentinel sustitution:

 >>> for t in it.rest('<sentinel>'): print t
 ...
 ('c', '<sentinel>', 'C')
 ('<sentinel>', '<sentinel>', 'D')

or optionally in sentinel substitution mode from the start:

 >>> for t in izip('abc','12','ABCD').rest('<sentinel>'): print t
 ...
 ('a', '1', 'A')
 ('b', '2', 'B')
 ('c', '<sentinel>', 'C')
 ('<sentinel>', '<sentinel>', 'D')

Usage-wise, this seems not too diseased to me, so I guess I want to make sure
this is what you were reacting to ;-)

(Implementation was just to hack together a working demo. I'm sure it can be 
improved upon ;-)

>
>
>> Even if there is little use for continuing in correct code, IWT getting
>> at the state of the iterator in an erroroneous situation would be a benefit.
>> Being able to see the result of the last attempt at gathering tuple elements
>> could help. (I can see reasons for wanting variations of trying all streams
>> vs shortcutting on the first to exhaust though).
>
>On the one hand, that seems reasonable.  On the other hand, I can't see
>how to use it without snarling the surrounding code in which case it is
>probably better to explicitly manage individual iterators within a
>while loop.
>
The above would seem to allow separation of concerns. I.e., if you care why
a normal iteration terminated, you can test after the fact. I.e., if all 
sequences
were the same length, the .rest() iterator will be empty. And if you don't care 
at
all about possible data, you can just try: it.rest().next() and catch 
StopIteration
to check.

BTW, is there any rule against passing information with StopIteration?

Regards,
Bengt Richter
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to