[issue37003] ast unparse does not support f-string new debug format.

Matthias Bussonnier added the comment: I believe all is fine now. Thanks ! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker _

[issue37003] ast unparse does not support f-string new debug format.

Eric V. Smith added the comment: mbussonn: can you re-check this in light of the changes for issue37050? I'm not sure if there's still a problem that needs fixing or not. -- ___ Python tracker _

[issue37003] ast unparse does not support f-string new debug format.

Pablo Galindo Salgado added the comment: > Notice that test_tools will fail if f'{x=}' becomes f'x={x!r}' I arrived at the wrong conclusion as Matthias points out. >>> import ast >>> ast.dump(compile("f'{x=}'","","exec",ast.PyCF_ONLY_AST)) "Module(body=[Expr(value=JoinedStr(values=[Formatted

[issue37003] ast unparse does not support f-string new debug format.

Pablo Galindo Salgado added the comment: Actually, it checks if the dump is the same: class ASTTestCase(unittest.TestCase): def assertASTEqual(self, ast1, ast2): self.assertEqual(ast.dump(ast1), ast.dump(ast2)) def check_roundtrip(self, code1, filename="internal"): as

[issue37003] ast unparse does not support f-string new debug format.

Matthias Bussonnier added the comment: I thought it was comparing the AST of the file to the AST of the unparsed AST. So it's actually checking if parse(unparse(x)) is indempotent and not wether parse(unparse(x)) is indempotent. So x={x!r} should be fine. On Wed, May 22, 2019, 09:22 Pablo Ga

[issue37003] ast unparse does not support f-string new debug format.

Pablo Galindo Salgado added the comment: Notice that test_tools will fail if f'{x=}' becomes f'x={x!r}' when unparsed as it compares the text of the file and the text of the roundtrip of the ast of the file -- nosy: +pablogsal ___ Python tracker

[issue37003] ast unparse does not support f-string new debug format.

Eric V. Smith added the comment: Thanks for the recap, Matthias. Once I remove expr_text (hopefully this weekend!), we should still at least add tests to make sure nothing fails, even with the ast-expanded version of the = f-strings. -- ___ Python

[issue37003] ast unparse does not support f-string new debug format.

Matthias Bussonnier added the comment: Just for clarification for future readers; I landed a PR that used f"{x=}" in some new functionalities, and that broke the buildbots, the buildbots do test that many of the `Lib/` files can be round-tripped ast->unparse->ast, and as ast-unparse did not

[issue37003] ast unparse does not support f-string new debug format.

Eric V. Smith added the comment: Never mind on the failing code. I see your test cases now. -- ___ Python tracker ___ ___ Python-bu

[issue37003] ast unparse does not support f-string new debug format.

Eric V. Smith added the comment: I don’t think this is worth changing. I’m planning on removing the expr_text field before beta 1. At which point I don’t think there will be any work to do here. See https://mail.python.org/pipermail/python-dev/2019-May/157493.html Also, can you explain what

[issue37003] ast unparse does not support f-string new debug format.

Change by Larry Hastings : -- assignee: -> eric.smith nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue37003] ast unparse does not support f-string new debug format.

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +13387 stage: -> patch review ___ Python tracker ___ ___ Python-

[issue37003] ast unparse does not support f-string new debug format.

New submission from Matthias Bussonnier : All in title, f"{x=}" implemented in https://bugs.python.org/issue36817 are not liked by unparse: https://github.com/python/cpython/pull/13473, -- components: Library (Lib) messages: 343105 nosy: mbussonn priority: normal severity: normal statu