[Python-ideas] Should this be considered a bug?

[Mike Meyer]

On Mon, 31 Oct 2011 08:31:18 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Mon, Oct 31, 2011 at 8:17 AM, Mike Meyer <mwm at mired.org> wrote:
> > The only other iterable type you can add is tuples - and they don't
> > display this behavior. So why not go ahead and fix this "bug" by
> > making list.__add__ try converting the other object to a list, and
> > adding a list.__radd__ with the same behavior?
> >
> > For that matter, a similar tweak for tuples wouldn't be inappropriate,
> > and then the case of adding tuples & lists can raise a type error,
> > paralleling the behavior of decimals and floats in the number
> > hierarchy.
> 
> The universe of container types is a lot bigger than the Python
> builtins. Suppose we made list.__add__ as permissive as list.__iadd__.
> Further suppose we make collections.deque.__add__ similarly
> permissive.
> 
> Now "[] + deque() == []", but "deque() + [] == deque()". Contrast that
> with numeric types, which are designed to work together as a numeric
> tower, such that the type of a binary operation's result does *not*
> depend on the order of the operands: "1 + 1.1 == 2.1" and "1.1 + 1 ==
> 2.1".

True. But addition on lists isn't commutative. [1] + [2] != [2] + [1].

> Commutativity is an important expected property for addition and
> multiplication. Even NumPy's arrays respect that by using those
> operations for the element-wise equivalents - they use a separate
> method for matrix multiplication (which is not commutative by
> definition).

I agree. And if lists were commutative under addition, I'd say that
was sufficient reason not to do this. But they aren't.

    <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org