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.

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..., 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-leave@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/IVNKPA... Code of Conduct: http://python.org/psf/codeofconduct/

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

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?

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 "<string>", line 1, in <module> IOError: [Errno 2] No such file or directory: 'not-there' $ python3 -c 'open("not-there")' Traceback (most recent call last): File "<string>", line 1, in <module> 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.

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

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.

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.

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.

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

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~

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.

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

On 5/2/2020 7:18 AM, Alex Hall wrote:

On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar mailto:wagenaarhenkjaap@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

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

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:

...

...

result = Foo.save()

how about: 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

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 "<stdin>", line 1, in <module> 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.

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

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

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.

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

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