[Python-Dev] Why not make frames? [was: Alternative forms [was: PEP 463: Exception-catching expressions]]

2014-03-09 Thread Jim J. Jewett
TL;DR: expr except (default if exc_expr) expr (except default if exc_expr) expr except (exc_expr: default) expr (except exc_expr: default) (1) Group the exceptions with the default they imply. (2) inline-: still needs () or [] or {}. (3) Consider the expression inside a

[Python-Dev] Scope issues [was: Alternative forms [was: PEP 463: Exception-catching expressions]]

2014-03-09 Thread Jim J. Jewett
On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote: On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett jimjjewett at gmail.com wrote: (Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded: ...[as-capturing is] deferred until there's a non-closure means of creating a sub-scope. The problem

Re: [Python-Dev] Why not make frames? [was: Alternative forms [was: PEP 463: Exception-catching expressions]]

2014-03-09 Thread Chris Angelico
On Mon, Mar 10, 2014 at 1:16 PM, Jim J. Jewett jimjjew...@gmail.com wrote: On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote: I don't see except expressions as fundamentally more associated with if/else than with, say, an or chain, which works left to right. I do, because of the skipping

Re: [Python-Dev] Scope issues [was: Alternative forms [was: PEP 463: Exception-catching expressions]]

2014-03-09 Thread Chris Angelico
On Mon, Mar 10, 2014 at 1:35 PM, Jim J. Jewett jimjjew...@gmail.com wrote: The PEP should therefore explicitly state that implementation details may force the deferral to be permanent, and that this is considered an acceptable trade-off. How about words to this effect? Should there be, in