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

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 argume

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

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)) >

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

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 OverdefinedOrderi

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

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 RuntimeErro

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

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-ide

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

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 =

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

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

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

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: > >>   retu

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

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 ValueUnpack

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

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? un

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

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] Re: Introduce 100 more built-in exceptions

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 s

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

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 (inspire

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

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() >

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

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

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

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 lea

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

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

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

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. ;-) ___ P

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

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

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

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

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

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 standardiz

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

> 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

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

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

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

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 m

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

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 catc

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

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

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

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 in

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

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 at

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

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 >

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

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

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

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 th

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

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 m

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

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

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

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

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

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 reaso

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

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

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

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, enhancin

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

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 mo

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

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

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

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

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

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

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

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

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

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

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

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`,

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

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

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

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'

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

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