The documentation for standard types says [1]:

  clear() and copy() are included for consistency with the interfaces of
  mutable containers that don’t support slicing operations (such as dict
  and set)

  New in version 3.3: clear() and copy() methods.

[1] https://docs.python.org/3.4/library/stdtypes.html#immutable-sequence-types

but collections.abc documentation mentions only clear() method.

I've uploaded a patch that implements Set.copy() method, mentions it in
Set's documentation, and adds a sanity test.

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.

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

Also, note that MutableMapping does not have a copy method.

Agreed with Raymond.  The return type of copy() for ABCs feels problematic.  MutableMapping doesn't have it either.

> 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.

You need to learn when to give up. :-)

I wasn't the one who added a copy() method to other containers.  I personally despise almost all uses of "copying" (including the entire copy module, both deep and shallow copy functionality).  I much prefer to write e.g. list(x) over x.copy() -- when I say list(x) I know the type of the result.