On Wed, Apr 28, 2021 at 8:53 PM Nathaniel Smith <n...@pobox.com> wrote: > 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.
Well, this is where we respectfully disagree. The case of changing how the regular try..except works in a backwards incompatible way is a very convincing blocker to us. > > 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. We did. The PEP talks at length as to why this isn't a problem. > > 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. You keep saying that your idea of flat EGs is "ergonomic" and "important for a language like Python". The problem is that after all these emails I still have absolutely no idea about: - what exactly are you trying to propose? - what specific problem do you want to address? (that the current PEP, in your opinion, does not address) - why do you think that what you propose would be more ergonomic or simple? - what "flat EGs" or "flat tracebacks" even mean; I can't figure out not only the high level API, I don't even understand what you're talking about at the data structures level. Nathaniel, at this point it's clear that this thread somehow does not help us understand what you want. Could you please just write your own PEP clearly outlining your proposal, its upsides and downsides? Without a PEP from you this thread is just a distraction. Yury _______________________________________________ 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/AR737RYK2KCTATCBW3QSDK5SSF7CH75M/ Code of Conduct: http://python.org/psf/codeofconduct/
