Earlier quoted context omitted.
Right, because x + " " + y is more clear than of simply f"{x} {y}". Been using python for longer than 10 years and immediately started using f-strings when I could. It takes almost no time to understand the basics.
Personally I do find the first version clearer, because it is based on general language rules.
Python string literals are kinda funny
51–60 of 67 posts
Re: Python string literals are kinda funny
#52Earlier quoted context omitted.
In Python, that less hazardous string concatenation operator is an f-string.
I’m assuming you can only use it with string literals, hence it is less universally useful.
f'{a} = {functionThatReturnsAButHasSideEffects()}'
Re: Python string literals are kinda funny
#53Earlier quoted context omitted.
Are f-strings not easy for beginners? What would you prefer instead?
I'd prefer one way of doing things. I do understand that the improvements to string literals are improvements, but it means there are multiple things to learn.
Re: Python string literals are kinda funny
#54I'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.
Re: Python string literals are kinda funny
#55Whenever I read people's takes about Python on HN, I always feel like I'm using an entirely different language.
The most puzzling thing is few languages use the absolute simplest solution to escaping quotes, which happens to be especially useful for non-expanded literals, and that's good ol' quote-doubling. Difficult for Python to introduce now since it'd be a bc-break for implied concatenation, but if space were required between them, we could have had
x = r'ex\x20cape!\'
y = 'diff''rent'
z = 'diff' 'erent'
respectively containing
ex\x20cape!\
diff'rent
different
TOML has a similar issue: it is impossible to store its delimiter for non-expanded multi-line strings inside a multi-line non-expanded string. There's no method to escape it. Whilst this is rarely an issue in practice, it's odd that there's unnecessary difficulty in writing about TOML inside a TOML document. Again, it could have used the simpler quote-doubling method for all strings (even easier because no concatenation), with similar rules for non-expanded and multi-line variants. Then there would be no limitation on what can be stored in any literal type. Instead it has a peculiarity that's illogical and offers no benefit to us authors.
Re: Python string literals are kinda funny
#56Earlier quoted context omitted.
Personally I do find the first version clearer, because it is based on general language rules.
Especially if you come from other languages. a + " " + b will be clearer to devs that aren't senior python developers. the f string thing is just a marginal improvement at the cost of alienating other devs. But it's great for gatekeeping and job security.
According to Wikipedia[1] the history of string formatting goes back to 1950s. Also, basically every major programming language these days implements it in some form.
[1] https://en.wikipedia.org/wiki/Printf
> senior python developers > great for gatekeeping and job security
Ah, okay, it's just a troll.
Re: Python string literals are kinda funny
#57Earlier quoted context omitted.
I'd prefer one way of doing things. I do understand that the improvements to string literals are improvements, but it means there are multiple things to learn.
Your one way is f-strings, that's it. Disregard the others unless you have an extremely good reason not to.
Re: Python string literals are kinda funny
#58Earlier quoted context omitted.
age = 32 print(f"Age: {age}") Thus concludes the lecture on f-strings.
It’s unclear what the big advantage is over `print("Age: "+age)`. It’s even more characters, in that specific example.
>>> age = 32
>>> print("Age: " + age)
Traceback (most recent call last):
File "", line 1, in
TypeError: can only concatenate str (not "int") to str
>>> print("Age: " + str(age))
Age: 32
As a side note, I always found it amusing that Python is dynamic but doesn't let you do this, while C# has static typing but lets you do string + number. (I looked into it a while back, I think it's because both are Object, so it does operator overloading on Object+Object and then checks the types...)Re: Python string literals are kinda funny
#59Earlier quoted context omitted.
Especially if you come from other languages. a + " " + b will be clearer to devs that aren't senior python developers. the f string thing is just a marginal improvement at the cost of alienating other devs. But it's great for gatekeeping and job security.
> come from other languages According to Wikipedia[1] the history of string formatting goes back to 1950s. Also, basically every major programming language these days implements it in some form. [1] https://en.wikipedia.org/wiki/Printf > senior python developers > great for gatekeeping and job security Ah, okay, it's just a troll.
"%T", T t
not "{ (expr).__str__()} "
> Ah, okay, it's just a troll.If that helps you sleep at night
Re: Python string literals are kinda funny
#60here'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...