[Python-Dev] API for binary operations on Sets
Terry Reedy
tjreedy at udel.edu
Thu Sep 30 06:29:10 CEST 2010
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
More information about the Python-Dev
mailing list