4 ms·

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.

by dwdz 2mo ago

analog31 2mo 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.
- orf 2mo ago
  Are f-strings not easy for beginners? What would you prefer instead?
  - analog31 2mo ago
    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.
    - Daishiman 2mo ago
      Your one way is f-strings, that's it. Disregard the others unless you have an extremely good reason not to.
      - analog31 2mo ago
        You and Claude agree. ;-) And me too, I must admit.
- ForceBru 2mo ago
  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.
  - deleted 2mo ago
    [deleted]
ForceBru 2mo ago
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 sense and immediately lets me see what the resulting strings generally look like. Basic usage is a no-brainer: write your string, put variables or short expressions in curly braces, add `printf`-style format specifiers after the colon. This is also great because it's a natural extension of `printf`-style format strings. Of course you can write complicated and confusing f-strings. But then you can write complicated and confusing... anything, really. Many programming languages have extremely weird quirks and cases where basic syntax can be transformed into an unreadable monstrosity, like C syntax for pointers to functions and arrays. Sure, this increases the language's complexity, but you don't have to use all of it to reap the benefits.
- Izkata 2mo ago
  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) It also supports positional with empty {}. And like f-strings, you can put formatting information after a colon. %-based printf-style did also have named variables like this but it seemed less known.
  - circuit10 2mo ago
    This is still significantly more clunky than f-strings, especially when you're writing them a lot for debugging purposes
- layer8 2mo ago
  > 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.
ajrouvoet 2mo ago
It is baffling to me that Python seems to insist on reinventing language features and coming up with the most incomprehensible of designs. The whole dataclass and serialisation ecosystem comes to mind, as well as the evolution of typing. The language exposes so much of its internals that even if the design were consistent, the ecosystem of (buggy) libs and tools makes it inconsistent.
- LPisGood 2mo ago
  PKL files and the entire multiprocessing paradigm is one of the worst experiences I’ve ever had with a programming language feature. Surely there has to be a better way.
vova_hn2 2mo ago
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-examples https://docs.python.org/3/library/string.html#format-example... [2] https://docs.python.org/3/library/stdtypes.html#str.format https://docs.python.org/3/library/stdtypes.html#str.format [3] https://docs.python.org/3/library/string.html#string.Template https://docs.python.org/3/library/string.html#string.Templat... [4] https://docs.python.org/3/reference/lexical_analysis.html#f-strings https://docs.python.org/3/reference/lexical_analysis.html#f-... [5] https://docs.python.org/3/reference/lexical_analysis.html#t-strings https://docs.python.org/3/reference/lexical_analysis.html#t-... [6] https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/
- gucci-on-fleek 2mo ago
  > 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).
  - deleted 2mo ago
    [deleted]
  - vova_hn2 2mo ago
    > maybe t-strings can be creatively used here somehow Maybe they could, but I would be the first to oppose introducing creative ways to do logging or string formatting. Such basic things should be done in the most standard way possible to reduce cognitive effort required to read and understand the code. But the standard way is kinda ugly. Most people would expect f-strings to be used for "normal" string formatting and %-style to be used for logging, because it is the default and most codebases do it this way. Therefore, you basically forced to have (at least) two different formatting syntaxes in your codebase. I say "at least", because if the program serves html pages, you most likely also have some other template engine like jinja...
odyssey7 2mo ago
It doesn’t have to be beneficial, it just has to be “pythonic.”
deleted 2mo ago
[deleted]

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.

by dwdz 2mo 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 2mo 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.

orf 2mo ago
Are f-strings not easy for beginners? What would you prefer instead?
- analog31 2mo ago
  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.
  - Daishiman 2mo ago
    Your one way is f-strings, that's it. Disregard the others unless you have an extremely good reason not to.
    - analog31 2mo ago
      You and Claude agree. ;-) And me too, I must admit.
ForceBru 2mo ago
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.
- deleted 2mo ago
  [deleted]

ForceBru 2mo ago

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 sense and immediately lets me see what the resulting strings generally look like. Basic usage is a no-brainer: write your string, put variables or short expressions in curly braces, add `printf`-style format specifiers after the colon. This is also great because it's a natural extension of `printf`-style format strings. Of course you can write complicated and confusing f-strings. But then you can write complicated and confusing... anything, really. Many programming languages have extremely weird quirks and cases where basic syntax can be transformed into an unreadable monstrosity, like C syntax for pointers to functions and arrays. Sure, this increases the language's complexity, but you don't have to use all of it to reap the benefits.

Izkata 2mo ago
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) It also supports positional with empty {}. And like f-strings, you can put formatting information after a colon. %-based printf-style did also have named variables like this but it seemed less known.
- circuit10 2mo ago
  This is still significantly more clunky than f-strings, especially when you're writing them a lot for debugging purposes
layer8 2mo ago
> 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.

ajrouvoet 2mo ago

It is baffling to me that Python seems to insist on reinventing language features and coming up with the most incomprehensible of designs. The whole dataclass and serialisation ecosystem comes to mind, as well as the evolution of typing. The language exposes so much of its internals that even if the design were consistent, the ecosystem of (buggy) libs and tools makes it inconsistent.

LPisGood 2mo ago
PKL files and the entire multiprocessing paradigm is one of the worst experiences I’ve ever had with a programming language feature. Surely there has to be a better way.

vova_hn2 2mo ago

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-examples https://docs.python.org/3/library/string.html#format-example... [2] https://docs.python.org/3/library/stdtypes.html#str.format https://docs.python.org/3/library/stdtypes.html#str.format [3] https://docs.python.org/3/library/string.html#string.Template https://docs.python.org/3/library/string.html#string.Templat... [4] https://docs.python.org/3/reference/lexical_analysis.html#f-strings https://docs.python.org/3/reference/lexical_analysis.html#f-... [5] https://docs.python.org/3/reference/lexical_analysis.html#t-strings https://docs.python.org/3/reference/lexical_analysis.html#t-... [6] https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/

gucci-on-fleek 2mo ago
> 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).
- deleted 2mo ago
  [deleted]
- vova_hn2 2mo ago
  > maybe t-strings can be creatively used here somehow Maybe they could, but I would be the first to oppose introducing creative ways to do logging or string formatting. Such basic things should be done in the most standard way possible to reduce cognitive effort required to read and understand the code. But the standard way is kinda ugly. Most people would expect f-strings to be used for "normal" string formatting and %-style to be used for logging, because it is the default and most codebases do it this way. Therefore, you basically forced to have (at least) two different formatting syntaxes in your codebase. I say "at least", because if the program serves html pages, you most likely also have some other template engine like jinja...

odyssey7 2mo ago

It doesn’t have to be beneficial, it just has to be “pythonic.”

deleted 2mo ago

[deleted]