[Python-ideas] Modern language design survey for "assign and compare" statements

Chris Angelico rosuav at gmail.com
Fri May 18 21:10:30 EDT 2018

On Sat, May 19, 2018 at 10:54 AM, Mike Miller <python-ideas at mgmiller.net> wrote:
> In short, extend the "if/elif", "while", and comprehension to:
>     if pattern.search(data) as match:
>     while read_next_item() as value:
> May be best to disallow multiple assignment/conditions for now, but up for
> discussion.  That leaves comprehensions, which could support a EXPR as NAME
> target also:
>     filtered_data = [f(x) as y, x/y for x in data]
> or perhaps reuse of the if…as statement to keep it simpler:
>     filtered_data = [y, x/y for x in data if f(x) as y]
> That variant might need an extra test if f(x) returns a falsey value,
> perhaps
> "is not None" on the end.

The bit that you tag on as an afterthought is actually critically
important here. You have two options:

1) The 'as' is part of the syntax of the 'if' and 'while' statements; or

2) The 'as' is part of the definition of an expression.

The first case would be grammar like this:

if_stmt: 'if' test ['as' NAME] ':' suite ('elif' test ':' suite)*
['else' ':' suite]

The second is permitting 'as' name-bindings in arbitrary expressions,
but then saying "except that they're only allowed in 'if' statements".
As you've noted, the first one isn't sufficient. You can't use the
restricted syntax for more than a small handful of conditions
(including re.match(), but not including anything that might return
None and might return other falsey values).

So if this is valid:

    if (f(x) as y) is not None:

then why isn't this valid:

    print(f(x) as y)

or this:

    f(x) as y # identical to "y = f(x)"

or even this:

    with (f(x) as y):

? If you say they should all be valid, have a read of the PEP - the
consequences are pretty dangerous, especially the last one. If not,
then where do you draw the line, and which consequences do you want to

The 'as' syntax has been hammered out in great detail and is no longer
recommended due to its negative interactions with existing constructs.


More information about the Python-ideas mailing list