[Python-ideas] Re: Introduce 100 more built-in exceptions

[Serhiy Storchaka]

01.05.20 09:48, Ram Rachum пише:
I wish there were a 100 more built-in exceptions in Python, that will be 
very specific about what went wrong.


If I do this:

     >>> x, y = range(3)

I know it'll raise a ValueError, because I've memorized that, but it did 
take me a few years to remember where I should expect ValueError and 
where I should expect TypeError.


It would be nice if the operation above raised UnpackingOverflowError, 
which will be a subclass of UnpackingError, along with 
UnpackingUnderflowError. UnpackingError can be a subclass of ValueError, 
for backward compatibility.


Could you please provide a list of these 100 exceptions? If you create a 
PR, with documentation and tests, it would be a good start of the 
discussion.

___
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/M52MP2IYUDMBPKD3SPTFFDQHKKQ7RYXQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Ram Rachum]

On Fri, May 1, 2020 at 10:28 AM Serhiy Storchaka 
wrote:

> Could you please provide a list of these 100 exceptions? If you create a
> PR, with documentation and tests, it would be a good start of the
> discussion.
>

That's not a reasonable request. If there's enough support for this idea,
then I'll be happy to start working on this, but even then it'll be a
collaborative effort.
___
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/IVNKPAYM3HT67CMULVUIOT35USUWWW6L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[M.-A. Lemburg]

Hi Ram,

I think you are confusing the exception type with the exception
reason. By adding 100 more exception types, you don't make things
easier, but instead you complicate things, since we'd all have
to memorize those 100 exception types.

That said, enhancing the error reasons texts is certainly something
that would help everyone.

Adding more exception types to the stack makes sense when there's
a dedicated need to catch only specific sub types, but even there
it's already possible to add this extra information to the exception
objects as e.g. .errno or similar attribute.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 01 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/


On 01.05.2020 08:48, Ram Rachum wrote:
> Hi,
> 
> Here's something I wanted in Python for many years. If this has been
> discussed in the past, please refer me to that discussion.
> 
> On one hand, it's something that I can't imagine the python-dev
> community supporting. On the other hand, it would maintain backward
> compatibility.
> 
> I wish there were a 100 more built-in exceptions in Python, that will be
> very specific about what went wrong.
> 
> If I do this: 
> 
>     >>> x, y = range(3)
> 
> I know it'll raise a ValueError, because I've memorized that, but it did
> take me a few years to remember where I should expect ValueError and
> where I should expect TypeError.
> 
> It would be nice if the operation above raised UnpackingOverflowError,
> which will be a subclass of UnpackingError, along with
> UnpackingUnderflowError.  UnpackingError can be a subclass of
> ValueError, for backward compatibility.
> 
> Similarly, if I did this: 
> 
>     >>> def f(x, y): return x + y
>     >>> f(1)
> 
> I would get a TypeError. Would be a lot cooler if I got
> MissingArgumentsError, which would be a subclass of SignatureError,
> which would be a subclass of TypeError.
> 
> There are 2 reasons I want this: 
> 
> 1. When I'm writing a try..except clause, I want to catch a specific
> exception like MissingArgumentsError rather than ValueError or
> TypeError. They're too ubiquitous. I don't want some other unexpected
> failure producing the same ValueError and triggering my except clause. 
> 
> 2. When I get an error, especially from some shitty corporate system
> that truncates the traceback, I want to get as many hints as possible
> about what went wrong.
> 
> It's true that today, most Python exceptions have good text in their
> message, like "TypeError: f() missing 1 required positional argument:
> 'y'". But that isn't guaranteed everywhere, and specific exception types
> could help.
> 
> 
> What do you think? 
> 
> 
> Ram.
> 
> ___
> 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/XZXWXICKS2RCQLLX73NJOWCJPRY7IUX2/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
___
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/HKZTPPY5JHMAP7QSV7ALCT6O6TLETCDP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Ram Rachum]

I thought of a third advantage to this approach: Except clauses will be
easier to understand.

If I'm reading someone's code and I see `except ValueError`, I'm gonna have
to do a bit of thinking to figure out what exactly they're catching. On the
other hand, if the code is `except IntParsingError`, then I know exactly
what it is they're catching.

On Fri, May 1, 2020 at 9:48 AM Ram Rachum  wrote:

> Hi,
>
> Here's something I wanted in Python for many years. If this has been
> discussed in the past, please refer me to that discussion.
>
> On one hand, it's something that I can't imagine the python-dev community
> supporting. On the other hand, it would maintain backward compatibility.
>
> I wish there were a 100 more built-in exceptions in Python, that will be
> very specific about what went wrong.
>
> If I do this:
>
> >>> x, y = range(3)
>
> I know it'll raise a ValueError, because I've memorized that, but it did
> take me a few years to remember where I should expect ValueError and where
> I should expect TypeError.
>
> It would be nice if the operation above raised UnpackingOverflowError,
> which will be a subclass of UnpackingError, along with
> UnpackingUnderflowError.  UnpackingError can be a subclass of ValueError,
> for backward compatibility.
>
> Similarly, if I did this:
>
> >>> def f(x, y): return x + y
> >>> f(1)
>
> I would get a TypeError. Would be a lot cooler if I got
> MissingArgumentsError, which would be a subclass of SignatureError, which
> would be a subclass of TypeError.
>
> There are 2 reasons I want this:
>
> 1. When I'm writing a try..except clause, I want to catch a specific
> exception like MissingArgumentsError rather than ValueError or TypeError.
> They're too ubiquitous. I don't want some other unexpected failure
> producing the same ValueError and triggering my except clause.
>
> 2. When I get an error, especially from some shitty corporate system that
> truncates the traceback, I want to get as many hints as possible about what
> went wrong.
>
> It's true that today, most Python exceptions have good text in their
> message, like "TypeError: f() missing 1 required positional argument: 'y'".
> But that isn't guaranteed everywhere, and specific exception types could
> help.
>
>
> What do you think?
>
>
> Ram.
>
___
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/6Z2XITLJ4RSAW4WGTVPCA2YSHXONM3HO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Ram Rachum]

On Fri, May 1, 2020 at 11:37 AM M.-A. Lemburg  wrote:

> Hi Ram,
>
> I think you are confusing the exception type with the exception
> reason.


Some time ago `ModuleNotFoundError` was added as a subclass of
`ImportError`, which I really liked. Was this also another instance of a
confusion between the exception type and the exception reason?



> By adding 100 more exception types, you don't make things
> easier, but instead you complicate things, since we'd all have
> to memorize those 100 exception types.
>

Why would you have to memorize them? If you're writing an except clause,
you could still write `except ValueError:` and it'll work the same as
before.

Do you feel that the addition of `ModuleNotFoundError` meant that you now
had to memorize a new exception?
___
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/UIOZ4AZ2VEF5YKUWJ7UZHPVLBZ32NRBX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Alex Hall]

Recent related discussion:

https://mail.python.org/archives/list/python-ideas@python.org/thread/MXPCNEAWXWJPOHB3DC3QW3S3ZPOFSM4Q/

On Fri, May 1, 2020 at 8:53 AM Ram Rachum  wrote:

> Hi,
>
> Here's something I wanted in Python for many years. If this has been
> discussed in the past, please refer me to that discussion.
>
> On one hand, it's something that I can't imagine the python-dev community
> supporting. On the other hand, it would maintain backward compatibility.
>
> I wish there were a 100 more built-in exceptions in Python, that will be
> very specific about what went wrong.
>
> If I do this:
>
> >>> x, y = range(3)
>
> I know it'll raise a ValueError, because I've memorized that, but it did
> take me a few years to remember where I should expect ValueError and where
> I should expect TypeError.
>
> It would be nice if the operation above raised UnpackingOverflowError,
> which will be a subclass of UnpackingError, along with
> UnpackingUnderflowError.  UnpackingError can be a subclass of ValueError,
> for backward compatibility.
>
> Similarly, if I did this:
>
> >>> def f(x, y): return x + y
> >>> f(1)
>
> I would get a TypeError. Would be a lot cooler if I got
> MissingArgumentsError, which would be a subclass of SignatureError, which
> would be a subclass of TypeError.
>
> There are 2 reasons I want this:
>
> 1. When I'm writing a try..except clause, I want to catch a specific
> exception like MissingArgumentsError rather than ValueError or TypeError.
> They're too ubiquitous. I don't want some other unexpected failure
> producing the same ValueError and triggering my except clause.
>
> 2. When I get an error, especially from some shitty corporate system that
> truncates the traceback, I want to get as many hints as possible about what
> went wrong.
>
> It's true that today, most Python exceptions have good text in their
> message, like "TypeError: f() missing 1 required positional argument: 'y'".
> But that isn't guaranteed everywhere, and specific exception types could
> help.
>
>
> What do you think?
>
>
> Ram.
> ___
> 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/XZXWXICKS2RCQLLX73NJOWCJPRY7IUX2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/ZVX6Q6GFRVN6X43WZEAOBCDZTWJH56U6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Serhiy Storchaka]

01.05.20 10:32, Ram Rachum пише:
On Fri, May 1, 2020 at 10:28 AM Serhiy Storchaka 
> wrote:


Could you please provide a list of these 100 exceptions? If you
create a
PR, with documentation and tests, it would be a good start of the
discussion.


That's not a reasonable request. If there's enough support for this 
idea, then I'll be happy to start working on this, but even then it'll 
be a collaborative effort.


There is nothing to discuss without the subject of discussion.
___
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/J37BHTL3O2XPIBMKTMB3RMORVQUVDVAG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[M.-A. Lemburg]

