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` ? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CGW5TKJJWZSOBYJDGWW3KVTV4XGAZ7CV/ Code of Conduct: http://python.org/psf/codeofconduct/
