itertools.izip brokeness

[rurpy at yahoo.com]

<rurpy at yahoo.com> wrote:
> But here is my real question...
> Why isn't something like this in itertools, or why shouldn't
> it go into itertools?

Never mind...
I just read this in the source code for itertools.imap:

  1) Itertools are designed to be easily combined and chained together.
     Having all tools stop with the shortest input is a unifying
principle
     that makes it easier to combine finite iterators (supplying data)
with
     infinite iterators like count() and repeat() (for supplying
sequential
     or constant arguments to a function).

  2) In typical use cases for combining itertools, having one finite
data
     supplier run out before another is likely to be an error condition
which
     should not pass silently by automatically supplying None.

  3) The use cases for automatic None fill-in are rare -- not many
functions
     do something useful when a parameter suddenly switches type and
becomes
     None.

  4) If a need does arise, it can be met by __builtins__.map() or by
     writing:  chain(iterable, repeat(None)).

  5) Similar toolsets in Haskell and SML do not have automatic None
fill-in.

I know I shouldn't post this but...

<FLAME ON>
Jezuz Freekin' Cripes!!
This is the crap that drives me up a wall using Python.
I spent 10 hours writing the original non-working code,
finding the probllem, posting to c.l.p, writing working
replacement code.  Why?  Because some pythonic
devdude sitting in his god throne declared that I don't
need to do what I needed to do!!

  1) Itertools are designed to be easily combined and chained together.
     Having all tools stop with the shortest input is a unifying
principle
     that makes it easier to combine finite iterators (supplying data)
with
     infinite iterators like count() and repeat() (for supplying
sequential
     or constant arguments to a function).

There is not a count or a repeat to be seen anywhere in
my code.  So let's see...  I am prevented from using a
tool I need to use so that I will have the ability to use
some tools which I don't need.  Wow, that makes a lot
of f'ing sense.

  2) In typical use cases for combining itertools, having one finite
data
     supplier run out before another is likely to be an error condition
which
     should not pass silently by automatically supplying None.

Just plain wrong.  Files are very commonly used iterators,
and the ttypical case with them is that they are of different
lengths.  And I have run into plenty of non-file iterators of
differing lengths.  Declaring by fiat that these are all
error cases and shouldn't be permitted is bullshit.

  3) The use cases for automatic None fill-in are rare -- not many
functions
     do something useful when a parameter suddenly switches type and
becomes
     None.

So allow a caller-specified fill.  Not rocket science.

  4) If a need does arise, it can be met by __builtins__.map() or by
     writing:  chain(iterable, repeat(None)).

Yes, if youre a python guru.  I don't even understand the
code presented in this thread that uses chain/repeat, let
alone have any chance of writing it in less than a week.
For the average python user, having a tool to iterate to
the longest input is about 4 orders of magnitude simpler.

 5) Similar toolsets in Haskell and SML do not have automatic None
fill-in.

What the hell does this have to do with anything?  Maybe
there are other reasons like they have alternate, better
ways of doing the same thing?  Does the fact the C++
lack some feature justify leaving it out of Python?

Python is basically a pretty good language but there are
these big time holes in it.  I spend WAY too much time
trying to figure out how to do something that should be
easy, but isn't because someone thought that it might
hurt the "purity" of the language or violate some "principle".

pissed-offedly-yr's, rurpy

<FLAME OFF>