On Fri, Sep 3, 2021 at 9:35 AM Guido van Rossum <gu...@python.org> wrote:

> The question is, would anyone ever want to make a distinction between the
> two in *real* code?
>

I expect not.

However, finer grained exception may help with debugging and testing.

-CHB




find it unlikely that someone would write
>
> try:
>     sum(x, y, z)
> except TypeError:
>     ...
>
> If you bury the sum() call deep inside other code, I'd say your try/except
> net is too wide.
>
> On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin <oscar.j.benja...@gmail.com>
> wrote:
>
>> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka <storch...@gmail.com>
>> 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).
>> >
>> > 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 that it would be good to make TypeError more fine-grained.
>> Another example is:
>>
>> >>> sum(1, 2, 3)
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> TypeError: sum() takes at most 2 arguments (3 given)
>>
>> There can be reasons in library code to catch TypeError that might
>> arise from bad user input but in those situations you would usually
>> not want to catch this TypeError. The error from calling a function
>> with the wrong number of arguments would usually mean a bug in the
>> library code which should not be caught. Conversely if the user input
>> is a callable and you do want to catch the error resulting from it
>> being called with the wrong number of arguments then catching
>> TypeError is too broad again. Something like BadArgumentsError would
>> be better.
>
>
>>
>> --
>> Oscar
>> _______________________________________________
>> 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/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
> _______________________________________________
> 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/MXVBSNUTLVJVKWIVUK7MSCKM4YDPEL4Y/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
_______________________________________________
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/TUZTKVO23LZGZ37QX45MJZ3T7LECKIW3/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to