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 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 future, a way to c

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 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 portion. > > Sh

[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 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 is that once

[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 lon