[Python-ideas] PEP 572: Statement-Local Name Bindings

[Chris Angelico]

On Wed, Feb 28, 2018 at 5:53 PM, Gregory P. Smith <greg at krypto.org> wrote:
>
> My first concern for this proposal is that it gives parenthesis a
> non-intuitive meaning.  ()s used to be innocuous.  A way to group things,
> make explicit the desired order of operations, and allow spanning across
> multiple lines.
>
> With this proposal, ()s occasionally take on a new meaning to cause
> additional action to happen _outside_ of the ()s - an expression length name
> binding.
>
> Does this parse?
>
>   print(fetch_the_comfy_chair(cardinal) as chair, "==", chair)
>
> SyntaxError?  My read of the proposal suggests that this would be required:
>
>   print((fetch_the_comfy_chair(cardinal) as chair), "==", chair)
>
> But that sets off my "excess unnecessary parenthesis" radar as this is a new
> need it isn't trained for.  I could retrain the radar...

Hmm, interesting point. The value to be captured DOES need to be
grouped, though, and the influence of the assignment is "until end of
statement", which is usually fairly clear.

Parentheses do already have quite a number of meanings. For instance,
a function call does more than simply group a subexpression - there's
a lot of difference between

x=(1, 2, 3)

and

x(1, 2, 3)

even before you look at all the other syntaxes that can be used inside
function calls (eg keyword arguments). The way I see it, this proposal
is about the "as" keyword being used for local name binding, and the
purpose of the parentheses is to group the name with the value being
bound.

> I see people try to cram too much functionality into one liners.  By the
> time you need to refer to a side effect value more than once in a single
> statement... Just use multiple statements.  It is more clear and easier to
> debug.

This concern comes up frequently, and there are definitely times when
it's true. But there are also times when the opposite is true, and
pushing more syntax into a single logical action makes code MORE
readable. For instance, Python allows us to quickly zero out a bunch
of variables all at once:

a = b = c = d = e = 0

Can this be abused? Sure! But when it's used correctly, it is far MORE
readable than laying everything out vertically:

a = 0
b = 0
c = 0
d = 0
e = 0

Code is attempting to express abstract ideas. If your idea of
"readable code" is "code that makes it easy to see the concrete
actions being done", you're missing out on a lot of the power of
Python.

> We've got a whitespace delimited language. That is a feature. Lets keep it
> that way rather than adding a form of (non-curly) braces.

I don't fully understand you here. Python has always used symbols as
delimiters, and I doubt anyone would want to do things any
differently.

> Practical examples from existing code that become clearly easier to
> understand afterwards instead of made the examples with one letter names may
> help.

Fair enough. I'll try to dig some up. The trouble is that practical
examples are seldom as clear and simple as the shorter examples are.

ChrisA