Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide how to handle comments with debug expressions in f-strings #112243

Closed
pablogsal opened this issue Nov 18, 2023 · 7 comments
Closed

Decide how to handle comments with debug expressions in f-strings #112243

pablogsal opened this issue Nov 18, 2023 · 7 comments

Comments

@pablogsal
Copy link
Member

pablogsal commented Nov 18, 2023

After PEP 701, having comments mixed with debug expressions is possible but the interactions has not been discussed. For instance, consider this code:

a = 1
f"{a = # my comment
}"

this produces:

'a = # my comment\n1'

which is surprising. What we should do here? I think we should probably not include the comment but we should agree on the behavior before a PR can be made

Linked PRs

@pablogsal
Copy link
Member Author

@isidentical @lysnikolaou

@ericvsmith
Copy link
Member

I think we should remove the comment and keep the newline.

@terryjreedy
Copy link
Member

I expected the example to produce "SyntaxError: unterminated f-string literal (detected at line 1)", just as it would without the '{'. But given that '{' escapes the newline, I also expect it to escape the octothorpe, just as it does now. So I consider the current behavior correct.

@pablogsal
Copy link
Member Author

@terryjreedy not sure I follow your reasoning, what do you mean when you say that "given that '{' escapes the newline"? There is nothing here being scaped no? Inside an f-string expression now any expression can be made as if it written between parentheses. The key of this issue is the debug expression here

@terryjreedy
Copy link
Member

I was using a different analogy for my expectation. 'a = #com\n3' is a SyntaxError. '''a= #com\n3''' is not, and the comment is keep. Your comment suggests this instead: (a * #com by itself is a Syntaxerror; (a * #com\n3 is not, because the parentheses cause the comment and newline to be ignored.

Even better, I think, are these: f'{a #com\n}' ignores the comment and its terminating newline and prints 1. The a = construct is unusual because 'a =' is quoted while 'a' is executed. What happens with text between '=' and '}'? f'{a=x}' raises SyntaxError: f-string: expecting '!', or ':', or '}'. These examples convince me that a comment after '=' should be recognized as such and ignored rather that quoted as additional text.

As for newlines: whitespace before and after = is kept, whether or not #whatever is present, and newlines can be escaped with \. Leave this alone.

@thecaralice
Copy link

If the expression component of an f-string requires comments, you're probably doing something horribly wrong. That being said, keeping the comment in the resulting string is likely to be the least surprising behavior. Either that or forbidding comments inside f-strings altogether.

@lysnikolaou
Copy link
Contributor

I also think that the comment should be ignored, while the newline should be kept.

pablogsal added a commit to pablogsal/cpython that referenced this issue Nov 20, 2023
pablogsal added a commit to pablogsal/cpython that referenced this issue Nov 20, 2023
…essions (pythonGH-112284)

(cherry picked from commit d59feb5)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants