Python 3000 idea -- + on iterables -> itertools.chain

[Carl Banks]

George Sakkis wrote:
> Fredrik Lundh wrote:
>
> > George Sakkis wrote:
> >
> > > The base object class would be one candidate, similarly to the way
> > > __nonzero__ is defined to use __len__, or __contains__ to use __iter__.
> > >
> > > Alternatively, iter() could be a wrapper type (or perhaps mixin)
> > > instead of a function, something like:
> >
> > so you're proposing to either make *all* objects respond to "+", or
> > introduce limited *iterator* algebra.
>
> If by 'respond to "+"' is implied that you can get a "TypeError:
> iterable argument required", as you get now for attempting "x in y" for
> non-iterable y, why not ?

Bad idea on many, many levels.  Don't go there.


> Although I like the iterator algebra idea
> better.
>
> > not sure how that matches the OP's wish for "mostly backwards
> > compatible" support for *iterable* algebra, really...
>
> Given the subject of the thread, backwards compatibility is not the
> main prerequisite. Besides, it's an *extension* idea; allow operations
> that were not allowed before, not the other way around or modifying
> existing semantics.

You missed the important word (in spite of Fredrick's emphasis):
iterable.  Your iter class solution only works for *iterators* (and not
even all iterators); the OP wanted it to work for any *iterable*.

"Iterator" and "iterable" are protocols.  The only way to implement
what the OP wanted is to change iterable protocol, which means changing
the documentation to say that iterable objects must implement __add__
and that it must chain the iterables, and updating all iterable types
to do this.  Besides the large amount of work that this will need,
there are other problems.

1. It increases the burden on third party iterable developers.
Protocols should be kept as simple as possible for this reason.
2. Many iterable types already implement __add__ (list, tuple, string),
so this new requirement would complicate these guys a lot.

> Of course, programs that attempt forbidden
> expressions on purpose so that they can catch and handle the exception
> would break when suddenly no exception is raised, but I doubt there are
> many of those...

3. While not breaking backwards compatibility in the strictest sense,
the adverse effect on incorrect code shouldn't be brushed aside.  It
would be a bad thing if this incorrect code:

a = ["hello"]
b = "world"
a+b

suddenly started failing silently instead of raising an exception.


Carl Banks