Do you have real-world use cases for map's None fill-in feature?

Bengt Richter bokr at oz.net
Tue Jan 10 17:06:06 CET 2006


On 10 Jan 2006 00:47:36 -0800, "Raymond Hettinger" <python at rcn.com> 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



More information about the Python-list mailing list