On 9/29/2010 11:50 PM, Raymond Hettinger wrote:
I would like to solicit this group's thoughts on how to reconcile the
Set abstract base class with the API for built-in set objects (see
http://bugs.python.org/issue8743 ). I've been thinking about this issue
for a good while and the RightThingToDo(tm) isn't clear.
Here's the situation:
Binary operators for the built-in set object restrict their "other"
argument to instances of set, frozenset, or one of their subclasses.
Otherwise, they return NotImplemented. This design was intentional (i.e.
part of the original pure python version, it is unittested behavior, and
it is a documented restriction). It allows other classes to "see" the
NotImplemented and have a chance to take-over using __ror__, __rand__,
etc. Also, by not accepting any iterable, it prevents little coding
atrocities or possible mistakes like "s | 'abc'". This is a break with
what is done for lists (Guido has previously lamented that list.__add__
accepting any iterable is one of his "regrets").
I do not understand this. List.__add__ is currently *more* restrictive
than set ops in that it will not even accept a 'frozenlist' (aka tuple).
>>> ll + (4,5,6)
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
ll + (4,5,6)
TypeError: can only concatenate list (not "tuple") to list
>>> ll.__add__((5,6,7))
Traceback (most recent call last):
File "<pyshell#4>", line 1, in <module>
ll.__add__((5,6,7))
TypeError: can only concatenate list (not "tuple") to list
Does this violate the Sequence ABC (assuming there is one)?
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
