[Python-Dev] API for binary operations on Sets (original) (raw)

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 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 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