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/

Reply via email to