On Fri, Apr 23, 2021 at 9:22 AM Nathaniel Smith <
njs@pobox.com> wrote:
On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum <guido@python.org> wrote:
> On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith <njs@pobox.com> wrote:
>> Sure. This was in my list of reasons why the backwards compatibility
>> tradeoffs are forcing us into awkward compromises. I only elaborated
>> on it b/c in your last email you said you didn't understand why this
>> was a problem :-). And except* is definitely useful. But I think there
>> are options for 'except' that haven't been considered fully.
>
> Do you have any suggestions, or are you just telling us to think harder? Because we've already thought as hard as we could and within all the constraints (backwards compatibility and otherwise) we just couldn't think of a better one.
The main possibility that I don't think we've examined fully is to
make 'except' blocks fire multiple times when there are multiple
exceptions. We ruled it out early b/c it's incompatible with nested
EGs, but if flat EGs are better anyway, then the balance shifts around
and it might land somewhere different. it's a tricky discussion
though, b/c both the current proposal and the alternative have very
complex implications and downsides. So we probably shouldn't get too
distracted by that until after the flat vs nested discussion has
settled down more.
I'm not trying to filibuster here -- I really want some form of EGs to
land.
I'm very glad to hear that. It's been hard to know where you stand, because you didn't even decline our invitation in October to work together on this, and several
later
invitations to look at the implementation and try it with Trio -- you just didn't reply. The only responses I saw were public, on this list, taking us right back to the drawing board (for example - the suggestion you mention in the previous paragraph as not-sufficiently-explored, actually appears in the rejected ideas section of the PEP, and the reason for rejection is not that it's incompatible with nesting). So thank you for clarifying that you are, ultimately, supportive of our efforts.
We do realize that we didn't adequately credit you for the contributions of your 2018 work to this PEP, and have now added an acknowledgements section for that purpose. Apologies for that.
I'm confused about the flattening suggestion - above you talk about "flat EG", but below about tracebacks. It's not clear to me whether you want EG to be flat (ie no nesting of EGs) or just the traceback to be flat (but you can still have a nested EG). I also don't know what problem you are trying to solve with this.
Fortunately we're not at the whiteboard stage anymore, we have a fully working implementation and you can use it to demonstrate any problems you see with what we did.
Irit
I think python has the potential to be the most elegant and
accessible language around for writing concurrent programs, and EGs
are a key part of that. I don't want to fight about anything; I just
want to work together to make sure we have a full picture of our
options, so we can be confident we're making the best choice.
> The real cost here is that we would need a new "TracebackGroup" concept, since the internal data structures and APIs keep the traceback chain and the exception object separated until the exception is caught. In our early design stages we actually explored this and the complexity of the data structures was painful. We eventually realized that we didn't need this concept at all, and the result is much clearer, despite what you seem to think.
I'm not talking about TracebackGroups (at least, I think I'm not?). I
think it can be done with exactly our current data structures, nothing
new.
- When an EG is raised, build the traceback for just that EG while
it's unwinding. This means if any C code peeks at exc_info while it's
in flight, it'll only see the current branch of the traceback tree,
but that seems fine.
- When the exception is caught and we go to write back the traceback
to its __traceback__ attribute, instead "peek through" the EG and
append the built-up traceback entries onto each of the constituent
exceptions.
You could get cleverer for efficiency, but that basic concept seems
pretty simple and viable to me. What am I missing?
-n
--
Nathaniel J. Smith -- https://vorpus.org