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

Pablo Galindo Salgado added the comment: I created a PEP to formally propose the change: https://www.python.org/dev/peps/pep-0679/ -- ___ Python tracker ___ _

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

Guido van Rossum added the comment: You don’t have to use the new feature. But people expect it to work. -- ___ Python tracker ___ _

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

Serhiy Storchaka added the comment: 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: as

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

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +28465 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30247 ___ Python tracker __

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

Guido van Rossum added the comment: 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 "i

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

Pablo Galindo Salgado added the comment: 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 AS

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

Pablo Galindo Salgado added the comment: We could do this, but feels a bit hacky: | 'assert' '(' a=expression b=[',' z=expression { z }] ')' &(NEWLINE | ';') | 'assert' a=expression b=[',' z=expression { z }] -- ___ Python tracker

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

Pablo Galindo Salgado added the comment: > 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=exp

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

Guido van Rossum added the comment: 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_conditio

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

Raymond Hettinger added the comment: > 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)

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

Change by Karthikeyan Singaravelan : -- nosy: +gvanrossum, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list

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

Gregory P. Smith added the comment: 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 i

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

Pablo Galindo Salgado added the comment: 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

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

Serhiy Storchaka added the comment: 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 writin

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

Change by Sergei Lebedev : -- nosy: +slebedev ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

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

New submission from Gregory P. Smith : 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 d