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 Horacio Hoyos, ned.deily, r.david.murray, rhettinger
Date 2017-04-28.03:54:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1493351688.28.0.439098014453.issue30146@psf.upfronthosting.co.za>
In-reply-to
Content
> That being said, I believe (as the OP of issue 8743) 
> that the ABC collections should comply to the API of
> the Python base collections. 

Sorry Horacio, but your beliefs don't trump Guido's intentional design decisions.   He was the one who decided that the collections.abc.Set should have a __and__ that accepts an iterable and that it should not have the named methods (union, intersection, difference, etc).  Once released, that decision is not changeable without breaking existing code that relies on any iterable being accepted (which is a useful behavior given the absence of an union() method).   Guido also decided long ago that no class other that list would repeat its list.__iadd__ design mistake.   You can search the python-dev archives to find the discussion where it was decided that this applies to the concrete set type (i.e. that s |= 'abc' would raise a TypeError).  I happen to agree with that decision.  Though it seems to offend your sense of consistency, it does have the advantage of precluding what would likely be a common source of errors.

I'm marking this as closed.  The time to litigate API design decisions is prior to their being released.  This particular ship sailed a decade ago and has mostly worked out fine for all of our users.
History
Date User Action Args
2017-04-28 03:54:48rhettingersetrecipients: + rhettinger, ned.deily, r.david.murray, Horacio Hoyos
2017-04-28 03:54:48rhettingersetmessageid: <1493351688.28.0.439098014453.issue30146@psf.upfronthosting.co.za>
2017-04-28 03:54:48rhettingerlinkissue30146 messages
2017-04-28 03:54:47rhettingercreate