[Python-ideas] Inline assignments using "given" clauses

Steven D'Aprano steve at pearwood.info
Fri May 11 07:46:27 EDT 2018

On Sat, May 05, 2018 at 06:24:07AM -0400, Juancarlo Añez wrote:
> I think that "expr as y"  was discarded too quickly.

This discussion started back in *February*. I don't think "too quickly" 
applies to ANYTHING about it.


And Chris' first draft of the PEP:


I have been one of the main proponents of "as". See, for example:


At least, I *was*. I'm now satisfied that "as" is the wrong solution, 
and I don't think it was discarded too quickly. Even though it makes me 
sad that "as" is not suitable, I'm satisfied that the problems with it 
would require too high a price to solve.

The major problem is that it will clash with "except as" and "with as" 
statements. Of course we *could* introduce some sort of special 
treatment, possibly as simple as simply banning the use of binding- 
assignments inside except/with statements, but such special rules add 
complexity, make the feature less useful, harder to learn, and more 

Allowing or disallowing particular expressions after a certain keywork 
ought to be a last resort. Even though this was my preferred solution, 
I've now come to change my mind and think this would have been a 

(Thanks Chris for sticking to your guns and rejecting "as".)

You say:

> The special cases that may arise over "except"  and "with"  can be worked
> out and documented.

but there's no "may" about this. Using "as" does clash, it's not a 
matter of whether or not it will clash, we know it will. And it's easy 
to say that it "can" be worked out, but unless you have a concrete 
proposal to work it out, that's not really an argument in favour for 
"as", it is just a hope.

Guido has also correctly pointed out that will "as" is used to bind 
names in other contexts, it doesn't *quite* work the same as regular = 
assignment. Again, the "with" statement is especially relevant:

    with expression as name

does not bind the value of the expression to name, except by 
coincidence. It actually binds the value of expession.__enter__() to 

I still, and probably always will, like the look of

    result = (expression as spam) + spam**2

but I'm realistic to realise that it isn't practical.


More information about the Python-ideas mailing list