On 01.05.2020 10:44, Ram Rachum wrote:
> 
> 
> On Fri, May 1, 2020 at 11:37 AM M.-A. Lemburg  > wrote:
> 
> Hi Ram,
> 
> I think you are confusing the exception type with the exception
> reason.
> 
> 
> Some time ago `ModuleNotFoundError` was added as a subclass of
> `ImportError`, which I really liked. Was this also another instance of a
> confusion between the exception type and the exception reason?

No, because the ImportError can actually mean a lot of things (the
import machinery being rather complex) and you will want to be able to
catch the error situation where the module is not installed, rather
than e.g. an error which happened while loading an installed module.
> By adding 100 more exception types, you don't make things
> easier, but instead you complicate things, since we'd all have
> to memorize those 100 exception types.
> 
> 
> Why would you have to memorize them? If you're writing an except clause,
> you could still write `except ValueError:` and it'll work the same as
> before.
> 
> Do you feel that the addition of `ModuleNotFoundError` meant that you
> now had to memorize a new exception?

Sure, because I would not know that this is actually a subclass of
ImportError.

The hierarchy already has quite a few exeption types and it's not
always clear that one type is subclass of another:

https://docs.python.org/3/library/exceptions.html#exception-hierarchy

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 01 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
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/22PK2OB6QHMNJUAMKO4ERVISOIGSMKTK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Steven D'Aprano]

Is "100 more exceptions" hyperbole? Or do you actually mean precisely 
one hundred more exceptions?


On Fri, May 01, 2020 at 09:48:21AM +0300, Ram Rachum wrote:

[...]
> I know it'll raise a ValueError, because I've memorized that, but it did
> take me a few years to remember where I should expect ValueError and where
> I should expect TypeError.

If it took you a few years to learn that ValueError is raised for bad 
values, and TypeError for bad types, then it would probably take you 
three or four hundred years to memorise an additional 100 exceptions and 
their spellings.

"Is it UnpackingOverflowException or PackingUnderflowError or 
TooManyValuesUnpackException or ValueUnpackingError or ...???"

It took me far too long to learn the difference between 
UnicodeEncodingError and UnicodeDecodingError. Or is it 
UnicodeEncodeError and UnicodeDecodeError?

It is possible to have too many fine-grained errors as well as too 
few.


[...]
> Similarly, if I did this:
> 
> >>> def f(x, y): return x + y
> >>> f(1)
> 
> I would get a TypeError. Would be a lot cooler if I got
> MissingArgumentsError, which would be a subclass of SignatureError, which
> would be a subclass of TypeError.

This is an idea I could get behind:

https://mail.python.org/archives/list/python-ideas@python.org/message/MXPCNEAWXWJPOHB3DC3QW3S3ZPOFSM4Q/


> There are 2 reasons I want this:
> 
> 1. When I'm writing a try..except clause, I want to catch a specific
> exception like MissingArgumentsError rather than ValueError or TypeError.
> They're too ubiquitous. I don't want some other unexpected failure
> producing the same ValueError and triggering my except clause.

Best practice is to put try...except around only a *single* operation 
which may raise what you want to catch. Of course that's easier said 
than done, especially since nearly anything can raise nearly anything. 
But in practice, it is surprisingly more practical than it sounds in 
theory.


> 2. When I get an error, especially from some shitty corporate system that
> truncates the traceback, I want to get as many hints as possible about what
> went wrong.

I sympathise, but it's not up to the language to work around the bad 
practices of lousy corporate systems.


> It's true that today, most Python exceptions have good text in their
> message, like "TypeError: f() missing 1 required positional argument: 'y'".
> But that isn't guaranteed everywhere, and specific exception types could
> help.
> 
> 
> What do you think?

I think that speaking generically, being in favour of "better error 
messages" and "more fine-grained exceptions" is like being in favour of 
peace. But the devil is in the details. Peace at what cost?



-- 
Steven
___
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/KUC5A6W2T5Y4TJMYG4KH4CTPRQAYY4FD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Ram Rachum]

On Fri, May 1, 2020 at 12:28 PM Steven D'Aprano  wrote:

> Is "100 more exceptions" hyperbole? Or do you actually mean precisely
> one hundred more exceptions?
>

It is hyperbole.

I should have realized that the way I phrased it was provocative. Maybe
people would have responded better if I put more thought into that...
100 is an arbitrary number of course. I gave a few specific examples
of UnpackingUnderflowError and MissingArgumentsError, and if I spent 30
minutes on it I could probably come up with 10 more examples. The point
isn't the specific example, but to advocate for a general strategy of
breaking down exception to as many classes as possible, instead of having
this fight over and over again on each exception.



> This is an idea I could get behind:
>
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/MXPCNEAWXWJPOHB3DC3QW3S3ZPOFSM4Q/


Alex sent me that, I'm happy to see it :)
___
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/CQKEPB27BU7QJWNBTDO7NKPINUSJUHYK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Peter Otten]

M.-A. Lemburg wrote:

> Hi Ram,
> 
> I think you are confusing the exception type with the exception
> reason. By adding 100 more exception types, you don't make things
> easier, but instead you complicate things, since we'd all have
> to memorize those 100 exception types.
> 
> That said, enhancing the error reasons texts is certainly something
> that would help everyone.
> 
> Adding more exception types to the stack makes sense when there's
> a dedicated need to catch only specific sub types, but even there
> it's already possible to add this extra information to the exception
> objects as e.g. .errno or similar attribute.

There is prior art, though, specifically for errno:

$ python2 -c 'open("not-there")'
Traceback (most recent call last):
  File "", line 1, in 
IOError: [Errno 2] No such file or directory: 'not-there'
$ python3 -c 'open("not-there")'
Traceback (most recent call last):
  File "", line 1, in 
FileNotFoundError: [Errno 2] No such file or directory: 'not-there'

I very much prefer the specific exception because most of the time I only 
want to handle the common problems. Instead of

try:
   open file
except OSError as err:
   if err.errno == what was file-not-found? ah ENOENT:
  # deal with it
   elif err.errno == what was is-a-directory? ah EISDIR:
  # deal with it
   else:
  # give up
  raise

I can now write

try:
open file
except FileNotFoundError:
# deal with it
except IsADirectoryError:
# deal with it

which (a) looks better to me and (b) is easier to remember. It's a bit like 
Guido's advice to use distinct functions instead of flags.

I am sure that I would quickly adopt more specific exceptions in other areas 
(most notably HTTPError). I don't think they all need to become built-ins. 
___
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/JF7WXRP6IEJCZDIUTVHGIRAAYM24SEAN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Steven D'Aprano]

On Fri, May 01, 2020 at 11:36:40AM +0300, Ram Rachum wrote:
> I thought of a third advantage to this approach: Except clauses will be
> easier to understand.
> 
> If I'm reading someone's code and I see `except ValueError`, I'm gonna have
> to do a bit of thinking to figure out what exactly they're catching.

You say that as if that's a bad thing. Except in the most blindingly 
obvious and simple cases, you're going to have to do that anyway. 
Working out what is being caught is not the hard part, unless you abuse 
try...except clauses:

try:
main()
except:
print("an error occurred")

is a classic example of exception misuse. But there are many smaller 
ways to abuse them too.

The hard part is usually figuring out *why* the exception occurred, not 
*what* you are catching.


> On the
> other hand, if the code is `except IntParsingError`, then I know exactly
> what it is they're catching.

Will you? Since I don't know what functions might raise IntParsingError, 
I can't tell what it might have raised it. I mean, sure, it is obviously 
something parsing an int in some sense, but that's pretty wide:

- must it be parsing a string? could it be bytes? 
- parsing a fraction?
- might it be a call to `eval` or `compile` or only `int`?

I think we need to distinguish between the two use-cases for exceptions:

- to halt processing and report an error to the developer;
- to be caught and recovered from.

In this case, I don't think there is any benefit to me, the developer, 
to read:

IntParsingError: invalid literal for int() with base 10: 'a'

over the status quo:

ValueError: invalid literal for int() with base 10: 'a'


and from the perspective of debugging, it's just bloat:

- one more thing to document
- one more thing for the test suite to test
- one more thing to learn
- one more thing to misspell
  (is it IntParsingError or IntParseError or IntParsingException?)
- one more class using up memory
- one more thing for IDEs and syntax colourisers to check for

etc. From the perspective of catching and recovering from errors, again, 
I doubt that there is much benefit to well-written code:

try:
num = int(astring)
except ValueError:
recover()

is fine, changing the ValueError to IntParsingError gains nothing. The 
only advantage I can see is if your try block falls into that very 
narrow zone where it is large enough to contain *exactly* one attempt to 
parse an int *but also* at least one other function call which might 
raise an unrelated ValueError:


try:
a, b = int(astring), float(alist)
except IntParsingError:
...

But I'm not sure that this is valuable enough to make up for the bloat.



-- 
Steven
___
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/ME2GI5SQV5VZM55BDXVE7FVWZNJQCNS2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[André Roberge]

On Fri, May 1, 2020 at 4:34 AM Ram Rachum  wrote:

> On Fri, May 1, 2020 at 10:28 AM Serhiy Storchaka 
> wrote:
>
>> Could you please provide a list of these 100 exceptions? If you create a
>> PR, with documentation and tests, it would be a good start of the
>> discussion.
>>
>
> That's not a reasonable request.
>
If there's enough support for this idea, then I'll be happy to start
> working on this, but even then it'll be a collaborative effort.
>

I believe the first step would be to show that which combination of
current_exception + messages should be split into various new exceptions.

To give a possible concrete example, if you have a look at
https://aroberge.github.io/friendly-traceback-docs/docs/html/tracebacks_en_3.6.html,
you will see that TypeError can have various messages such as:

* must be X not Y  (where X might be str and Y might be list, etc.)
* can only concatenate X (not Y) to X
* unsupported operand type(s) X for: Y and Z
* X not supported between instances of Y and Z
* bad operand type for unary X: Y
* X object does not support item assignment
* X takes Y positional arguments but Z was given
* X missing 2 required positional arguments: Y and Z
* X object is not callable

