(original) (raw)
> This strictly speaking isn't necessary. I could have added another
Constant node for "x=" and left FormattedValue alone. I didn't for three
reasons: it was expedient; it didn't require a lot of surgery to
f-string parsing, which the extra Constant node would require; and it
allowed the Python/ast\_unparse.c code to produce a string that was more
Constant node for "x=" and left FormattedValue alone. I didn't for three
reasons: it was expedient; it didn't require a lot of surgery to
f-string parsing, which the extra Constant node would require; and it
allowed the Python/ast\_unparse.c code to produce a string that was more
consistent with input string.
Agreed.
> Does anyone care that f'{x=}' would become f'x={x!r}' if I removed
expr\_text from the FormattedValue node?
expr\_text from the FormattedValue node?
Yes, when i was implementing f-string debugging support to Berker's astor project
the roundtrip tests i wrote is failing because of it adds an extra \`!r\` to end. Then
i realized you added a new field (expr\_text) for that.
> I'm not sure how much we care about all of this, but let me know if you
have a strong feeling about it.
have a strong feeling about it.
I don't think we should complicate this. The current version is very simple and understandable.