I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
---------- Forwarded message --------- From: Hoi lam Poon <gillcovi...@gmail.com> Date: Fri, Apr 23, 2021, 02:01 Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST] To: Nathaniel Smith <n...@pobox.com> Stop pretending, I can definitely get the key control file, your working group, all past actions and instructions cannot be cleared in front of me at all. You have been playing around for a few days, and I won’t stop you. Your face? I won’t, you know, you can’t drive me away, and that file is all, after I get it, you will be convicted even if you disband, I swear 在 2021年4月23日 週五 16:23，Nathaniel Smith <n...@pobox.com> 寫道： > On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum <gu...@python.org> wrote: > > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith <n...@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 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 > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/VOBOWZGW44GNMW6IUZU6P5OO2A5YKB53/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4BAOL763Y2O2AXLEILYGHSNG2VMZJIN6/ Code of Conduct: http://python.org/psf/codeofconduct/
