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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4