On 2021-10-01 2:04 a.m., Steven D'Aprano wrote:
> 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
> > > ExceptionWeCareAbout:
> > > some.user_code()
> > > code_we_assume_is_safe()
> > > if args.something and some_condition:
> > > raise ExceptionWeCareAbout # Line (A)
> > >
> > > How does the compiler know that *only* ExceptionWeCareAbout originating
> > > in Line (A) should be re-raised, and any other location turned into
> > > RuntimeError?
> >
> > Same way Rust decides whether to propagate or unwrap a Result: you
> > *must* tell the compiler.
>
> How do I tell the compiler? There is no sign in your syntax that Line
> (A) is special or different from the rest of the lines in the function.
>
> > > What if I factor out those last two lines and make it:
> > >
> > > def a_potentially_recursive_function(some, args) with
> > > ExceptionWeCareAbout:
> > > some.user_code()
> > > code_we_assume_is_safe()
> > > check_condition_or_raise(args.something, some_condition)
> > >
> > > How does the compiler decide to re-raise exceptions originating in the
> > > last line but not the first two?
> >
> > In this case, it explicitly doesn't.
>
> So by refactoring a conditional raise (if condition: raise) into a
> function, I completely change the meaning of the code? That's just
> great. Not.
>
>
> > You explicitly told it the last line doesn't raise any exceptions that
> > contribute to your API's exception surface.
>
> I did? I wasn't aware that I told the interpeter *explicitly* anything
> about the last line. How does this work?
>
> That's what I'm trying to understand about your proposal: I write a
> function, and stick "with ExceptionName" into the function declaration
> line:
>
> def function(some, args) with ExceptionWeCareAbout:
>
> and then write a block of code under that declaration, and *somehow* in
> some completely unspecified way the compiler Does What I Mean by
> deciding that *some* of those lines which raise ExceptionWeCareAbout it
> should let the exception through while *other* lines that raise the same
> exception should be guarded against ExceptionWeCareAbout and have them
> raise RuntimeError instead.
>
> And I have no idea how it decides which lines are guarded and which are
> not. You tell me that I explicitly instructed the compiler which
> lines should be guarded, but I don't know how I did it.
>
>
> > You *must* use try: check_condition_or_raise(args.something,
> > some_condition) except ExceptionWeCareAbout: raise
>
> But that's not what the pre-refactoring code had. All I did was move:
>
> # The original version, before refactoring.
> if args.something and some_condition:
> raise ExceptionWeCareAbout
>
> into a named function and call that. In the original code, I didn't have
> to explicitly catch the exception and then immediately re-raise it:
>
> # This was never used.
> try:
> if args.something and some_condition:
> raise ExceptionWeCareAbout
> except ExceptionWeCareAbout:
> raise
>
> But now you are telling me that if I move the `if... raise` lines into a
> function I have to also wrap it in a try...except, catch the exception,
> and immediately and unconditionally re-raise it.
>
> This behaviour may be clear to *you* but I cannot read your mind. Unless
> you actually tell me how the compiler knows which part of the block need
> to be guarded and which parts don't, I have no clue how this is
> happening except "the compiler magically infers what I want it to do".
>
>
>
Look for the clarification post we posted as a reply to the original post.
_______________________________________________
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/F6W5PWT253XLOFQRGV4LSHUADHC2GGJD/
Code of Conduct: http://python.org/psf/codeofconduct/
