George Sakkis wrote:
> Carl Banks wrote:
> > George Sakkis wrote:
> > > 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.
>
> Do you also find the way "in" works today a bad idea ?
Augh. I don't like it much, but (assuming that there are good use
cases for testing containment in iterables that don't define
__contains__) it seems to be the best way to accomplish it for
iterables in general. However, "in" isn't even comparable to "add"
here.
First of all, unlike "add", the nature of "in" more of less requires
that the second operand is some kind of collection, so surprises are
kept to a minimum. Second, testing containment is just a bit more
important, and thus deserving of a special case, than chaining
iterables.
The problem is taking a very general, already highly overloaded
operator +, and adding a special case to the interpreter for one of the
least common uses. It's just a bad idea.
> > 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.
>
> That's a good example for why I prefer an iterator rather than an
> iterable algebra; the latter is too implicit as "a + b" doesn't call
> only __add__, but __iter__ as well. On the other hand, with a concrete
> iterator type "iter(a) + iter(b)" is not any more error-prone than
> 'int(3) + int("2")' or 'str(3) + str("2")'.
>
> What's the objection to an *iterator* base type and the algebra it
> introduces explicitly ?
Well, it still makes it more work to implement iterator protocol, which
is enough reason to make me -1 on it. Anyways, I don't think it's very
useful to have it for iterators because most people write functions for
iterables. You'd have to write "iter(a)+iter(b)" to chain two
iterables, which pretty much undoes the main convenience of the +
operator (i.e., brevity). But it isn't dangerous.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
