Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:

Sorry Dan, we're going to pass on this one.  The current behavior was an 
intentional design choice by Guido and reflects a careful balance between some 
difficult trade-offs.

An early and permanent mistake in Python's design is that list.__iadd__() and 
list.extend() both accept any input iterable.  For extend(), this proved to be 
useful.  In contrast, __iadd__() was a recurring bug magnet.  People would 
routinely type "s=['abc']; s+='def'" expecting to get ['abc', 'def'] rather 
than ['abc', 'd', 'e', 'f'].   Based on this experience, Guido wisely opined 
that math operators on other concrete collection classes should be restricted 
working with members of their own class.

When abstract base classes were introduced, a seemingly inconsistent decision 
was made.  The Set ABCs allowed the math operators to accept any input iterable 
and did not provide the spelled-out method names (union, intersection, 
difference, etc).

IIRC, there were several reasons for this.  It kept the total number of methods 
to a manageable size (important so as to not unduly burden implementers of 
concrete classes).  Also, having a same type restriction is at odds with some 
of the design goals and use cases for collections ABCs.  Additionally, the code 
for the mixin methods is simpler without the restrictions.

When dict views were implemented, they followed the Set ABCs.  This gave them 
fewer methods than sets but also gave them fewer restrictions.  For the most 
part, these design trade-offs have worked out well in practice.  The existing 
behavior is neither "needless" nor "arbitrary".  It was the result of careful 
consideration by GvR on what works best for most people, most of the time.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue34497>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to