Currently WeakSet().discard([]) will raise a TypeError as we cannot take a weak reference to a list.

However, that means a list can never be in a WeakSet, so WeakSet().discard([]) could instead be a no-op.  Similarly WeakSet().remove([]) could be a KeyError.

What about difference_update(), issubset(), issuperset(), __eq__()?

Raising TypeError looks reasonable to me. Operations with ordinal sets can raise TypeError for unhashable values.

>>> [] in set()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
>>> set().remove([])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
>>> set().discard([])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

Unlike to set.__contains__ WeakSet.__contains__ returns False for unsupported types:

>>> [] in weakref.WeakSet()
False

Shouldn't set.__contains__ be changed to return False for unhashable values? Or may be make WeakSet.__contains__ raising TypeError for values that can't have weak references?

dict.pop() supports unhashable values, but dict.__contains__() and dict.get() don't:

>>> [] in {}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
>>> {}.get([], 42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
>>> {}.pop([], 42)
42

OrderedDict.pop() also doesn't support unhashable values:

>>> collections.OrderedDict().pop([], 42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

> Raising TypeError looks reasonable to me. 
> Operations with ordinal sets can raise TypeError 
> for unhashable values.

I agree.  TypeError looks the right exception in this case.

The argument for not raising TypeError for unsupported types:

This is just from the definition of a set. If the set can't contain the value of specific type, then checking if this value is contained in the set should return False, and discarding it from the set should be no-op.

The argument for raising TypeError for unsupported types:

Using a value of unsuitable type is likely a programming error. Silencing TypeError can hide an error. Since raising and catching an exception is costly (but it is cheaper in C than in Python), this also can lead to performance degradation which is hard to catch.

If the first argument is stronger then the second argument then we should change a number of set, dict, dict views and OrderedDict methods and make them returning a reasonable result rather than raising TypeError.

If the second argument is stronger then the first argument then we should change just WeakSet.__contains__() and dict.pop(). Since this is a behavior change that can break third-party code they should first emit deprecation warnings for one or two releases.

Just to add, I framed this slightly wrongly by using a list [] as an example, whereas my original motivating case was objects that are hashable but not weakly referenceable.   (eg () ).

So there are two cases to consider ... what to do in discard/remove etc when the value is (i) not weakly referenceable, and (ii) when the value is not hashable.

> my original motivating case was objects that are hashable but not weakly referenceable.  

It is probably not good design to extend discard() to handle types that aren't handled by the other methods.  To me, it isn't at all surprising that the business of a WeakSet is to handle objects that are both hashable and weak referenceable.  Muddying those waters may do more harm than good.  My recommendation is to decline the feature request.

One other thought.  As the Python world starts to encourage type annotations and static type checking, one benefit we would hope for is code with cleaner matches between the caller and callee signatures.  Accordingly, we shouldn't encourage people to write code with odd signatures:
  
    x : thing_that_cant_possibly_be_in_the_weakset
    some_weakset.discard(x)  # Someday, we might hope this would be flagged