[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