There are likely many more cases only for TypeError (not to mention other
types of errors.)

Note that there are actual tests for each of these (which is one important
criterion as mentioned by Serhly). (This comment does not mean that I am
not necessarily expressing support for adding many new exception types.)

You're welcome to start collaborating and help document all possible
cases.   This invitation to collaborate is, of course open to all.

André Roberge



> ___
> 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/IVNKPAYM3HT67CMULVUIOT35USUWWW6L/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/YELQDSYP4TAMP3OJ2UP6CRQVHDBA4HVS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Rhodri James]

On 01/05/2020 07:48, Ram Rachum wrote:

There are 2 reasons I want this:

1. When I'm writing a try..except clause, I want to catch a specific
exception like MissingArgumentsError rather than ValueError or TypeError.
They're too ubiquitous. I don't want some other unexpected failure
producing the same ValueError and triggering my except clause.


If you want to catch MissingArgumentsError, you're doing something 
really weird.  I'm trying to think of a realistic example and failing.



2. When I get an error, especially from some shitty corporate system that
truncates the traceback, I want to get as many hints as possible about what
went wrong.


Then you should read the exception reason.  You're still going to have 
to think about what your program logic error is, and a separate 
exception is going to be less use than an explanatory text string.


--
Rhodri James *-* Kynesim Ltd
___
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/4ZKBKMGTVUDL5G5B2ZOCEIYISOBSKAZF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[André Roberge]

On Fri, May 1, 2020 at 10:15 AM Rhodri James  wrote:

> On 01/05/2020 07:48, Ram Rachum wrote:
> > There are 2 reasons I want this:
> >
> > 1. When I'm writing a try..except clause, I want to catch a specific
> > exception like MissingArgumentsError rather than ValueError or TypeError.
> > They're too ubiquitous. I don't want some other unexpected failure
> > producing the same ValueError and triggering my except clause.
>
> If you want to catch MissingArgumentsError, you're doing something
> really weird.  I'm trying to think of a realistic example and failing.
>

This type of error is already caught and identified by Python as a
TypeError in at least two different situations with the following (generic)
error messages:

X takes Y positional arguments but Z was given

X missing 2 required positional arguments: Y and Z

The fact that two such messages exist is indicative that this type of error
do occur in realistic code.

So, in theory, one could think of extracting these two subcases of
TypeError into a new exception subclass; personnally, I think that the
current error messages are sufficient and adding a new exception subclass
for them would just make the exception handling code more complicated than
necessary.

André Roberge

>
> > 2. When I get an error, especially from some shitty corporate system that
> > truncates the traceback, I want to get as many hints as possible about
> what
> > went wrong.
>
> Then you should read the exception reason.  You're still going to have
> to think about what your program logic error is, and a separate
> exception is going to be less use than an explanatory text string.
>
> --
> Rhodri James *-* Kynesim Ltd
> ___
> 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/4ZKBKMGTVUDL5G5B2ZOCEIYISOBSKAZF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/OER543LOXANLUUBUYSLKNBYO6EXYJIFA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Soni L.]

On 2020-05-01 3:48 a.m., Ram Rachum wrote:

Hi,

Here's something I wanted in Python for many years. If this has been 
discussed in the past, please refer me to that discussion.


On one hand, it's something that I can't imagine the python-dev 
community supporting. On the other hand, it would maintain backward 
compatibility.


I wish there were a 100 more built-in exceptions in Python, that will 
be very specific about what went wrong.


If I do this:

    >>> x, y = range(3)

I know it'll raise a ValueError, because I've memorized that, but it 
did take me a few years to remember where I should expect ValueError 
and where I should expect TypeError.


It would be nice if the operation above raised UnpackingOverflowError, 
which will be a subclass of UnpackingError, along with 
UnpackingUnderflowError. UnpackingError can be a subclass of 
ValueError, for backward compatibility.


oh yes please let me distinguish the exception from the unpacking and 
the exception from the iterator


def foo():
  yield from ()
  raise ValueError

it = foo()
try:
  x, y = it
except ValueError:
  print("Is this a problem with the unpacking or a problem with the 
generator?")

  raise

also please have unpacking wrap any UnpackingError from the generator 
into a RuntimeError.




Similarly, if I did this:

    >>> def f(x, y): return x + y
    >>> f(1)

I would get a TypeError. Would be a lot cooler if I got 
MissingArgumentsError, which would be a subclass of SignatureError, 
which would be a subclass of TypeError.


There are 2 reasons I want this:

1. When I'm writing a try..except clause, I want to catch a specific 
exception like MissingArgumentsError rather than ValueError or 
TypeError. They're too ubiquitous. I don't want some other unexpected 
failure producing the same ValueError and triggering my except clause.


2. When I get an error, especially from some shitty corporate system 
that truncates the traceback, I want to get as many hints as possible 
about what went wrong.


It's true that today, most Python exceptions have good text in their 
message, like "TypeError: f() missing 1 required positional argument: 
'y'". But that isn't guaranteed everywhere, and specific exception 
types could help.



What do you think?


Ram.

___
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/XZXWXICKS2RCQLLX73NJOWCJPRY7IUX2/
Code of Conduct: http://python.org/psf/codeofconduct/


___
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/LK5QSTJCABDGH72333T7GFRF3DWMW36O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[M.-A. Lemburg]

On 01.05.2020 11:40, Peter Otten wrote:
> M.-A. Lemburg wrote:
> 
>> Hi Ram,
>>
>> I think you are confusing the exception type with the exception
>> reason. By adding 100 more exception types, you don't make things
>> easier, but instead you complicate things, since we'd all have
>> to memorize those 100 exception types.
>>
>> That said, enhancing the error reasons texts is certainly something
>> that would help everyone.
>>
>> Adding more exception types to the stack makes sense when there's
>> a dedicated need to catch only specific sub types, but even there
>> it's already possible to add this extra information to the exception
>> objects as e.g. .errno or similar attribute.
> 
> There is prior art, though, specifically for errno:
> 
> $ python2 -c 'open("not-there")'
> Traceback (most recent call last):
>   File "", line 1, in 
> IOError: [Errno 2] No such file or directory: 'not-there'
> $ python3 -c 'open("not-there")'
> Traceback (most recent call last):
>   File "", line 1, in 
> FileNotFoundError: [Errno 2] No such file or directory: 'not-there'

Yes, and the reason for having those is that you will want to
often catch those exceptions in applications in a platform independent
way. That doesn't apply to all OS errors, though.

As with all great new features, a case has to be made why an
addition is necessary, what the benefits and drawbacks are and
why we should force millions of Python programmers to learn about
the addition.

Note that we're talking about the Python core, not an application
or Python package from PyPI. Those can, of course, define their own
exceptions and hierarchies.

I assume Ram was testing waters here... just to get an idea of what
it takes for such a change to go in, please see the PEP for the
OS/IO exception hierarchy changes:

https://www.python.org/dev/peps/pep-3151/

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 01 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
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/OYLCV4XDIMHRBCUQNCHCM3Z5YWJZTJCI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Dan Sommers]

On Fri, 1 May 2020 10:21:22 -0300
André Roberge  wrote:

> On Fri, May 1, 2020 at 10:15 AM Rhodri James  wrote:
> 
> > On 01/05/2020 07:48, Ram Rachum wrote:
> > > There are 2 reasons I want this:
> > >
> > > 1. When I'm writing a try..except clause, I want to catch a specific
> > > exception like MissingArgumentsError rather than ValueError or TypeError.
> > > They're too ubiquitous. I don't want some other unexpected failure
> > > producing the same ValueError and triggering my except clause.
> >
> > If you want to catch MissingArgumentsError, you're doing something
> > really weird.  I'm trying to think of a realistic example and failing.
> >
> 
> This type of error is already caught and identified by Python as a
> TypeError in at least two different situations with the following (generic)
> error messages:
> 
> X takes Y positional arguments but Z was given
> 
> X missing 2 required positional arguments: Y and Z
> 
> 
> The fact that two such messages exist is indicative that this type of
> error do occur in realistic code.

"Realistic code"?  Those are both effectively syntax (i.e., compile
time) errors, and should be caught way before any code hits the street.
I agree with Rhodri:  if you're catching these errors at runtime, then
you're doing something really weird.  (And I agree with others:  if
you're catching these errors in a REPL or in unit tests, then you're
going to have to think about how to fix the problem regardless of the
label of the exception.)

(Well, if I use my imagination:  someone else is in control of your
environment, and they pulled in a new version of some library that
doesn't care about backwards compatility, and suddenly the runtime
behavior of your otherwise tested and debugged code is now failing.  But
that hardly seems like a common scenario.)

(Or maybe you're trying to build a genetic code generator and/or
debugger, and it's easier on your software to "guide" the evolution if
more information is encoded in the type of the exception rather than in
a human readable message.  But that also seems rather unlikely.)

Dan

-- 
“Atoms are not things.” – Werner Heisenberg
Dan Sommers, http://www.tombstonezero.net/dan
___
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/3AVTHZGUXVIVSDTNUV7TZ2WVU5CHRQ5Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Eric V. Smith]

On 5/1/2020 9:21 AM, André Roberge wrote:



On Fri, May 1, 2020 at 10:15 AM Rhodri James > wrote:


On 01/05/2020 07:48, Ram Rachum wrote:
> There are 2 reasons I want this:
>
> 1. When I'm writing a try..except clause, I want to catch a specific
> exception like MissingArgumentsError rather than ValueError or
TypeError.
> They're too ubiquitous. I don't want some other unexpected failure
> producing the same ValueError and triggering my except clause.

If you want to catch MissingArgumentsError, you're doing something
really weird.  I'm trying to think of a realistic example and failing.


