On Mon, Jun 1, 2020 at 5:31 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote:
> > > > On Jun 1, 2020, at 3:32 AM, a...@yert.pink a...@yert.pink <a...@yert.pink> > wrote: > > > > I propose that the `Set` ABC API should be augmented to contain all of > the named methods. This would provide consistency in the collections, and > enhance the duck typing capabilities of the `Set` abc. > > Two thoughts. First, I believe Guido intentionally omitted the named set > methods from the ABC — perhaps the reasons are documented in the ABC PEP. I just took a look at the PEP: https://www.python.org/dev/peps/pep-3119/#sets All I can see is: > Note: the issubset and issuperset methods found on the set type in Python 2 are not supported, as these are mostly just aliases for `__le__` and `__ge__`. 1. I don't know why it specifically says Python 2, the same methods exist in Python 3. 2. I assume this reasoning also applies to other named methods like intersection and union which are similar but not mentioned. 3. That's a pretty minimal justification. Is there more somewhere? Is that all you were referring to? 4. Even just aliases are useful: 1. They're arguably sometimes more readable, particularly to readers who don't know the operators. 2. When I want to use a set method on dict views, I have no easy way of remembering whether it's named methods or operators which work, and my first guess is often wrong. This is mildly inconvenient for me, but for less proficient users it may lead them to think that dict views don't implement the set methods at all and that they misunderstood what 'set-like' meant. 3. The builtin set operators don't accept arbitrary iterables on the RHS - only the named methods do. But several of the Set ABC operators *do* accept arbitrary iterables (why this difference?). I just learned this last bit, I don't think I knew it before, so I imagine there are others that don't know it either. This makes it seem like you have to write `my_dict.keys() & set(other)` instead of just `my_dict.keys() & other` which is both shorter and faster. > Second, most APIs are easily expanded by adding new methods, but ABCs > define a minimum for other classes to implement. So if we added new > methods, it would likely break code that was only meeting the existing > minimum. > These would be mixin methods, not abstract. Set already implements the various operators based on the abstract methods, it could easily add more mixin methods which would delegate to the operators. Classes which override the operators with more efficient versions would automatically get efficient aliases for free.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XHFQRM4XCLSU4VK3MTYKOM3T2OC6544K/ Code of Conduct: http://python.org/psf/codeofconduct/
