On 5/20/2019 10:32 AM, Batuhan Taskaya wrote:
> > 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
> 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?
>
> 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.
>
> I don't think we should complicate this. The current version is very
> simple and understandable.
I think the salient question is: does the lack of expr_text make
anything more difficult for anyone? As Serhiy said in the other email,
lots of things are lost while round-tripping, this would just be another
one. Anyone really interested in high-fidelity round trips already can't
use the ast module to unparse from.
Eric
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4