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.
Python string literals are kinda funny
21–30 of 67 posts
Re: Python string literals are kinda funny
#22here'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 pa…
Update: They really changed it! (in python 3.12) 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...
Wow, I didn't know this either. I find it a bit crazy. It must make no sense without syntax highlighting. But I suppose who writes code without highlighting any more?
Re: Python string literals are kinda funny
#23I 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.
Re: Python string literals are kinda funny
#24Earlier quoted context omitted.
Update: They really changed it! (in python 3.12) 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...
Wow, I didn't know this either. I find it a bit crazy. It must make no sense without syntax highlighting. But I suppose who writes code without highlighting any more?
It's been a long time since I've had to SSH into a box to fix an issue in production. But it is comforting to know that I _could_.
VI (not even VIM) on minimal Debian installs does not have syntax highlighting.
Re: Python string literals are kinda funny
#25I'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.
I'm a HUGE fan of f-strings and I think they should be added to more or less every language in existence. (This is just to show how much I like f-strings, not to be taken literally) `printf`-style format strings seem outdated: why use format strings when I can put my variables IN THE STRING? I want the result of `x+y` to be put {HERE} in this string. Well, just write `"This is here: {x+y} blah"` — it makes perfect se…
Those aren't the only two options. Like GP I don't like f-strings, but there was something introduced before that: the format function.
"The thing is {foo}, and also {foo} again".format(foo=x+y)
%-based printf-style did also have named variables like this but it seemed less known.
Re: Python string literals are kinda funny
#26Been using python for almost 10 years. I never use any of the funky strings. Instead of reading like 10 PEPs for f strings, I just use the + operator on strings and backslash escaping, big whoop.
age = 32 print(f"Age: {age}") Thus concludes the lecture on f-strings.
I find it funny and satisfying that Python has converged to it's own "printf", by which I mean print(f"").
Re: Python string literals are kinda funny
#27I'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.
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.
How is, say, `age = 5; print(f"Age: {age} years old")` not easy for beginners? IMO it's as easy as it gets: you want the value of `age` printed {HERE}, so you just put it where you want it, surrounded by curly brackets.
Re: Python string literals are kinda funny
#28I'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.
I like f-strings but I don't like that there are at least five ways to format stings.
1. %-formatting [1]
2. str.format [2]
3. string.Template [3]
4. f-string [4]
5. t-string [5]
What happened to "one-- and preferably only one --obvious way to do it"? [6]
Also, the way string formatting interacts with logging is a total mess. People just pass f-strings to logging, which seems to be an intuitive way to do it. Except it limits your options if you want to collect structured logs and it doesn't allow you to use late evaluation based on log level.
[1] https://docs.python.org/3/library/string.html#format-example...
[2] https://docs.python.org/3/library/stdtypes.html#str.format
[3] https://docs.python.org/3/library/string.html#string.Templat...
[4] https://docs.python.org/3/reference/lexical_analysis.html#f-...
[5] https://docs.python.org/3/reference/lexical_analysis.html#t-...
Re: Python string literals are kinda funny
#29I'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.
I like f-strings but I don't like that there are at least five ways to format stings. 1. %-formatting [1] 2. str.format [2] 3. string.Template [3] 4. f-string [4] 5. t-string [5] What happened to "one-- and preferably only one --obvious way to do it"? [6] Also, the way string formatting interacts with logging is a total mess. People just pass f-strings to logging, which seems to be an intuitive way to do it. Except i…
> What happened to "one-- and preferably only one --obvious way to do it"?
There arguably still is—just use f-strings for everything, unless you need to support ancient Python, in which case use %-formatting.
t-strings are a special case, but in theory most functions should only accept regular strings or templates, so there should only be one choice there too.
> Also, the way string formatting interacts with logging is a total mess [...] it doesn't allow you to use late evaluation based on log level.
This all seems to be a side-effect of the fact that string formatting produces static strings, so I don't think that there's much that can be done here (but maybe t-strings can be creatively used here somehow).
Re: Python string literals are kinda funny
#30I'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.
I'm a HUGE fan of f-strings and I think they should be added to more or less every language in existence. (This is just to show how much I like f-strings, not to be taken literally) `printf`-style format strings seem outdated: why use format strings when I can put my variables IN THE STRING? I want the result of `x+y` to be put {HERE} in this string. Well, just write `"This is here: {x+y} blah"` — it makes perfect se…
> why use format strings
Because these are used for locale-specific configuration data. `"This is here: {x+y} blah"` on the other hand isn’t a string (mere data), it’s a program, because you can have arbitrary expressions inside the braces. You don’t want to repeat the `x+y` in each localization file.
I have nothing against ergonomic program constructs for composing strings, but please let’s not confuse such program constructs with mere string literals.