On Fri, Apr 23, 2021 at 4:08 AM Irit Katriel <iritkatr...@googlemail.com> wrote: > > On Fri, Apr 23, 2021 at 9:22 AM Nathaniel Smith <n...@pobox.com> wrote: >> 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.
Yes, I apologize again for the radio silence there -- I had real world stuff that left me with no cope for open-source. I, uh, was feeling guilty about not getting back to you the whole time, if that helps? Probably that doesn't help. My memory is that in our initial discussions, I suggested having each 'except Blah as exc' clause be executed once, receiving an ExceptionGroup containing all the Blah exceptions. Guido pointed out that this broke typing -- 'exc' would not longer have type 'Blah' -- and I was like... okay yeah that's a fatal flaw, never mind. And I never seriously raised the 'execute a single clause multiple times' option, because of the issue where in the nested design, taking individual exceptions out of an ExceptionGroup breaks tracebacks. Looking at the relevant section of the PEP again [1], it notes the same fatal flaw with my first suggestion, and then says that the multiple-except-executions option should be rejected because users have written code like 'except SomeError: ...' with the expectation that the 'except' clause would run exactly once. That's definitely true, and it's a downside of the multiple-except-executions approach, but I don't think it's convincing enough to rule this out on its own. The problem is, *all* our options for how 'except' should interact with ExceptionGroups will somehow break previous expectations. Concretely: imagine you have a pre-existing 'except SomeError', and some new code inside the 'try' block raises some number of 'SomeError's wrapped in an ExceptionGroup. There are three options: - Execute the 'except' block multiple times. This breaks the expectation that it should be executed at most once. - Execute the 'except' block exactly once. But if there are multiple SomeError's, this require they be grouped and delivered as a single exception, which breaks typing. - Execute the 'except' block zero times. This is what the current PEP chooses, and breaks the expectation that 'except SomeError' should catch 'SomeError'. So we have to pick our poison. [1] https://www.python.org/dev/peps/pep-0654/#extend-except-to-handle-exception-groups > 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. Oh, that didn't bother me at all, but thanks :-). And I'm sorry if I was denying you credit for things that you had actually independently re-invented. > 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). Hmm, I was thinking about making both of them flat, so no nested EGs. In all my designs, the only reason I ever had nesting was because I couldn't figure out any other way to make the tracebacks work. Do you have some other motivation for wanting nesting? If so that would be interesting, because it might point to why we're talking past each other and help us understand the problem better... > I also don't know what problem you are trying to solve with this. I'm not saying that there's some fatal problem with the current PEP. (In my first message I explicitly said that it would be an improvement over the status quo :-).) But I think that nesting will be really counterintuitive/confusing for users in some ways. And concurrency APIs will be offputting if they force you to use a different special form of 'except' all the time. Basically the 'flat' version might be a lot more ergonomic, and that's important for a language like Python. -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/D6G7Z4QVC5H6UMHOFR33FMVCRV4HL6SM/ Code of Conduct: http://python.org/psf/codeofconduct/
