Now that we have a shiny new parser, can we finally get rid of this language wart:

assert thing, description  # works as intended

assert (thing, description)  # always True as non-empty tuples are Truthy

This most often happens when extending thing or description beyond a single line on assert statements as () are the natural way to do that and as it is with assert being a statement, knowing specifically where to place the ()s to not fall into the pit of snakes of unintentionally nerfing your assertion to be an always true tuple is hard for human authors.

This would obsolete the pylint error about tuple assertion and enable more natural assert use.

py.test framework users would presumably rejoice as well.


This parsing change would need a PEP.  I fail to see any obvious downsides though.

It does not need any change in parser, it can be done in the code generator which currently explicitly warns about such ambiguity.

Although it needs changes in formal grammar which will be more complex.

But what is a benefit? What is an advantage of writing

   assert (thing, description)

instead of

   assert thing, description

?

I can try to prototype something in the parser to see how it looks and work on the pep if everything looks ok.

Parentheses are a bit tricky in general as backtracking ends causing all sorts of tricky situations with custom syntax errors as the parser needs to distinguish between function calls, tuple construction and grouping so that's the only dangerous situation I can think of

It's not about an advantage, it's about removing the problem of what edit to make when working on


assert thing_that_has_a_meaningful_name.methods_have_good_names(value_from_somewhere) == other_thing_that_is_meaningful, "Description of what the issue is if this fails for humans, as if the names weren't enough"

and making that fit within whatever line length limit your codebase has.

put () in the wrong place and it triggers the long standing Python wart or parsing as a tuple.

rather than warn about the syntax wart, we should just do the thing code authors want in the first place.

> can we finally get rid of this language wart

Yes, please.  This is a pretty bad pitfall.

I've seen this happen to people who've been conditioned by other languages to think of assert() as a macro or function:

    assert(sometest, somemessage)

We managed to do this for 'with' so it should be possible here too, I'd think. The "committing" token would be the newline following the close parenthesis.

Serhiy: the benefit is when you want to split it across two lines, e.g.

assert (a_very_long_condition(),
        "A Very Long Message")

I know you can do this using backslash, e..

assert a_very_long_condition(), \
        "A Very Long Message"

but there's a strong cultural rejection of backslash for line splitting (it's in PEP 8 and engrained in many people's brains) and it's just so natural to use parentheses -- they work for 'import', 'with', function calls, 'if', etc.

> We managed to do this for 'with' so it should be possible here too, I'd think. The "committing" token would be the newline following the close parenthesis.


I am not so sure is that inmediate. Changing the assert statement from:

 'assert' a=expression b=[',' z=expression { z }]

to

    | 'assert' '(' a=expression b=[',' z=expression { z }] ')'
    | 'assert' a=expression b=[',' z=expression { z }] 

will render this invalid:

assert (a, b) <= c, "something"

The reason is that it will parse the (a, b) as the assert statement eagerly and then it will fail to parse the rest.

We could do this, but feels a bit hacky:

    | 'assert' '(' a=expression b=[',' z=expression { z }] ')' &(NEWLINE | ';')
    | 'assert' a=expression b=[',' z=expression { z }]

Another possibility is actually handled this in the compiler:

if we see an assert with a tuple of two elements, we can assume is basically in the form that we want and proceed as if is in the form
assert A, B

This also feels a bit hacky because the AST is somehow wrong as the assert node is already prepared to differentiate these two cases.

I like the lookahead. We could also make the comma and the message mandatory when inside parentheses:

    | 'assert' '(' a=expression ',' b=expression [','] ')' &(NEWLINE | ';')
    | 'assert' a=expression b=[',' z=expression { z }]

(And probably add an "invalid" rule to cover tuples with 0, 1, 3 or more elements.)

For very long expression or very long message you can add parentheses around the expression or message. Black will format it as:

assert (
    very very long
    expression
), (
    "very very long "
    "message"
)

With the proposed feature it will be:

assert (
    very very long
    expression,
    "very very long "
    "message",
)

It saves one line, but the border between an expression and a message is blur. Since they are separated by a comma at the end of line and all lines have the same indentation it looks less readable to me.

Note also that Black adds a comma after message.

You don’t have to use the new feature. But people expect it to work.

I created a PEP to formally propose the change:

https://www.python.org/dev/peps/pep-0679/