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

[Bengt Richter]

On 7 Jan 2006 23:19:41 -0800, "Raymond Hettinger" <python at rcn.com> wrote:

>I am evaluating a request for an alternate version of itertools.izip()
>that has a None fill-in feature like the built-in map function:
>
>>>> map(None, 'abc', '12345')   # demonstrate map's None fill-in feature
>[('a', '1'), ('b', '2'), ('c', '3'), (None, '4'), (None, '5')]
>
I don't like not being able to supply my own sentinel. None is too common
a value. Hm, ... <bf warning> unless maybe it can also be a type that we can instantiate with
really-mean-it context level like None(5) ;-)

 >>> map(None(5), 'abc', '12345')   # demonstrate map's None fill-in feature
 [('a', '1'), ('b', '2'), ('c', '3'), (None(5), '4'), (None(5), '5')]

But seriously, standard sentinels for "missing data" and "end of data" might be nice to have,
and to have produced in appropriate standard contexts. Singleton string subclass
instances "NOD" and "EOD"? Doesn't fit with EOF=='' though.
</bf warning>

>The movitation is to provide a means for looping over all data elements
>when the input lengths are unequal.  The question of the day is whether
>that is both a common need and a good approach to real-world problems.
>The answer to the question can likely be found in results from other
>programming languages or from real-world Python code that has used
>map's None fill-in feature.
>
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.

>I scanned the docs for Haskell, SML, and Perl and found that the norm
>for map() and zip() is to truncate to the shortest input or raise an
>exception for unequal input lengths.  I scanned the standard library
>and found no instances where map's fill-in feature was used.  Likewise,
>I found no examples in all of the code I've ever written.
>
>The history of Python's current zip() function serves as another
>indicator that the proposal is weak.  PEP 201 contemplated and rejected
>the idea as one that likely had unintended consequences.  In the years
>since zip() was introduced in Py2.0, SourceForge has shown no requests
>for a fill-in version of zip().
>
>My request for readers of comp.lang.python is to search your own code
>to see if map's None fill-in feature was ever used in real-world code
>(not toy examples).  I'm curious about the context, how it was used,
>and what alternatives were rejected (i.e. did the fill-in feature
>improve the code).
>
>Also, I'm curious as to whether someone has seen a zip fill-in feature
>employed to good effect in some other programming language, perhaps
>LISP or somesuch?
ISTM in general there is a chicken-egg problem where workarounds are easy.
I.e., the real question is how many workaround situations there are
that would have been handled conveniently with a builtin feature,
and _then_ to see whether the convenience would be worth enough.
>
>Maybe a few real-word code examples and experiences from other
>languages will shed light on the question of whether lock-step
>iteration has meaning beyond the length of the shortest matching
>elements.  If ordinal position were considered as a record key, then
>the proposal equates to a database-style outer join operation (where
>data elements with unmatched keys are included) and order is
>significant.  Does an outer-join have anything to do with lock-step
>iteration?  Is this a fundamental looping construct or just a
>theoretical wish-list item?  IOW, does Python really need
>itertools.izip_longest() or would that just become a distracting piece
>of cruft?
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).

Regards,
Bengt Richter