This type of error is already caught and identified by Python as a 
TypeError in at least two different situations with the following 
(generic) error messages:


X takes Y positional arguments but Z was given

X missing 2 required positional arguments: Y and Z

The fact that two such messages exist is indicative that this type of 
error do occur in realistic code.


So, in theory, one could think of extracting these two subcases of 
TypeError into a new exception subclass; personnally, I think that the 
current error messages are sufficient and adding a new exception 
subclass for them would just make the exception handling code more 
complicated than necessary.


But the question is: why would you actually catch these different 
exception types, and what would you do when you caught them? There's 
actual code that checked for errno on an IOError, which is why it was 
easy to say that adding FileNotFoundError, etc. would be an improvement. 
Where's the code that catches (or wants to catch) MissingArgumentsError?


I do think that every exception subclass that anyone wants to add is 
going to go through a case-by-case scrutiny. We're not just going to say 
"let's add a lot more exceptions!".


Eric



André Roberge


> 2. When I get an error, especially from some shitty corporate
system that
> truncates the traceback, I want to get as many hints as possible
about what
> went wrong.

Then you should read the exception reason.  You're still going to
have
to think about what your program logic error is, and a separate
exception is going to be less use than an explanatory text string.

-- 
Rhodri James *-* Kynesim Ltd

___
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/4ZKBKMGTVUDL5G5B2ZOCEIYISOBSKAZF/
Code of Conduct: http://python.org/psf/codeofconduct/


___
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/OER543LOXANLUUBUYSLKNBYO6EXYJIFA/
Code of Conduct: http://python.org/psf/codeofconduct/
___
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/K5ABN2MQNBSZNSNYAJVQD2WE7RDLY6P7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Christopher Barker]

On Fri, May 1, 2020 at 1:38 AM M.-A. Lemburg  wrote:

> Adding more exception types to the stack makes sense when there's
> a dedicated need to catch only specific sub types, but even there
> it's already possible to add this extra information to the exception
> objects as e.g. .errno or similar attribute.
>

Maybe it's too late for this, but I would love it if ".errno or similar"
were more standardized. As it is, every exception may have it's own way to
find out more about exactly what caused it, and often you are left with
parsing the message if you really want to know.

Honestly, I've never written production code that does that -- but I don't
think that's because there's no need for it, but because, well, parsing an
error message is pretty painful, and just seems "wrong".

I'm not sure how this could reasonably work, but maybe we could standardize
that all Exceptions have an .errno attribute, and a standard mapping
between the errorno and a message, or, 

Even if most Exceptions would have only a single error number, this would
be a standardized way to add extra info to any Exception.

And frankly I've always thought it odd that the way to get the message was
to grab the first element in .args -- it's a defacto standard, but wouldn't
it be better to make it a actual standard?

Not well thought out, but this may be a way to address Ram's issues, while
not massively cluttering up the Exception namespace.

NOTE: I'm not sure where I come down on this, but having to "memorize" a
bunch more exceptions does not concern me in the least. I pretty much
always write code or tests that trigger the Exception I'm going to catch to
make sure I've got the right one anyway. Sure, I'm pretty familiar with
ValueError and TypeError, but there are a lot more than I can keep in my
brain at one time anyway, and I need to spell it right, and all that.

The one complication I DO see to this approach is that we'd have a lot of
Exceptions that were subclasses of more general ones, and when you see it,
it would not be obvious what the hierarchy is, so folks would tend to use
the fine-grained exception over the more general one, even if that wasn't
appropriate.

-CHB



-- 
Christopher Barker, PhD

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/VRFFIGLKVXWHK3SRCAYNPF3PCABKPSGN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[André Roberge]

On Fri, May 1, 2020 at 1:24 PM Christopher Barker 
wrote:

> On Fri, May 1, 2020 at 1:38 AM M.-A. Lemburg  wrote:
>
>> Adding more exception types to the stack makes sense when there's
>> a dedicated need to catch only specific sub types, but even there
>> it's already possible to add this extra information to the exception
>> objects as e.g. .errno or similar attribute.
>>
>
> Maybe it's too late for this, but I would love it if ".errno or similar"
> were more standardized. As it is, every exception may have it's own way to
> find out more about exactly what caused it, and often you are left with
> parsing the message if you really want to know.
>
> Honestly, I've never written production code that does that -- but I don't
> think that's because there's no need for it, but because, well, parsing an
> error message is pretty painful, and just seems "wrong".
>
> I'm not sure how this could reasonably work, but maybe we could
> standardize that all Exceptions have an .errno attribute, and a standard
> mapping between the errorno and a message, or, 
>
>
+100

With the exception of the obscure "SyntaxError: Invalid syntax", this would
make it really easy to provide translations of error messages in other
languages (or in "beginner friendly English") as I'm slowly doing with
friendly-traceback.

André Roberge
___
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/MN6XX4H76UJZV3UJGHVW4LKTBCAQFXDY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Andrew Barnert via Python-ideas]

On May 1, 2020, at 09:24, Christopher Barker  wrote:
> 
> Maybe it's too late for this, but I would love it if ".errno or similar" were 
> more standardized. As it is, every exception may have it's own way to find 
> out more about exactly what caused it, and often you are left with parsing 
> the message if you really want to know.

I don’t think there are many cases where a standardized .errno would help—and I 
think most such cases would be better served by separate exceptions. With 
OSError, errno was a problem to be fixed, not an ideal solution to emulate 
everywhere.

You do often need to be able to get more information, and that is a problem, 
but I think it usually needs to be specific to each exception, not something 
generic.

Does code often need to distinguish between an unpacking error and an int 
parsing error? If so, you should be able to handle UnpackingError and 
IntParsingError, not handle ValueError and check an .errno against some set of 
dozens of new builtin int constants. If not, then we shouldn’t change anything 
at all.

As for parsing the error message, that usually comes up because there’s 
auxiliary information that you need but that isn’t accessible. For example, in 
2.x, to get the filename that failed to open, you had to regex .args[0], and 
that sucked. But the fix was to add a .filename to all of the relevant 
exceptions, and now it’s great. If you need to be able to get the failing 
string for int(s) raising a ValueError today, you have to regex .args[0], and 
that sucks. Do people actually need to do that? If so, there should be a 
.string or something that carries that information; an .errno won’t help.

It seems like every year or two, someone suggests that we should go through the 
stdlib and fix all the exceptions to be reasonably distinguishable and to make 
their relevant information more accessible, and I don’t think anyone ever has a 
problem with that, it’s just that nobody’s ever willing to volunteer to survey 
every place a builtin or stdlib raises, list them all, and work out exactly 
what should be changed and where.
___
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/CZP5RDQGWAXS4QQ3BHVNRT4VBXVP2Z3Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Ethan Furman]

On 05/01/2020 02:19 AM, Steven D'Aprano wrote:


Best practice is to put try...except around only a *single* operation
which may raise what you want to catch. Of course that's easier said
than done, especially since nearly anything can raise nearly anything.


The follow-on to that is to only catch what you can recover from.


But in practice, it is surprisingly more practical than it sounds in
theory.


Since not every problem can be recovered from and therefore shouldn't be caught.

--
~Ethan~
___
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/6ZCLS3X6BTHVFR5FRZAMT573GQLSLI6W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Christopher Barker]

On Fri, May 1, 2020 at 12:28 PM Andrew Barnert  wrote:

> > Maybe it's too late for this, but I would love it if ".errno or similar"
> were more standardized. As it is, every exception may have it's own way to
> find out more about exactly what caused it, and often you are left with
> parsing the message if you really want to know.
>
> I don’t think there are many cases where a standardized .errno would
> help—and I think most such cases would be better served by separate
> exceptions. With OSError, errno was a problem to be fixed, not an ideal
> solution to emulate everywhere.
>

I will note that wrote is response to someone else suggesting that that was
the solution to the OP's problem. If the "policy" is that some information
should be tacked on to a fairly generic exception, rather than crating a
bunch of subclasses if that exception, then I'm suggesting that there
should be a standardized way to do that.


> You do often need to be able to get more information, and that is a
> problem, but I think it usually needs to be specific to each exception, not
> something generic.
>

but does that mean there can't be a more standardized way to "add more
information" maybe not -- I can't say I've thougth deeply about it, but we
could go ONE step better: as far as I can tell, the only thing at all a
standard is the exceptions all have a .args attribute wich is a tuple of
??? IN practic,e the zeroth element of that tuple is the "Error Message",
but it could be any old thing.

Python2 DID have a .message attribute -- I guess I should go look and find
documentation for the reasoning behind that, but it does seem like a step
backwards to me.

As for parsing the error message, that usually comes up because there’s
> auxiliary information that you need but that isn’t accessible. For example,
> in 2.x, to get the filename that failed to open, you had to regex .args[0],
> and that sucked. But the fix was to add a .filename to all of the relevant
> exceptions, and now it’s great. If you need to be able to get the failing
> string for int(s) raising a ValueError today, you have to regex .args[0],
> and that sucks. Do people actually need to do that? If so, there should be
> a .string or something that carries that information; an .errno won’t help.
>

but it does seem like this could be a bit more standardized. in those two
cases, you have the data passed in that caused the failure -- could they
bwoth use .input_value or something? Maybe it's better to have a
use-specific name, maybe not.

I'm not going to be able to motivate this well, so I should probably just
stop until/unless I get some more time to dig back in my archives and find
examples when this was an issue, but I know that every time I've wanted a
bit more info from an Exception, I realized that .args is the ONLY standard
place for any info -- and thought "really?"

It seems like every year or two, someone suggests that we should go through
> the stdlib and fix all the exceptions to be reasonably distinguishable and
> to make their relevant information more accessible, and I don’t think
> anyone ever has a problem with that, it’s just that nobody’s ever willing
> to volunteer to survey every place a builtin or stdlib raises, list them
> all, and work out exactly what should be changed and where.
>

