On Wed, Jun 3, 2020 at 9:53 AM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
 > people think that ALL the regular methods are only there for legacy
 > reasons,

I tend to agree that they're legacy, but I think it's irrelevant to
the discussion.

I don't think so -- if you think that the ONLY reason for "regular" methods on ABCs is legacy, then the argument is over -- we're not going to add any new ones.

I don't think that -- I think there is a place for regular methods in ABCs, but that in most cases, backward compatibility will make it a bad idea to add any more. But not in this case.

You are correct to focus on whether adding them is
likely to cause backward compatibility issues, but I don't think an
acceptable degree of backward compatibility is a positive reason to
implement something.

no, of course not -- there has to be a positive reason to do so -- and I think there is. But not enough to push for it beyond this post. If the OP, or anyone else, wants to conitue to make the case, then I'll chime in in a with a +1 here and there, but that's about it.
 
BTW, thank you for clarifying that you aren't (in these posts)
advocating this change.  I shouldn't assume that lack of a disclaimer
means you're advocating rather than arguing a specific point.

well, I am, but pretty mildly ....

 > > I don't know about the Set ABC, but duck-typing is presumably quite
 > > common.  {1}.union([2]) uses set duck-typing.
 >
 > no it doesn't -- the set.union method takes any iterable -- that's
 > documented:

[list of documentation references omitted]

 > no duck-typing here.

What do you think the type "iterable" is? 

Sorry I didn't mean no duck typing, I meant no duck typing of set().

My point is that those methods take any iterable, not any set-like object -- and my point was that I don't think set-like objects are very often duck typed.
 
 For the purposes of set's
named methods, an "iterable" is "sufficiently set-like" to use set
operations on it.  That's duck typing.

I'm not sure this is just semantics, but I disagree, iterable is not "sufficiently set-like" -- it is an iterable. those methods do'nt need anything that is in a set that isn't in an iterable.

if they required something set like, they would require something in set that was not in all iterables.
 
 Do we need to
provide near duplicate methods that coerce iterables to set?

I don't think anyone is asking fort that -- the OP talked about the dict _keys and dict_items object, which, yes, are iterables, but they are also Sets:

In [8]: dk = d.keys()                                                          

In [9]: isinstance(dk, Set)                                                    
Out[9]: True

In [16]: di = d.items()                                                        

In [17]: isinstance(di, Set)                                                    
Out[17]: True

so no one asking for anything that will coerce iterables  to Sets, we are asking to make (at least some of) the Set objects in the standard library have the same API as the built in set object. Which seems pretty darn reasonable to me.

> "Parsimony" here is just a formal term for "YAGNI, so don't waste time typing it".

fair enough -- personally, I don't know that I've ever used the dict view objects as sets (yes, I use `in`, but that works with an container), so no, I don't need it.

But here's a (n abstract) use case:

def some_fun(a_set, some_args):
    ...
    a_set.union(something_iterable)
    ...

So I have a function that expects a set as input -- I could even use a type hint to say that.

I do all my testing, and use cases with the built in set() object -- seems perfectly reasonable.

But then one of my users passes in a dict_keys object -- and bam! it fails.

So then I need to either wrap something_Iterable in set(), and use the | operator, or I need to wrap a_set in the set() constructor.

Not a huge deal, but it does seem unnecessary.

I guess I don't like the inconsistency between the "prototype" builtin and the ABC -- seems strange to me.

And there is nothing in the docs that discourages use of the methods in favor of the operators. In fact, there is a section that describes why the methods are there, and how they can be useful.

OK, maybe now I am advocating :-)

But again, not worth any more of my time that I have already spent.

-CHB


--
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython