> I don't think this is needed nor do I think that it is a good idea to
> have a copy() method in the ABCs because they know so little about
> their concrete underlying class (perhaps the backing store in the
> filesystem or a database).  Besides, a user already has workable
> alternatives such as creating a new instance and applying |= to
> populate it.

"because they know so little about their concrete underlying class"

FYI, the patch demonstrates how to implement copy() for *any*
MutableSet:

  def copy(self):
      return self._from_iterable(self)

_from_iterable() default implementation is cls(self) i.e., the copy()
method may be also efficient by default e.g., it may return the object
itself for immutable types.

---
The issue is closed so the rest can be ignored.

> In general, we don't do API expansions without motivating use cases to
> guide the design.

The reason to add Set.copy() is the same one as for set.copy() i.e., add
the equivalent of L[:] to mutable containers that don't support slicing
as the documentation excerpt in msg224255 explicitly says (copy()
doesn't modify its object so it can be added to immutable type).

General purpose language should provide an ability to copy a container.

In practice, people spell this operation as CustomSet(s) thus hardcoding
the type and ruining the flexibility provided by s.copy() duck-typing
(or copy.copy()).

The same could be said about MutableMapping (separate issue) e.g., merge
a, b dictionaries assuming no .copy() method:

  d = dict(a)
  d.update(b)

vs. the same with .copy():

  d = a.copy()
  d.update(b)

The latter may also work for a custom dict. The former is hardcoded to
produce a dict e.g., you have to reimplement it (and all the surrounding
code) for OrderedDict, SortedDict, Splay tree -based dict, etc. Luckily
projects such as blist, banyan that implement custom container types do
provide copy() method.

I don't see why we should make it harder to correctly implement/use
custom set/dict types.