Rendered at 19:59:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dwdz 22 minutes ago [-]
I'm not a fan of f-strings.
I feel like 90% of new Python features in the last 10 years just increased language complexity without any benefit.
analog31 7 minutes ago [-]
Indeed, and I get that one can ignore those features (I do), but finding them in existing code or having the AI coding agent use them diminishes the "easy for beginners" aspect.
xg15 3 days ago [-]
here's a valid f-string:
>>> f'{'}'}'
'}'
Huh? I remember learning the rule that you can't nest quotes inside fstrings if they are the same kind (unlike in bash) - e.g
f"{mydict["foo"]}"
would be a syntax error, but
f"{mydict['foo']}"
or
f'{mydict["foo"]}'
would be valid.
The reason being the same like for the rstring weirdness: The lexer comes first and identifies the string literal, then for fstrings, the python parser is invoked again for each {...} expression to parse it.
This is unlike other nested expressions, which are already split up by the lexer and then parsed in one go.
I feel like 90% of new Python features in the last 10 years just increased language complexity without any benefit.
>>> f'{'}'}' '}'
Huh? I remember learning the rule that you can't nest quotes inside fstrings if they are the same kind (unlike in bash) - e.g
would be a syntax error, but or would be valid.The reason being the same like for the rstring weirdness: The lexer comes first and identifies the string literal, then for fstrings, the python parser is invoked again for each {...} expression to parse it.
This is unlike other nested expressions, which are already split up by the lexer and then parsed in one go.
Did that change at some point?
There was a PEP about it:
https://stackoverflow.com/questions/78388333/nested-quotes-i...
https://docs.python.org/3.12/whatsnew/3.12.html#pep-701-synt...