f-strings were released in Python 3.6 in December 2016. This isn't news.
Python 3's F-Strings: An Improved String Formatting Syntax
141–147 of 147 posts
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#142The issue with f-strings is that they can't be used for i18n. AFAIK, it is impossible to make `_(f"Hello, {name}")` work - at least without a preprocessor or very arcane bytecode manipulation magic. This is unlike much uglier but common and well-supported `_("Hello, %(name)s") % {"name": name}`. In the examples I've used `_` as an alias for a `gettext` call - I believe this is a common practice to do something like `…
This bit of additional functionality in both JS and C# makes their interpolated strings/template literals extremely useful for i18n (and other uses such as query parameterization and injection attack avoidance).
I'm surprised that in comparing the efforts of other languages Python didn't include such functionality in the f-strings PEP. I wonder if such a feature could be added in a non-disruptive way. Maybe a meta-property like a __format_parts__ or something?
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#143Earlier quoted context omitted.
I don't understand. Why exactly is having features that you don't need to use a barrier to entry? Casual programmers can use the same Python that 2.x used - with very little (yet IMO logical) differences. You can get started just as easily and use/learn (or don't) features as you need/wish.
Casual programmers, especially those learning Python as a first programming language, aren't well-placed to know which language features they need. If they're learning from multiple sources and tutorial series A teaches Python 2-style %-formatting, B teaches str.format, and C teaches f-strings, then the novice programmer will learn all of these equivalent features. This also shows up when the novice programmer wants…
Isn't the key though, that they aren't in fact equivalent features at all? %-formatting doesn't allow for mapping names or changing the order of variables. f-strings are just a shorter version of .format() and there's no conceptual difference in usage.
> If there is only one way to do things, then all common examples of a task should use that one way. If there are multiple ways (as here), then common examples (or an open source project of interest) may use any combination of them.
Unfortunately, despite all noble efforts of avoiding this, Python is already full of these. This is true for any sufficiently powerful language. That's why there's idiomatic ways (here: "the Pythonic way") of doing things and "freestyling":
x = []
for i in range(4):
if i % 2 == 0:
x.append(i)
y = []
for i in range(0, 4, 2): y.append(i)
z = [i for i in range(4) if i % 2 == 0]
r = [i for i in range(0, 4, 2)]
s = []
i = 0
while i = 4: break
# x, y, z, r, s, and t will contain the same values
Every one of the snippets above showcases a different
way of doing the exact same thing in Python. Some are
idiomatic, others ugly, some are outright bad code, yet all are perfectly valid Python.How would a novice programmer know which of the above is "good" code and what is the preferred way to do it?
A Python tutorial aimed at kids [1] never even mentions "range()", list-comprehensions, "+=", etc. yet enables children to write games in Python.
A Python intro for non-programmers [2] on the other hand shows both for- and while-loops as well as "range()".
So I'd argue that this is a non-starter as even the very basics as taught by recommended sites from the Python website itself [3] differ greatly in scope.
So I [edit]don't[/edit] find f-strings to be a big deal, especially since string formatting is a rather advanced topic anyway and beginners would stick with
for i in [1, 2, 3, 4, 5, 6, 7]:
print("The number", i, "is", "even" if i % 0 == 0 else "odd")
anyway instead of messing with f-string, %, or "format()" - whoops! - accidentally introduced yet another way of doing it :D[1] http://www.letslearnpython.com/learn/
[2] https://thepythonguru.com/python-loops/
[3] https://wiki.python.org/moin/BeginnersGuide/NonProgrammers
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#144> However, once you start using several parameters and longer strings, your code will quickly become much less easily readable [...] `"Hello, %s %s. You are %s. You are a %s ...` Minor correction: % formatting allows specifying names for dictionary keys too: In [1]: "%(a)s and %(b)s" % {"a":"A", "b":"B"} Out[1]: 'A and B' In fact I had never switched to using str.format as it just never added enough benefit for me ov…
I have mixed feelings about code inside f-strings. It seems like a bit of a slippery slope towards losing track of what's happening. I have been tempted to write things like below because I really just need it for the print. f"Info print for item {hex(do_some_parsing(do_some_conversion(value)))}" Which runs perfectly fine, but at least on my editor syntax highlighting stops working as it is all part of the string. An…
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#145This reminds me of Swift's string formatting syntax: let name = "Bob" print("Hi my name is \(name)") Which I always quite liked. I found myself missing this when I moved on to Rust and Go.
This overloads the backslash \(). Which is usually used for escaping characters. Like, \n for new line. So, you may end up with code like: print(“Hi. \nMy name is \(name).”)
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#146Earlier quoted context omitted.
> But for f-strings, it has full support for the "inline" variables. Is this complete (meaning: it also includes more complicated expressions, referencing these variables)? I'm asking, because some Python development tools are failing in doing it right. This leads to annoying reliability issues for refactorings (even for simple renames). Currently, I have the problem with Wing IDE.
As far as I know yes. It knows that the "usage" of that variable in an f-string is an actual reference to the variable vs just part of the string with the same set of characters. Not sure what you mean by complicated expressions? If you mean the variable is referenced in a complicated statement with calcs or as part of a ternary operator, etc... AFAIK they are all supported. It even understands scope. So it won't go…
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#147Earlier quoted context omitted.
As far as I know yes. It knows that the "usage" of that variable in an f-string is an actual reference to the variable vs just part of the string with the same set of characters. Not sure what you mean by complicated expressions? If you mean the variable is referenced in a complicated statement with calcs or as part of a ternary operator, etc... AFAIK they are all supported. It even understands scope. So it won't go…
I tried it (again). First impression: No support for the black formatter. We have 2021 - really? https://youtrack.jetbrains.com/issue/PY-39750
https://www.jetbrains.com/help/pycharm/configuring-third-par...