This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients fgregg, rhettinger
Date 2018-06-16.07:22:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1529133743.9.0.56676864532.issue33874@psf.upfronthosting.co.za>
In-reply-to
Content
It's true the concrete set API differs in some ways from the Set abstract base class followed by dictviews.   The concrete set-to-set operators are restricted to only work with other sets, leaving the named set methods (union, intersection, difference, etc) to accept any iterable.  In contrast, the Set abstract base class only has operators and those are specifically allowed to accept any iterable.

It may not seem harmonious, but those were intentional and long-standing design decisions.  The restriction on concrete set operators to only work with other sets can be traced back to bad experiences with the += operator for lists accepting any iterable (allowing mistakes like s+='abc' when s.append('abc') was intended).  

Different choices were made in the design of the abstract Set API.  In order to be useful, that API can't make as strong of a restriction, so it allows any iterable to be used as inputs to the operators.  Also note that the abstract Set API doesn't have the named set methods (union, intersection, difference, etc), so the burden of falls on the operators to support iterables.   IIRC, the reason that the named set methods were omitted was to make it easier to implement conforming classes that could interoperate with one another.  For more details on the design of the collections ABCs, see Guido's PEP on the subject (that's where he explains was problem the abstract classes where intended to solve and some of design considerations).

One can argue with those design decisions, but that ship sailed a long time ago and it would no longer be possible to change either set or Set without breaking existing code.  The existing behaviors are intentional, venerable, tested, and guaranteed.
History
Date User Action Args
2018-06-16 07:22:23rhettingersetrecipients: + rhettinger, fgregg
2018-06-16 07:22:23rhettingersetmessageid: <1529133743.9.0.56676864532.issue33874@psf.upfronthosting.co.za>
2018-06-16 07:22:23rhettingerlinkissue33874 messages
2018-06-16 07:22:23rhettingercreate