FSTRING Start is not preserved in AST causing issue in `ast.unparse`

[Thamirawaran]

Bug report

Bug description:

import ast
code = """
f"My name is {name}"
rf"My name is {name}"
"""
print(ast.dump(ast.parse(code), indent=4))
ast_obj = ast.parse(code)
print(ast.unparse(ast_obj))

output

Module(
    body=[
        Expr(
            value=JoinedStr(
                values=[
                    Constant(value='My name is '),
                    FormattedValue(
                        value=Name(id='name', ctx=Load()),
                        conversion=-1)])),
        Expr(
            value=JoinedStr(
                values=[
                    Constant(value='My name is '),
                    FormattedValue(
                        value=Name(id='name', ctx=Load()),
                        conversion=-1)]))],
    type_ignores=[])
f'My name is {name}'
f'My name is {name}'

CPython versions tested on:

3.12

Operating systems tested on:

Linux

[StanFromIreland]

I can reproduce this on main. JoinedStr has no kind field like Constant (added in 10f8ce6) to preserve the prefix, however, it ignores r so the only prefix that would be preserved here would be u.

[ericvsmith]

ast.unparse only guarantees equivalence, not identical round-tripping. Is there a case where a non-equivalent f-string is produced?

[lysnikolaou]

This is not related to FSTRING_START or f-strings for that matter. It's related to how the r prefix works. It's not preserved for regular strings either.

Also, like @ericvsmith said, ast.unparse only guarantees equivalence. In practice this means that if you parse/unparse/parse again, the two AST trees from doing two rounds of parsing should be the same, but the unparsed code is not guaranteed to be identical to the one you originally provided.

If there's an example where this is not the case, that's a bug we should fix. Otherwise, I feel like this can be closed as not-a-bug.