Probably so, but it seems that no one's going to do that work unless they
think it will be accepted -- kin dof like how Ram proposed this in vague
and hyperbolic terms, rather than providing a big list of all the places he
thought needed improvement.

But it seems clear that "doing a big revamp if all the Exceptions and
adding alot more subclasses" is not supported. Which doesn't means that a
few more expansions wouldn't be excepted.

So folks that like this idea may be best served by finding the lowest
hanging fruit, and suggesting jsut a few.

-CHB






-- 
Christopher Barker, PhD

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/OML342YY3CJPVE7YLHDXIQUMAES6SEX4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Steven D'Aprano]

On Fri, May 01, 2020 at 12:28:02PM -0700, Andrew Barnert via Python-ideas wrote:
> On May 1, 2020, at 09:24, Christopher Barker  wrote:
> > 
> > Maybe it's too late for this, but I would love it if ".errno or similar" 
> > were more standardized. As it is, every exception may have it's own way to 
> > find out more about exactly what caused it, and often you are left with 
> > parsing the message if you really want to know.
> 
> I don’t think there are many cases where a standardized .errno would help—and 
> I think most such cases would be better served by separate exceptions. With 
> OSError, errno was a problem to be fixed, not an ideal solution to emulate 
> everywhere.
> 
> You do often need to be able to get more information, and that is a problem, 
> but I think it usually needs to be specific to each exception, not something 
> generic.
> 
> Does code often need to distinguish between an unpacking error and an int 
> parsing error? If so, you should be able to handle UnpackingError and 
> IntParsingError, not handle ValueError and check an .errno against some set 
> of dozens of new builtin int constants. If not, then we shouldn’t change 
> anything at all.
> 
> As for parsing the error message, that usually comes up because 
> there’s auxiliary information that you need but that isn’t accessible. 
> For example, in 2.x, to get the filename that failed to open, you had 
> to regex .args[0], and that sucked.

Why would you parse the error message when you already have the 
file name?

try:
 f = open(filename)
except IOError as err:
 print(filename)

I'm trying to think of a case where you might be making a call to open 
but you don't know the filename.

I thought it might be if you pass a file descriptor, but in that case 
the filename attribute seems to be set to None.


> It seems like every year or two, someone suggests that we should go 
> through the stdlib and fix all the exceptions to be reasonably 
> distinguishable and to make their relevant information more 
> accessible, and I don’t think anyone ever has a problem with that, 

I do!

Christopher's proposal of a central registry of error numbers and 
standardised error messages just adds a lot more work to every core 
developer for negligible or zero actual real world benefit.

When I want to raise something in the stdlib, I just raise:

# let's say I add a kurtosis function
raise StatisticsError('not enough data points for kurtosis')

Under Christopher's proposal, I have to:

* look up the central registry;
* find the next ID unused number;
* register it to my library and error message;
* use the relevent errno and the same error message in my code:

# something like this?
raise StatisticsError('not enough data points for kurtosis', errno=926361)

and while I'm doing that, one of the faster and more productive core 
devs have come along and used that errno before I could merge my patch, 
so now I have to change the errno.

And then if I decide to improve the error message, what now? Do I have 
to register a new errno? What if the error message is variable?

Expected at least 4 data points, but got 2.

And the benefit of this is ... what? I'd like to see the real-world 
concrete benefit that couldn't be more easily accomplished by using a 
separate try...except around *only* the call to kurtosis:

try:
k = kurtosis(data)
except StatisticsError:
# This can only mean one thing: not enough data.
k = None


I'm sorry to anyone who likes to use a single try around many 
computations:

try:
xm = mean(ydata)
ym = mean(ydata)
xsd = stdev(xdata)
ysd = stdev(ydata)
except StatisticsError as err:
# How do I distinguish which call failed?

but supporting that is not something I'm prepared to do until either I 
need that functionality myself or somebody provides a really compelling 
use-case, not just "it would be cool if..." :-)



-- 
Steven
___
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/NE443NATMWLVZK2QS5BO6EM3DDDPXL2D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Andrew Barnert via Python-ideas]

> On May 1, 2020, at 14:34, Christopher Barker  wrote:
> 
> But it seems clear that "doing a big revamp if all the Exceptions and adding 
> alot more subclasses" is not supported. Which doesn't means that a few more 
> expansions wouldn't be excepted. 
> 
> So folks that like this idea may be best served by finding the lowest hanging 
> fruit, and suggesting jsut a few.

I think you’re right. It _might_ be accepted if someone did the work, but it’s 
probably a lot easier to get separate small changes with solid use cases in one 
by one. As long as you’re not being sneaky and pretending like you don’t have a 
master plan, and each of the changes is convincing, I think they’d have a much 
better chance. And there ought to be good use cases for “these builtin parse 
functions should have a .string with the input that failed so you don’t have to 
regex it out of the message” or “I need to distinguish this one kind of 
ValueError from all the other kinds” or whatever; a lot easier to argue for 
those use cases than something abstract and general. 

And almost any way it turns out seems like a win. Even if they all get 
rejected, better to know you were on the wrong track early rather than after a 
hundred hours of work. Or if it turns out to be more work than you expected and 
you get sick of doing it, at least you’ve improved some of the most important 
cases. Or maybe you’d just keep doing it and people just keep saying “fine”. Or 
maybe someone says, “Hold on, another one of these? They’re all good on their 
own, but shouldn’t we have some master plan behind it all?” and then you can 
point back to the master plan you posted in this thread that nobody wanted to 
read at the time, and now they’ll want to read it and start bikeshedding. :)

(By “you” here I don’t mean you, Christopher; I mean Ram, or whoever else wants 
to do all this work.)

By the way:

> Python2 DID have a .message attribute -- I guess I should go look and find 
> documentation for the reasoning behind that, but it does seem like a step 
> backwards to me.

In 2.6 and 2.7, it’s undocumented, and should always be either the same thing 
__str__ returns or the empty string. So, not particularly useful.

I believe it exists as a consequence of the first time someone suggested “let’s 
clean up all the exceptions” but then that cleanup didn’t get started.

It was added in 2.5, along with a planned deprecation of args, and a new rule 
for __str__ (return self.message instead of formatting self.args), and a new 
idiom for how newly-written exception classes should super: don’t pass *args, 
pass a single formatted string; anything worth keeping around for users is 
worth storing in a nicely named attribute the way SyntaxError and IOError 
always have. And Py3000 was going to change all the existing exceptions to use 
that new idiom. But that never happened, and 2.6 and 3.0 basically went back to 
2.4: there’s no mention of message at all, args isn’t going to be deprecated, 
the rule for __str__ is the old one, etc.

There are more custom attributes on more exceptions than there used to be, but 
they seem to mostly have grown on a case by case basis (and mostly on brand new 
exceptions) rather than in one fell swoop. Which implies that you were right 
about the best way to get anything done.

___
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/ODSM2MPGCQPPOMB4V5Q2BQFROLTP6KR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Andrew Barnert via Python-ideas]

On May 1, 2020, at 16:32, Steven D'Aprano  wrote:
> 
> On Fri, May 01, 2020 at 12:28:02PM -0700, Andrew Barnert via Python-ideas 
> wrote:
>>> On May 1, 2020, at 09:24, Christopher Barker  wrote:
>>> Maybe it's too late for this, but I would love it if ".errno or similar" 
>>> were more standardized. As it is, every exception may have it's own way to 
>>> find out more about exactly what caused it, and often you are left with 
>>> parsing the message if you really want to know.
>> I don’t think there are many cases where a standardized .errno would 
>> help—and I think most such cases would be better served by separate 
>> exceptions. With OSError, errno was a problem to be fixed, not an ideal 
>> solution to emulate everywhere.
>> You do often need to be able to get more information, and that is a problem, 
>> but I think it usually needs to be specific to each exception, not something 
>> generic.
>> Does code often need to distinguish between an unpacking error and an int 
>> parsing error? If so, you should be able to handle UnpackingError and 
>> IntParsingError, not handle ValueError and check an .errno against some set 
>> of dozens of new builtin int constants. If not, then we shouldn’t change 
>> anything at all.
>> As for parsing the error message, that usually comes up because
>> there’s auxiliary information that you need but that isn’t accessible.
>> For example, in 2.x, to get the filename that failed to open, you had
>> to regex .args[0], and that sucked.
> 
> Why would you parse the error message when you already have the 
> file name?
> 
>   try:
>f = open(filename)
>   except IOError as err:
>print(filename)

   try:
   config = parse_config()
   except IOError as err:
   print(filename)

You can’t get the local variable out of some other function that you called, 
even with frame hacking.

At any rate, it’s a bit silly to relitigate this change. All of the new IOError 
subclasses where a filename is relevant have had a filename attribute since 
3.0, so this problem has been solved for over a decade. If you really prefer 
the 2.x situation where sometimes those exception instances had the filename 
and sometimes not, you’ll need a time machine.

>> It seems like every year or two, someone suggests that we should go
>> through the stdlib and fix all the exceptions to be reasonably
>> distinguishable and to make their relevant information more
>> accessible, and I don’t think anyone ever has a problem with that,
> 
> I do!
> 
> Christopher's proposal of a central registry of error numbers and 
> standardised error messages just adds a lot more work to every core 
> developer for negligible or zero actual real world benefit.

You’re replying to a message saying “errno was a problem to be fixed, not an 
ideal solution to emulate” and likewise having to parse errors. And you’re 
insisting that you disagree because adding errno and standardizing messages so 
they could be parsed would be a problem for maintainers as well as for users. 
Sure, you’re right, but that’s not in any way an argument against Ram’s 
proposal, or against the paragraph you quoted; if anything, it’s an argument 
*for* it.

