Is this a relevant argument (either way) here? While I appreciate considering the applicability of the argument to existing code is generally a good thing, I'm not sure that it makes sense for cases like this where a logical outcome seems to be missing. If you can try/finally and then implicitly pass both the generic except and else clauses, and you can try/except/finally and then implicitly pass the else clause, why shouldn't the construction be logically consistent to cover the other option that is try/else/finally and then implicitly pass the generic except clause? And, for what it's worth, finding current scenarios for something like this seems heavily biased by the fact that such a construction doesn't currently exist and so code will be written to explicitly avoid it... Or just ignore being necessarily precise, as is often the case with implementations of try/except that I've seen (see the prior discussion between MRAB and Celelibi about overinclusion in the try block). I'll ask the same question as OP: "Is there a *reason* why else without except has to be invalid syntax?" On Tue, Aug 1, 2023 at 10:18 AM Chris Angelico <rosuav@gmail.com> wrote:
On Wed, 2 Aug 2023 at 02:02, Celelibi <celelibi@gmail.com> wrote:
If later on an "except" is added, the developper doing the modification should be reminded to move the call to no_error_occurred() into an "else". With real-world non-trivial code, it might not be so simple to see.
Can you give us an example of real-world non-trivial code that would benefit from this?
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/XOWJDT... Code of Conduct: http://python.org/psf/codeofconduct/