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.
Not really about the content of the blog post but am I the only one bothered by the complete lack of capitalization? Granted it may be because of my screen reader but my TTS engine of choice doesn't pause on un-capitalized words/sentences/phrases/etc. which follow a full stop, so this post unless I read it line by line (minus the code) just blends into complete noise.
I think this is pretty intuitive (I was able to answer the question correctly before opening the spoiler), but I really like raw string designs in Rust and C++11 that allow you to stop worrying about escaping completely.
In his 2017 PyCon Israel keynote, "The Fun of Reinvention", Dave Beazley made a wonderfully mischievous case for taking advantage of new Python features instead of making every new project carry the accumulated baggage of old Python versions.
Talking about Python 3.6, he said it was "probably one of the most major Python releases that has ever been made." His demonstration intentionally used new features that made the code incompatible with older interpreters. This was a prototype, so why not use the interesting new tools?
He was especially enthusiastic about f-strings: "F-strings are just awesome."
I was originally skeptical about them, but he convinced me to reconsider. One implementation detail that later helped win me over was that CPython 3.6 added dedicated FORMAT_VALUE and BUILD_STRING opcodes for f-strings. That does not mean an f-string is faster than simply doing a + b when both values are already strings -- simple concatenation usually wins that particular race -- but f-strings are generally cleaner, and often faster than older formatting machinery such as str.format().
I agree with his argument. There are vanishingly few situations in which a new project genuinely must support ancient Python releases. If your employer refuses to let you use a reasonably current version without a concrete technical reason, that is a warning sign. Life is too short to program indefinitely for obsolete interpreters.
11 comments
[ 3.7 ms ] story [ 20.7 ms ] thread>>> 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?
I feel like 90% of new Python features in the last 10 years just increased language complexity without any benefit.
Instead of reading like 10 PEPs for f strings, I just use the + operator on strings and backslash escaping, big whoop.
Talking about Python 3.6, he said it was "probably one of the most major Python releases that has ever been made." His demonstration intentionally used new features that made the code incompatible with older interpreters. This was a prototype, so why not use the interesting new tools?
He was especially enthusiastic about f-strings: "F-strings are just awesome."
I was originally skeptical about them, but he convinced me to reconsider. One implementation detail that later helped win me over was that CPython 3.6 added dedicated FORMAT_VALUE and BUILD_STRING opcodes for f-strings. That does not mean an f-string is faster than simply doing a + b when both values are already strings -- simple concatenation usually wins that particular race -- but f-strings are generally cleaner, and often faster than older formatting machinery such as str.format().
I agree with his argument. There are vanishingly few situations in which a new project genuinely must support ancient Python releases. If your employer refuses to let you use a reasonably current version without a concrete technical reason, that is a warning sign. Life is too short to program indefinitely for obsolete interpreters.
The keynote:
https://www.youtube.com/watch?v=js_0wjzuMfc
Beazley's other talks:
https://www.dabeaz.com/talks.html