Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[gpshead]

BPO	46167
Nosy	@gvanrossum, @rhettinger, @gpshead, @serhiy-storchaka, @lysnikolaou, @pablogsal
PRs	bpo-46167: Allow assert statements with parentheses #30247

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-12-23.19:58:53.712>
labels = ['interpreter-core', '3.11']
title = 'Parse assert (x == y, "Descriptive text") as statement params instead of a tuple'
updated_at = <Date 2022-01-10.00:22:08.743>
user = 'https://github.com/gpshead'

bugs.python.org fields:

activity = <Date 2022-01-10.00:22:08.743>
actor = 'pablogsal'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Parser']
creation = <Date 2021-12-23.19:58:53.712>
creator = 'gregory.p.smith'
dependencies = []
files = []
hgrepos = []
issue_num = 46167
keywords = ['patch']
message_count = 13.0
messages = ['409101', '409102', '409103', '409105', '409115', '409117', '409122', '409123', '409124', '409126', '409132', '409147', '410178']
nosy_count = 7.0
nosy_names = ['gvanrossum', 'rhettinger', 'gregory.p.smith', 'serhiy.storchaka', 'lys.nikolaou', 'pablogsal', 'slebedev']
pr_nums = ['30247']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue46167'
versions = ['Python 3.11']

[gpshead]

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.

[serhiy-storchaka]

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

?

[pablogsal]

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

[gpshead]

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.

[rhettinger]

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)

[gvanrossum]

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.

[pablogsal]

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.

[pablogsal]

We could do this, but feels a bit hacky:

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

[pablogsal]

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.

[gvanrossum]

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.)

[serhiy-storchaka]

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.