___
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/EESMDX2YO5KAIQQVVSSNKSTKTOYMSNH2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Steven D'Aprano]

On Fri, May 01, 2020 at 06:59:01PM -0700, Andrew Barnert wrote:

> >> For example, in 2.x, to get the filename that failed to open, you had
> >> to regex .args[0], and that sucked.
> > 
> > Why would you parse the error message when you already have the 
> > file name?
> > 
> >   try:
> >f = open(filename)
> >   except IOError as err:
> >print(filename)
> 
>try:
>config = parse_config()
>except IOError as err:
>print(filename)

That's not a very convincing example, because surely if you are logging 
the error, or reporting it to the user, you need the entire error 
message. As a user, what am I to make of this?

/tmp/z

when you could show me this instead?

FileNotFoundError: [Errno 2] No such file or directory: '/tmp/z'

I might also argue that this is a poorly designed parse_config function 
for many reasons, but it's obvious to me that you intended it as only a 
toy example to match my toy example, not real-world code.

But that's the thing, there are many things which seem compelling when 
you only look at toy examples, but in real-world code they become less 
useful. For example, in a real-world config system, you probably have 
"read_config" try a series of multiple file names, in some specified 
order, rather than fail, and the config function itself logs the errors 
if you need them logged. Even if none of them are available, you ought 
to return default settings rather than fail.

(I've used applications that die if a config file isn't readable, and 
they are horrible to use. But I digress.)

In the standard library, my quick and dirty grep has found a few uses 
for err.filename in the stdlib:

- ten cases testing that it is set correctly; 
- one place where it appears to be copied from one exception to another;

and unless I've missed anything, that's it. Take from that what you 
will.

So in the spirit of always being open to learning something new, have 
you personally used the err.filename attribute, and if so, under what 
circumstances was it useful to you?



[...]
> At any rate, it’s a bit silly to relitigate this change. 

Was that what I was doing? Whew, thank goodness you told me, now I can 
cancel the PEP I was writing to deprecate and remove that feature! 

*wink*

But seriously... unless it is your position that every functional change 
made to the language and stdlib is by definition optimal, and therefore 
beyond question, I don't think it is "silly" to revist a change made a 
decade ago and see whether it actually turned out to be as useful as we 
hoped, *before* using that change as an example of a successful language 
feature that ought to be copied.

YAGNI is a genuine principle, and I cannot tell you how many times I've 
started custom exceptions and loaded them up with information that I 
surely would need to extract programmatically, only to discover that all 
I really needed was to read the error message. So please forgive me if 
I'm a bit cautious about the suggestion that we must load exceptions up 
with more information.


> All of the 
> new IOError subclasses where a filename is relevant have had a 
> filename attribute since 3.0, so this problem has been solved for over 
> a decade.

Since the filename attribute can be None, you still have to deal with 
the case where the filename is missing. (Even if it is rarer than it 
used to be.)


> If you really prefer the 2.x situation where sometimes those 
> exception instances had the filename and sometimes not, you’ll need a 
> time machine.

Since I've never been in a position where I needed to extract the file 
name from an exception, at least not as far as I can remember, I don't 
think I would care if it was missing or not. YMMV.


> >> It seems like every year or two, someone suggests that we should go
> >> through the stdlib and fix all the exceptions to be reasonably
> >> distinguishable and to make their relevant information more
> >> accessible, and I don’t think anyone ever has a problem with that,
> > 
> > I do!
> > 
> > Christopher's proposal of a central registry of error numbers and 
> > standardised error messages just adds a lot more work to every core 
> > developer for negligible or zero actual real world benefit.
> 
> You’re replying to a message saying “errno was a problem to be fixed, 

Not every obscure OS error should be given its own exception. It is good 
that the most common ones have been, like FileNotFoundError, but for 
rarer and more exotic exceptions, it isn't worth the bloat of adding 50 
exception subclasses which most people will never experience in their 
entire lifetime. So for those, a standard errno works great and I don't 
think it is a problem to be fixed.

In fact, I don't think it was a problem as such, it is just that 
separate exceptions for common failures was *even better*.


> not an ideal solution to emulate” and likewise having to parse errors. 
> And you’re insisting that you disagree because adding errno and 
> standardizing m

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Steven D'Aprano]

On Fri, May 01, 2020 at 09:23:20AM -0700, Christopher Barker wrote:

> I'm not sure how this could reasonably work, but maybe we could standardize
> that all Exceptions have an .errno attribute, and a standard mapping
> between the errorno and a message, or, 
> 
> Even if most Exceptions would have only a single error number, this would
> be a standardized way to add extra info to any Exception.

Okay, I've given this a bit more thought and I think that I have a way 
to make this -- maybe -- practical without having to have a universal 
global registry. There will still be a registry, but it will be per- 
installation, and generated dynamically when exceptions are raised.

Whether it's useful, I don't know. (That's a polite way of saying I 
don't think it is *wink* )

Whenever an exception is instantiated:

ValueError('too many chromions in the neutron flux')

`BaseException` looks for the combination of exception type and 
error message in a per-site database. If they are not already in the DB, 
it generates a new unique number for them. Once the error number is 
generated or retrieved, it is added to the exception instance.

Exceptions like StopIteration will need to opt-out of this costly 
process. That's easy enough: have the `BaseException.__init__` method 
call a public `register` method to do the work. If you want to opt-out, 
just set `register = None` in your class.

If one wanted to be a bit fancier, in a "Do What I Mean" kind of way, we 
could use string similarity rather than equality, so that minor typos 
in the error message won't be considered significant. The downside of 
that is that

ValueError('too many chromions in the neutron flux')
ValueError('too few chromions in the neutron flux')

will probably count as being similar (edit distance of 1 word), which 
you may not want.

Being site-specific, the error numbers won't necessarily correspond 
between one site and the next. So you can't google for error numbers. 
There would have to be some sort of tool for looking them up in the 
database.

I'm not entirely sure what we would do with this error number once you 
have it, but there it is. It was fun to think about.

If anyone wants to experiment with this, you can use a mixin class 
in your exceptions without having to touch BaseException.


-- 
Steven
___
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/FUKGTWQ6WVY756TE5QX6N3OEDVHDD7MK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > It took me far too long to learn the difference between 
 > UnicodeEncodingError and UnicodeDecodingError. Or is it 
 > UnicodeEncodeError and UnicodeDecodeError?

That's why we provide UnicodeNothingInTheMiddleError. ;-)
___
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/ERE5F7J576Q4CLZNBX7Y3MDKSAAL7WZC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Henk-Jaap Wagenaar]

On Fri, 1 May 2020 at 10:29, Steven D'Aprano  wrote:
[...]
> "Is it UnpackingOverflowException or PackingUnderflowError or
> TooManyValuesUnpackException or ValueUnpackingError or ...???"

> It took me far too long to learn the difference between
> UnicodeEncodingError and UnicodeDecodingError. Or is it
> UnicodeEncodeError and UnicodeDecodeError?
>
> It is possible to have too many fine-grained errors as well as too
few.

This is thinking about exceptions and the proposal too simply. When I read
this, I (a) found out that this exception is a built-in so it isn't hard to
find out which is which (any IDE or IPython would help) but more
importantly, looking at their MRO, if you cannot understand the difference,
and you don't have to, you could instead choose to catch UnicodeError
instead (or the combination of both).

However, if you just want to catch encoding errors you can, and this is the
crux of this proposal: allowing similar catches throughout the standard
library as a first class citizen seems sensible to me and I am +1 of this
proposal.
___
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/CGFGNYT3RO64HPCJGZXVVLF2MMK33CGR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Eric V. Smith]

On 5/2/2020 6:00 AM, Henk-Jaap Wagenaar wrote:
On Fri, 1 May 2020 at 10:29, Steven D'Aprano > wrote:

[...]
> "Is it UnpackingOverflowException or PackingUnderflowError or
> TooManyValuesUnpackException or ValueUnpackingError or ...???"

> It took me far too long to learn the difference between
> UnicodeEncodingError and UnicodeDecodingError. Or is it
> UnicodeEncodeError and UnicodeDecodeError?
>
> It is possible to have too many fine-grained errors as well as too
few.

This is thinking about exceptions and the proposal too simply. When I 
read this, I (a) found out that this exception is a built-in so it 
isn't hard to find out which is which (any IDE or IPython would help) 
but more importantly, looking at their MRO, if you cannot understand 
the difference, and you don't have to, you could instead choose to 
catch UnicodeError instead (or the combination of both).


However, if you just want to catch encoding errors you can, and this 
is the crux of this proposal: allowing similar catches throughout the 
standard library as a first class citizen seems sensible to me and I 
am +1 of this proposal.


Please show an example of where you would catch ValueUnpackingError and 
how you'd handle it (recover, re-raise, whatever).


Eric


___
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/I26BBAZY7HP2XFH32FW3WKVPXEAEA6JY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Henk-Jaap Wagenaar]

Of course, there are other ways of writing this code, but imagine this for
a database interface where a save normally returns the saved object
(inspired by Django)

```
try:
x, y = Foo.save()
except ValueUnpackingError:
// oh... this means saving failed (it returned None instead)
// let's return a sensible response
return ExceptionToResponse(FooStateToException(foo.state))
```

Another example would be an interactive session where you expect an
iterable to have 3 entries (say for a 3D space coordinate) and you want to
check this specifically:

```
try:
x, y, z = point
except ValueUnpackingError:
print(f"point has wrong dimension")
```

where point is an instance of:

```
class Point:
def __iter__(self):
return (float(x) for x in self._internal)
```

Can you spot here why ValueError would result in significantly different
behaviour? ValueError will also catch it if point's internal list contains
a bad entry (e.g. a string that does not convert to a float).

Having these exceptions does not take anything away as they can choose the
more general version.

