Serhiy Storchaka wrote:
There are two different kinds of TypeError: if the end user passes an instance of wrong type and if the author of the library makes an error in implementation of some protocols. For example, len(obj) raises TypeError in two cases: if obj does not have __len__ (user error) and if obj.returns non-integer (implementation error). for x in obj raises TypeError if obj does not have __iter__ (user error) and if iter(obj) does not have __next__ (implementation error).
what's the reason for this not to raise AttributeError? I assume you asked this question in relation to the 3.11 changes to `with x:` raising TypeError vs AttributeError ?
User errors can be fixed on user side, implementation errors can only be fixed by the author of the class. Even if the user and the author is the same person, these errors point to different places of code. Would it be worth to add a special TypeError subclass for implementation errors to distinguish them from user errors? How to name it (ImplementationError, ProtocolError, etc)?
I think ProtocolError would be too easily confused as relating to typing.Protocol or asyncio.Protocol ImplementationError sounds like it's related to `abc`s or NotImplementedError How about `AttributeNotFoundError` or `AttributeRequiredError` ?