Live data from Hacker News

Python string literals are kinda funny

sebsite.pw

51–60 of 67 posts

Re: Python string literals are kinda funny

#51
post #36
post #14

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.

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.

Re: Python string literals are kinda funny

#52
post #48

Earlier 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.

Nope, you can put expressions in them:

f'{a} = {functionThatReturnsAButHasSideEffects()}'

Re: Python string literals are kinda funny

#53
post #12

Earlier 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.

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

#55
post #18

Whenever I read people's takes about Python on HN, I always feel like I'm using an entirely different language.

That you know how to use the language without such oddities presenting any difficulty does not make them less strange. That r-string parsing solution is fine for the interpreter, but we are not interpreters, so it's not a logical outcome for Python authors,

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

#56
post #51
post #36

Earlier 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.

> 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.

Re: Python string literals are kinda funny

#57

Earlier 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.

You and Claude agree. ;-) And me too, I must admit.

Re: Python string literals are kinda funny

#58
post #34
post #15

Earlier 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

#59
post #56
post #51

Earlier 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.

But the link you shared describes a syntax that is very different.

"%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

#60
post #3
post #2

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 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...

Interesting read. I had no ides that they switched the parser https://peps.python.org/pep-0617/
Post reply on HN