On Sat, 2 May 2020 at 11:12, Eric V. Smith  wrote:

> On 5/2/2020 6:00 AM, Henk-Jaap Wagenaar wrote:
>
> On Fri, 1 May 2020 at 10:29, Steven D'Aprano  wrote:
> [...]
> > "Is it UnpackingOverflowException or PackingUnderflowError or
> > TooManyValuesUnpackException or ValueUnpackingError or ...???"
>
> > It took me far too long to learn the difference between
> > UnicodeEncodingError and UnicodeDecodingError. Or is it
> > UnicodeEncodeError and UnicodeDecodeError?
> >
> > It is possible to have too many fine-grained errors as well as too
> few.
>
> This is thinking about exceptions and the proposal too simply. When I read
> this, I (a) found out that this exception is a built-in so it isn't hard to
> find out which is which (any IDE or IPython would help) but more
> importantly, looking at their MRO, if you cannot understand the difference,
> and you don't have to, you could instead choose to catch UnicodeError
> instead (or the combination of both).
>
> However, if you just want to catch encoding errors you can, and this is
> the crux of this proposal: allowing similar catches throughout the standard
> library as a first class citizen seems sensible to me and I am +1 of this
> proposal.
>
> Please show an example of where you would catch ValueUnpackingError and
> how you'd handle it (recover, re-raise, whatever).
>
> Eric
>
>
> ___
> 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/I26BBAZY7HP2XFH32FW3WKVPXEAEA6JY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/FKHQVRGQFSMZTLZA4NGD2CNZGWQULE7R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Alex Hall]

On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar <
wagenaarhenkj...@gmail.com> wrote:

> Of course, there are other ways of writing this code, but imagine this for
> a database interface where a save normally returns the saved object
> (inspired by Django)
>
> ```
> try:
> x, y = Foo.save()
> except ValueUnpackingError:
> // oh... this means saving failed (it returned None instead)
> // let's return a sensible response
> return ExceptionToResponse(FooStateToException(foo.state))
> ```
>

My concern is that this is risky code. If `Foo.save()` has a bug somewhere
inside (or maybe it calls back to your own code which has a bug) it could
raise `ValueUnpackingError` for different reasons, and then that gets
caught and misleads people into thinking that Foo.save returned None which
leads to all sorts of frustration and confusion.

This code:

```
result = Foo.save()
if result is None:
return ExceptionToResponse(...)
x, y = result
```

is not sexy, but it's explicit, safe, and it targets the real problem
precisely.

Creating these new exceptions would encourage people to write code that
will bite them later.


> Another example would be an interactive session where you expect an
> iterable to have 3 entries (say for a 3D space coordinate) and you want to
> check this specifically:
>
> ```
> try:
> x, y, z = point
> except ValueUnpackingError:
> print(f"point has wrong dimension")
> ```
>
> where point is an instance of:
>
> ```
> class Point:
> def __iter__(self):
> return (float(x) for x in self._internal)
> ```
>

The first example made sense, this is too much of a contrived toy example.
Why would you write that try/except in an interactive session? How does
catching the exception leave you better off than just letting it bubble up
and show you a traceback? What are you going to do after now that x,y,z are
undefined variables? How did you end up with a point of unknown dimension?

Can you spot here why ValueError would result in significantly different
> behaviour? ValueError will also catch it if point's internal list contains
> a bad entry (e.g. a string that does not convert to a float).
>

The solution here is to ensure that the strings are converted to floats
long before iteration, either by Point or by its producer. That's the kind
of solution programmers should look for. Catching exceptions in general
should be a last resort, and making it slightly less wrong may do more harm
than good.
___
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/S5SQF2VSAWX5USG6HLUHEUUL7DE4SBCN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Eric V. Smith]

On 5/2/2020 7:18 AM, Alex Hall wrote:
On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar 
mailto:wagenaarhenkj...@gmail.com>> wrote:


Of course, there are other ways of writing this code, but imagine
this for a database interface where a save normally returns the
saved object (inspired by Django)

```
try:
    x, y = Foo.save()
except ValueUnpackingError:
    // oh... this means saving failed (it returned None instead)
    // let's return a sensible response
    return ExceptionToResponse(FooStateToException(foo.state))
```


My concern is that this is risky code. If `Foo.save()` has a bug 
somewhere inside (or maybe it calls back to your own code which has a 
bug) it could raise `ValueUnpackingError` for different reasons, and 
then that gets caught and misleads people into thinking that Foo.save 
returned None which leads to all sorts of frustration and confusion.


This code:

```
result = Foo.save()
if result is None:
    return ExceptionToResponse(...)
x, y = result
```

is not sexy, but it's explicit, safe, and it targets the real problem 
precisely.


Creating these new exceptions would encourage people to write code 
that will bite them later.


I agree that we don't want to encourage code like the above example with 
catching the hypothetical ValueUnpackingError. I contend that even if we 
added ValueUnpackingError, no one would ever write code that used it, 
but should instead do what they do now: unpack it after checking it (as 
Alex's example shows). Of course, that's a horrible API, but sometimes 
you have to call horrible APIs. The fact that the API is bad doesn't 
mean we should add a way to handle it poorly.


The only reason I'd want it to exist (and I don't) is to see it in the 
REPL. But for that, there's the exception message and the traceback, so 
a unique exception for this would be useless to me.



Another example would be an interactive session where you expect
an iterable to have 3 entries (say for a 3D space coordinate) and
you want to check this specifically:

```
try:
    x, y, z = point
except ValueUnpackingError:
    print(f"point has wrong dimension")
```

where point is an instance of:

```
class Point:
    def __iter__(self):
        return (float(x) for x in self._internal)
```


The first example made sense, this is too much of a contrived toy 
example. Why would you write that try/except in an interactive 
session? How does catching the exception leave you better off than 
just letting it bubble up and show you a traceback? What are you going 
to do after now that x,y,z are undefined variables? How did you end up 
with a point of unknown dimension?


Can you spot here why ValueError would result in
significantly different behaviour? ValueError will also catch it
if point's internal list contains a bad entry (e.g. a string that
does not convert to a float).

I've never caught an exception in the REPL. And even if I wanted to, 
like the other examples above, you'd want to put the exception around 
the smallest possible piece of code. What if the each "x" above was an 
instance of something whose __float__() might raise ValueUnpackingError?


class X:
    def __float__(self):
    a, b = [3.0]
    return a

You'd be catching a ValueUnpackingError, but the wrong one. Just adding 
ever finer-grained exception classes doesn't solve any of the problems 
I've seen given in this thread. That's not to say improvement is 
impossible, but it will need to be on a case-by-case basis, with 
examples that show an actual improvement.


Eric


___
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/7K6O6Z3OTXTTO52SBZLFT3H6SIKUUX7D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Soni L.]

On 2020-05-02 11:59 a.m., Eric V. Smith wrote:

On 5/2/2020 7:18 AM, Alex Hall wrote:
On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar 
mailto:wagenaarhenkj...@gmail.com>> wrote:


Of course, there are other ways of writing this code, but imagine
this for a database interface where a save normally returns the
saved object (inspired by Django)

```
try:
    x, y = Foo.save()
except ValueUnpackingError:
    // oh... this means saving failed (it returned None instead)
    // let's return a sensible response
    return ExceptionToResponse(FooStateToException(foo.state))
```


My concern is that this is risky code. If `Foo.save()` has a bug 
somewhere inside (or maybe it calls back to your own code which has a 
bug) it could raise `ValueUnpackingError` for different reasons, and 
then that gets caught and misleads people into thinking that Foo.save 
returned None which leads to all sorts of frustration and confusion.


This code:

```
result = Foo.save()
if result is None:
    return ExceptionToResponse(...)
x, y = result
```

is not sexy, but it's explicit, safe, and it targets the real problem 
precisely.


Creating these new exceptions would encourage people to write code 
that will bite them later.


I agree that we don't want to encourage code like the above example 
with catching the hypothetical ValueUnpackingError. I contend that 
even if we added ValueUnpackingError, no one would ever write code 
that used it, but should instead do what they do now: unpack it after 
checking it (as Alex's example shows). Of course, that's a horrible 
API, but sometimes you have to call horrible APIs. The fact that the 
API is bad doesn't mean we should add a way to handle it poorly.


The only reason I'd want it to exist (and I don't) is to see it in the 
REPL. But for that, there's the exception message and the traceback, 
so a unique exception for this would be useless to me.




how about:

result = Foo.save()
try:
  x, y = result
except ValueUnpackingError:
  return ...

this would also handle generators (and, the unpacking operation should 
wrap the generator's ValueUnpackingError (if any) in a RuntimeError so 
it doesn't conflict with the unpacking operation's API)
___
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/DSCJVOQYV4NJR6AOHSTJJ4DUOVKESUZ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Steven D'Aprano]

On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote:

> how about:
> 
> result = Foo.save()
> try:
>   x, y = result
> except ValueUnpackingError:
>   return ...

If you do that, what benefit is ValueUnpackingError over just 
ValueError?



-- 
Steven
___
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/PNI4DP6SJXCRBJSU3IQYJBFN4KWW5X7J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Soni L.]

On 2020-05-02 1:07 p.m., Steven D'Aprano wrote:

On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote:

> how about:
> 
> result = Foo.save()

> try:
>   x, y = result
> except ValueUnpackingError:
>   return ...

If you do that, what benefit is ValueUnpackingError over just
ValueError?



unpacking (a generator) still doesn't wrap ValueError, and ValueError is 
raised a lot more than ValueUnpackingError.

___
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/GFYD6CN6OAEFZ7AALKX5QFJRNX3SFOF7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Eric V. Smith]

On 5/2/2020 12:20 PM, Soni L. wrote:



On 2020-05-02 1:07 p.m., Steven D'Aprano wrote:

