This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: PEP 463 (except expression) implementation
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.5
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Rosuav, berker.peksag, josh.r, martin.panter, twouters
Priority: normal Keywords: patch

Created on 2014-02-22 23:56 by twouters, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
exceptexpr.diff twouters, 2014-02-22 23:56 except expression with precedence equal to ifexpr. review
5c078eb8da39.diff twouters, 2014-02-24 00:31 review
unparse_exceptexpr.diff Rosuav, 2014-02-27 15:33 Patch to allow Tools/parser/ to unparse except expressions
make_stuff_work.diff Rosuav, 2014-02-27 20:59 Patches to make everything compile and run tests happily
churn1.diff Rosuav, 2014-02-27 21:00 Code churn to stress-test except expressions with assignments and return statements
churn2.diff Rosuav, 2014-02-27 21:00 Code churn to stress-test except expressions with double-expression form
broken.diff Rosuav, 2014-02-27 21:01 Patch that breaks the test suite
Repositories containing patches
Messages (7)
msg211973 - (view) Author: Thomas Wouters (twouters) * (Python committer) Date: 2014-02-22 23:56
Here is a preliminary implementation of PEP 463, minus mandatory parentheses and with the most straightforward precedence rule: equal to if-expr -- which means this:

A if C else B except E: D

is parsed as

A if C else (B except E: D)

(because of associativity, not precedence) and not as

(A if C else B) except E: D

as suggested by the PEP with the hand-wavy words 'between lambda and if/else in precedence'. The latter is possible but means a little more hoop-jumping in the grammar.

The tests included are rudimentary (at the end of and could probably do with some fleshing out, partially as tests and partially to try out how the precedence rules work out in practice.
msg212049 - (view) Author: Thomas Wouters (twouters) * (Python committer) Date: 2014-02-24 00:30 now contains a version of the patch that makes the parentheses mandatory, similar to generator expressions. (Leaving the old patch for reference.)
msg212360 - (view) Author: Chris Angelico (Rosuav) * Date: 2014-02-27 15:33
One test failing, due to Tools/parser/ not knowing how to unparse an except expression. Otherwise, test suite passes (with most of the stdlib unchanged). I'm about to try writing an actual conversion script which will rewrite the stdlib, and then see how much of the test suite still passes. (For this, I'll be doing only the easiest/simplest translations - the ones that involve simple or augmented assignment, and return statements - and I'll ignore PEP 8.)
msg212385 - (view) Author: Chris Angelico (Rosuav) * Date: 2014-02-27 20:59
I've applied all the changes my script can find, including ones that are actually quite inappropriate, like:

    except some_exception:

All tests pass except for one, which I don't fully understand. Attaching patches:

1) make_stuff_work.diff - what it says on the tin. I don't understand everything that's going on in there, but the build process made some changes to tracked files.

2) churn1.diff - mostly-plausible edits. They're unnecessary code churn, and shouldn't be done wholesale like this, but they make the obvious changes.

3) churn2.diff - less plausible edits, in the two-expression form shown above. These definitely shouldn't be done... but they don't break any of the tests, so they're a reasonable proof that the concept works.

4) broken.diff - for some reason that I don't understand, this causes a test failure. Something that's supposed to produce no output now produces a warning. I cannot figure out how there's a difference in there. Advice please?

The broken one is of the inappropriate type, but the fact that it doesn't work seems... indicative, somehow. Indicative of what, I don't know, and it's 8AM after I've been up all night, so I'm not going to try further to figure this out.
msg214998 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2014-03-27 23:20
It's not part of the PEP, but what happens with the new syntax if there is an existing exception context? Some utilities (e.g. functools.lru_cache) use dict.get over a try/except because they operate under the assumption that they may be invoked within an except block, and must leave the exception context (if any) unmodified.

It seems like something intended to serve as a general replacement for non-exception raising functions like dict.get should have similar exception context preserving semantics.
msg215008 - (view) Author: Thomas Wouters (twouters) * (Python committer) Date: 2014-03-27 23:58
The implementation in the patch preserves the exception context. It's probably the thing that took the most code, and it's why there's two new opcodes in the patch :) It's covered in the tests, too.
msg233992 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-01-14 01:30
Guido's comment about the PEP is at

Can we close this and mark PEP 463 as rejected now?
Date User Action Args
2022-04-11 14:57:59adminsetgithub: 64938
2016-04-16 17:13:17berker.peksagsetstatus: open -> closed
resolution: rejected
stage: patch review -> resolved
2015-01-14 01:30:10berker.peksagsetnosy: + berker.peksag
messages: + msg233992
2015-01-13 12:31:16martin.pantersetnosy: + martin.panter
2014-03-27 23:58:22twouterssetmessages: + msg215008
2014-03-27 23:20:26josh.rsetnosy: + josh.r
messages: + msg214998
2014-03-27 15:22:16yselivanovsetnosy: - yselivanov
2014-02-27 21:01:16Rosuavsetfiles: + broken.diff
2014-02-27 21:00:59Rosuavsetfiles: + churn2.diff
2014-02-27 21:00:16Rosuavsetfiles: + churn1.diff
2014-02-27 20:59:20Rosuavsetfiles: + make_stuff_work.diff

messages: + msg212385
2014-02-27 15:33:36Rosuavsetfiles: + unparse_exceptexpr.diff

messages: + msg212360
2014-02-24 00:31:22twouterssetfiles: + 5c078eb8da39.diff
2014-02-24 00:30:01twouterssethgrepos: + hgrepo218
messages: + msg212049
2014-02-23 01:48:43yselivanovsetnosy: + yselivanov
2014-02-23 00:03:49Rosuavsetnosy: + Rosuav
2014-02-22 23:56:57twouterscreate