[Python-ideas] Re: Better exception handling hygiene

On Thu, Sep 30, 2021 at 12:03:37AM -0300, Soni L. wrote: > > Only some.user_code is guarded by the try block. If it turns out that > > code_we_assume_is_safe is not actually safe, and fails with an > > exception, it won't be caught by the try block and you will know about > > it. > > Except no

[Python-ideas] Re: Better exception handling hygiene

On further thought, maybe something like this is what you are looking for? https://code.activestate.com/recipes/580808-guard-against-an-exception-in-the-wrong-place/ This allows you to replace one or more kinds of exceptions with another specified exception (defaults to RuntimeError) using a co

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 4:15 a.m., Steven D'Aprano wrote: > On Thu, Sep 30, 2021 at 12:03:37AM -0300, Soni L. wrote: > > > > Only some.user_code is guarded by the try block. If it turns out that > > > code_we_assume_is_safe is not actually safe, and fails with an > > > exception, it won't be caught by th

[Python-ideas] Re: Better exception handling hygiene

On Thu, Sep 30, 2021 at 8:43 PM Soni L. wrote: > You misnderstand exception hygiene. It isn't about "do the least stuff > in try blocks", but about "don't shadow unrelated exceptions into your > public API". > > For example, generators don't allow you to manually raise StopIteration > anymore: > >

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 10:08 a.m., Chris Angelico wrote: > On Thu, Sep 30, 2021 at 8:43 PM Soni L. wrote: > > You misnderstand exception hygiene. It isn't about "do the least stuff > > in try blocks", but about "don't shadow unrelated exceptions into your > > public API". > > > > For example, generators

[Python-ideas] Re: Better exception handling hygiene

On Fri, Oct 1, 2021 at 12:03 AM Soni L. wrote: > > > But what you're talking about doesn't have this clear distinction, > > other than in *your own definitions*. You have deemed that, in some > > areas, a certain exception should be turned into a RuntimeError; but > > in other areas, it shouldn't.

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 11:23 a.m., Chris Angelico wrote: > > For example this: (real code) > > > > def get_property_values(self, prop): > > try: > > factory = self.get_supported_properties()[prop] > > except KeyError as exc: raise PropertyError from exc > > iterator

[Python-ideas] Re: Shorthand syntax for lambda functions that have a single parameter

On 2021-09-30 07:21, Chris Angelico wrote: On Thu, Sep 30, 2021 at 4:19 PM Steven D'Aprano wrote: On Wed, Sep 29, 2021 at 02:09:03PM -0700, Guido van Rossum wrote: > Over in typing-sig we're considering a new syntax for callable *types*, > which would look like (int, int, str) -> float. A matc

[Python-ideas] Re: Better exception handling hygiene

Alright, some ppl asked us to rephrase this, so: The plan is to take the function syntax:     def name(args): and add an optional "with" to it:     def name(args) with exceptions: these then get added to the function, similar to e.g. default args. when an exception is thrown*, the VM then chec

[Python-ideas] Re: Better exception handling hygiene

On Fri, Oct 1, 2021 at 1:10 AM Soni L. wrote: > > > > On 2021-09-30 11:23 a.m., Chris Angelico wrote: > > > For example this: (real code) > > > > > > def get_property_values(self, prop): > > > try: > > > factory = self.get_supported_properties()[prop] > > > except K

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 09:25, Soni L. wrote: these then get added to the function, similar to e.g. default args. when an exception is thrown*, the VM then checks these and converts relevant exceptions into RuntimeError, e.g.: def foo(): raise Bar def baz() with Bar: foo()

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 2:04 p.m., Chris Angelico wrote: > On Fri, Oct 1, 2021 at 1:10 AM Soni L. wrote: > > > > > > > > On 2021-09-30 11:23 a.m., Chris Angelico wrote: > > > > For example this: (real code) > > > > > > > > def get_property_values(self, prop): > > > > try: > > > > f

[Python-ideas] Re: Better exception handling hygiene

> On 30 Sep 2021, at 17:25, Soni L. wrote: > > Alright, some ppl asked us to rephrase this, so: > > The plan is to take the function syntax: > > def name(args): > > and add an optional "with" to it: > > def name(args) with exceptions: > > these then get added to the function, simil

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 5:34 p.m., Barry Scott wrote: > > >> On 30 Sep 2021, at 17:25, Soni L. > > wrote: >> >> Alright, some ppl asked us to rephrase this, so: >> >> The plan is to take the function syntax: >> >>     def name(args): >> >> and add an optional "with" to it: >> >

[Python-ideas] Re: Better exception handling hygiene

On Fri, Oct 1, 2021 at 6:12 AM Soni L. wrote: > > Congratulations, you showed me some extremely complicated code, and > > then got miffed when I messed up something in trying to simplify it. > > Well done, you successfully tripped me up in my attempt to make code > > better. > > Fair enough, we we

[Python-ideas] Re: Better exception handling hygiene

On 2021-09-30 6:08 p.m., Chris Angelico wrote: > I still think that your use of LookupError is confusing the issue > somewhat, partly because it's a base class rather than something > that's ever raised per se. > > If you were using a custom exception type, how likely is it that that > exception

[Python-ideas] Re: Better exception handling hygiene

On Thu, Sep 30, 2021 at 07:41:47AM -0300, Soni L. wrote: > You misnderstand exception hygiene. It isn't about "do the least stuff > in try blocks", but about "don't shadow unrelated exceptions into your > public API". I disagree with that. I don't think that "exception hygiene" is a common term

[Python-ideas] Re: Better exception handling hygiene

Let's get to the fundamental problem with this. It is DWIM magic, and you haven't (as far as I have seen) yet specified how we are supposed to use it or predict how it is supposed to work. Here is your syntax again: > > def a_potentially_recursive_function(some, args) with > > ExceptionWeC

[Python-ideas] Re: Better exception handling hygiene

On Fri, Oct 1, 2021 at 3:02 PM Steven D'Aprano wrote: > We might take the point of view that StopIteration is reserved for use > by iterators, and that the interpreter reserves the use to treat *any* > use of StopIteration in any other context as undefined behaviour, and > that we ought to be grat