On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote:

> how about:
> > result = Foo.save()
> try:
>   x, y = result
> except ValueUnpackingError:
>   return ...

If you do that, what benefit is ValueUnpackingError over just
ValueError?



unpacking (a generator) still doesn't wrap ValueError, and ValueError 
is raised a lot more than ValueUnpackingError.


Has anyone actually had that problem? And if they did, make it:

result = tuple(Foo.save())
try:
    x, y = result
except ValueError:
    ...

You could even check the length of result before assigning it if you 
wanted to do something fancier without exceptions at all. But it seems 
silly to me.


Since I've seen no actual examples of code that would benefit, I'm still 
-1 on this particular exception, and -1 on a general-purpose addition of 
exceptions.


Eric
___
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/ACF4SGCUT2F2EQPLW4USIP2KWQO5YB2E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Steven D'Aprano]

On Sat, May 02, 2020 at 01:20:01PM -0300, Soni L. wrote:
> 
> 
> On 2020-05-02 1:07 p.m., Steven D'Aprano wrote:
> >On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote:
> >
> >> how about:
> >> 
> >> result = Foo.save()
> >> try:
> >>   x, y = result
> >> except ValueUnpackingError:
> >>   return ...
> >
> >If you do that, what benefit is ValueUnpackingError over just
> >ValueError?
> >
> >
> >
> unpacking (a generator) still doesn't wrap ValueError

Sorry, I don't understand that comment. What do you mean, "wrap"?

Unpacking a generator with too many values raises ValueError:

py> a, b = (x for x in range(3))
Traceback (most recent call last):
  File "", line 1, in 
ValueError: too many values to unpack (expected 2)

> and ValueError is 
> raised a lot more than ValueUnpackingError.

Why does that matter, and how does that relate to the specific code 
sample given?

Given the line of code `x, y = result`, the only possible way ValueError 
could be raised is if `result` has the wrong number of items when 
unpacking. So what benefit does ValueUnpackingError bring to this 
example?


-- 
Steven
___
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/K6EOGW57OCDRLCF2WKPSG5ZU2A2MI6HQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Soni L.]

On 2020-05-02 1:45 p.m., Steven D'Aprano wrote:

On Sat, May 02, 2020 at 01:20:01PM -0300, Soni L. wrote:
> 
> 
> On 2020-05-02 1:07 p.m., Steven D'Aprano wrote:

> >On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote:
> >
> >> how about:
> >> 
> >> result = Foo.save()

> >> try:
> >>   x, y = result
> >> except ValueUnpackingError:
> >>   return ...
> >
> >If you do that, what benefit is ValueUnpackingError over just
> >ValueError?
> >
> >
> >
> unpacking (a generator) still doesn't wrap ValueError

Sorry, I don't understand that comment. What do you mean, "wrap"?

Unpacking a generator with too many values raises ValueError:

 py> a, b = (x for x in range(3))
 Traceback (most recent call last):
   File "", line 1, in 
 ValueError: too many values to unpack (expected 2)

> and ValueError is 
> raised a lot more than ValueUnpackingError.


Why does that matter, and how does that relate to the specific code
sample given?

Given the line of code `x, y = result`, the only possible way ValueError
could be raised is if `result` has the wrong number of items when
unpacking. So what benefit does ValueUnpackingError bring to this
example?



or if iterating result raises ValueError.

consider:

def foo():
  yield from ()
  raise ValueError

iterator = foo()
x, y = iterator

you get a ValueError, but not a ValueUnpackingError.
___
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/KISHW53CLRMACGEWZ2WRLD5DKPCEBNBS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Eric V. Smith]

On 5/2/2020 2:39 PM, Soni L. wrote:



On 2020-05-02 1:45 p.m., Steven D'Aprano wrote:

On Sat, May 02, 2020 at 01:20:01PM -0300, Soni L. wrote:
> > > On 2020-05-02 1:07 p.m., Steven D'Aprano wrote:
> >On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote:
> >
> >> how about:
> >> > >> result = Foo.save()
> >> try:
> >>   x, y = result
> >> except ValueUnpackingError:
> >>   return ...
> >
> >If you do that, what benefit is ValueUnpackingError over just
> >ValueError?
> >
> >
> >
> unpacking (a generator) still doesn't wrap ValueError

Sorry, I don't understand that comment. What do you mean, "wrap"?

Unpacking a generator with too many values raises ValueError:

 py> a, b = (x for x in range(3))
 Traceback (most recent call last):
   File "", line 1, in 
 ValueError: too many values to unpack (expected 2)

> and ValueError is > raised a lot more than ValueUnpackingError.

Why does that matter, and how does that relate to the specific code
sample given?

Given the line of code `x, y = result`, the only possible way ValueError
could be raised is if `result` has the wrong number of items when
unpacking. So what benefit does ValueUnpackingError bring to this
example?



or if iterating result raises ValueError.

consider:

def foo():
  yield from ()
  raise ValueError

iterator = foo()
x, y = iterator

you get a ValueError, but not a ValueUnpackingError.


And as has been said before, what if iterating raises a ValueUnpackingError?

Rather than go over the same ground yet again, I'll stop replying to 
this thread. I remain at -1 for adding this particular exception.


Eric
___
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/KIPMOMVSAQ67A36NQGSAK2CXPVUQ7QGC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Steven D'Aprano]

On Sat, May 02, 2020 at 03:39:50PM -0300, Soni L. wrote:

> def foo():
>   yield from ()
>   raise ValueError

def foo():
yield from ()
    raise ValueUnpackingError

Does that help?


-- 
Steven
___
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/TEWDOXDKCIAHYXH4MFAJZOQOFHRK3CLP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Soni L.]

On 2020-05-02 7:29 p.m., Steven D'Aprano wrote:

On Sat, May 02, 2020 at 03:39:50PM -0300, Soni L. wrote:

> def foo():
>   yield from ()
>   raise ValueError

 def foo():
 yield from ()
     raise ValueUnpackingError

Does that help?



the idea is that it'd become a RuntimeError when you unpack it.
___
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/GQVFEDUZGVND7Q2ZCTVDSHOXWWUOCQDU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Ram Rachum]

Hey,

I just found a good example for the unpacking errors I suggested:


def topological_sort(graph: networkx.DiGraph) -> tuple:
try:
(zero_node,) = (node for node in graph if not
graph.neighbors(node))
except TooFewToUnpackError:
raise OverdefinedOrdering
except TooManyToUnpackError:
raise UnderdefinedOrdering

...

This is instead of the following code, which I find less elegant:

def topological_sort(graph: networkx.DiGraph) -> tuple:
zero_nodes = tuple(node for node in graph if not
graph.neighbors(node))
if not zero_nodes:
raise OverdefinedOrdering
elif len(zero_nodes) >= 2:
raise UnderdefinedOrdering
else:
(zero_node,) = zero_nodes


Besides elegance, the above code can be optimized with short-circuit logic
for the TooManyToUnpackError, assuming that doesn't break backward
compatibility.
...

On Sun, May 3, 2020 at 1:39 AM Soni L.  wrote:

>
>
> On 2020-05-02 7:29 p.m., Steven D'Aprano wrote:
> > On Sat, May 02, 2020 at 03:39:50PM -0300, Soni L. wrote:
> >
> > > def foo():
> > >   yield from ()
> > >   raise ValueError
> >
> >  def foo():
> >  yield from ()
> >  raise ValueUnpackingError
> >
> > Does that help?
> >
> >
> the idea is that it'd become a RuntimeError when you unpack it.
> ___
> 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/GQVFEDUZGVND7Q2ZCTVDSHOXWWUOCQDU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/55J446VK7534LKCIJIZZOK37Z3T2QZ64/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Alex Hall]

On Sat, May 9, 2020 at 7:02 PM Ram Rachum  wrote:

> Hey,
>
> I just found a good example for the unpacking errors I suggested:
>
>
> def topological_sort(graph: networkx.DiGraph) -> tuple:
> try:
> (zero_node,) = (node for node in graph if not
> graph.neighbors(node))
> except TooFewToUnpackError:
> raise OverdefinedOrdering
> except TooManyToUnpackError:
> raise UnderdefinedOrdering
>
> ...
>
> This is instead of the following code, which I find less elegant:
>
> def topological_sort(graph: networkx.DiGraph) -> tuple:
> zero_nodes = tuple(node for node in graph if not
> graph.neighbors(node))
> if not zero_nodes:
> raise OverdefinedOrdering
> elif len(zero_nodes) >= 2:
> raise UnderdefinedOrdering
> else:
> (zero_node,) = zero_nodes
>
>
> Besides elegance, the above code can be optimized with short-circuit logic
> for the TooManyToUnpackError, assuming that doesn't break backward
> compatibility.
>

The elegance argument doesn't convince me, you'll need to explain what you
mean by the last bit about short-circuit logic.
___
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/L7MPBSQLH63DHQLC7AOHG2LURXM4QRAK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Ram Rachum]

On Sat, May 9, 2020 at 8:09 PM Alex Hall  wrote:

> On Sat, May 9, 2020 at 7:02 PM Ram Rachum  wrote:
>
>>
>> Besides elegance, the above code can be optimized with short-circuit
>> logic for the TooManyToUnpackError, assuming that doesn't break backward
>> compatibility.
>>
>
> The elegance argument doesn't convince me, you'll need to explain what you
> mean by the last bit about short-circuit logic.
>

Ah, I did a test and saw that Python does do that optimization! I meant,
that if there are too many values to unpack, we stop hitting the iterator
after we surpassed the number of items by 1, rather than consume the whole
thing. That is not true about the second example.
___
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/BRF7EUTYZAW6SMEHW5MLSB524CVTUYZF/
Code of Conduct: http://python.org/psf/codeofconduct/