collections.Set / collections.MutableSet do not provide any of the named set methods, nor do dict view objects (neither as viewkeys and friends create them nor in py3). They obviously implement the operator methods correctly, but besides the fact that they're not fully implementing the set API, .union, .difference, and .intersection, for example, take *args to do arbitrary unions / difference / intersections, so there's at least one functionality gap too (nothing a for loop can't fix but, yeah). I've attached a very quick example diff'ing the methods which I ran on 2.7 and 3.2.


In searching around for a reason, or at least some documentation or acknowledgement that this is intentional, I see there's an offhand comment on Issue7771 (I apologize in advance if this didn't deserve its own ticket then). Issue9212 was accepted as "an oversight" and is related, so I hope that it's worth the clarification as to whether 1. we (you :) are planning / willing to do this fix on 2.7, or 3.2, or 2. if this is desired for some reason, in which case consider this simply a documentation request and perhaps a dupe of 7771 then.

Now that I've been long winded thanks for your time :).

IIUC, collections.Set is, by definition, the full 'set' API.  The fact that the set builtin implements some additional methods is a convenience.

Oh boy. Reading the comment in Issue9212 more carefully now that you said that I see that Mr. Hettinger said exactly that. I apologize for missing it the first time.

"Concrete classes are allowed to have more features than the corresponding ABC.  The ABCs are not intended to be full-featured; instead, they specify the part of the API that will be guaranteed.  For example, the union() method for built-in sets allows two or more set arguments, but the corresponding method for the ABC is limited to two arguments.  This was an intentional difference, designed to make it easier for people to implement a Set class."

I suppose I should close this, unless there's some hope perhaps of some elaboration on that last line. Why couldn't collections provide the named methods too (in what way is this "easier"?)

collections.Set (in python 3.3, collections.abc.Set) is the *definition* of the minimal API.  To construct a class that conforms to the minimal definition is certainly easier than constructing one that supports all of the methods that the set builtin does.

I suppose it would be possible for the collections module to provide a 'SetMixin' or some such that provided implementations of the other methods in terms of the required methods, but that would definitely be a feature request, and probably a topic that should be discussed first on the python-ideas mailing list.