And now for something completely different: Python 3.12 Python 3.12, the latest stable release of the Python programming language, was released on Monday, offering developers a handful of new capabilities and the removal of some cruft. The revision arrives almost a year after the previous stable release, Python 3.11. Python has recently been ranked the most popular, second most …
> are really ex-Pythons ...
The formal definition of ex-Python: "This Python is no more. It has ceased to be. It's expired and gone to meet its maker. This is a late Python. It's stiff. Bereft of life, it rests in peace. It's rung down the curtain and joined the choir, invisible. This is an ex-Python."
> f-strings can now handle multi-line expressions, comments, backslashes, and Unicode escape sequences.
They can even handle infinitely nested f-strings. Here is the example they proudly give for that:
.. f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}" # (outputs '2').
I am firmly of the conviction that if you ever use multiply nested f-strings * or worse, multi-line sub-expressions, in your f-string literals so as to make your python code unreadable you are a monster. At that point you might as well just be writing perl for maintainability.
* There is one non-criminal use for all this, which is programmatic string composition. i.e., your f-string includes a variable which contain another f-string(s), and things get evaluated till there's none left. As long as people stick to this things will be fine. But you know some people will commit horrors just because it's allowed.
>f-string includes a variable which contain another f-string(s)
Try:
bar = "foo"
f = f"{bar}"
f
# 'foo'
f = "f" + "{bar}"
def getbar(bar):
return f"{bar}"
getbar(f)
# 'f{bar}'
(Copy and paste into text editor insert required spaces then copy and paste into a Python 3.12 interpreter/REPL; El Reg does not permit computer code...)
Probably not what you expected; I've been running 3.12 for a while so I just tried it.
getbar(f"{bar}")
'works' but f"{bar}" is resolved *before* the function call (the result is 'foo').
Now there is always the funarg problem. But while McCarthy maybe didn't realize it was hiding in LISP (I was taught it as the "mapcar" problem, I believe they are the same but don't quote me) I suspect the Python guys know about it. After all they were brave, or stupid, enough to implement lambda expressions. C++ too. Lua just does it too; I much like Lua but haven't checked it for the funarg problem since I hope not to make that mistake.
Entertaining reading for those still here:
https://groups.google.com/g/comp.lang.lisp/c/3CkNwKawXos?pli=1
Only Python:
[on_true] if [expression] else [on_false]
because every other language specifying
[expression] ? [on_true] : [on_false]
was so boring?
Also, Pythons no brackets means no auto format.
Auto format makes revision control easier to read assuming all participants use the same auto format.
I think you answer your second question yourself.
I've never liked ternary expressions and avoid the Python version preferring full boolean evaluation. It's not much more typing but it is more explicit. Ternarys were added to Python because people kept demanding them but I don't think they're frequent in practice. Having read enough nested ternarys in my time, I'm very much against this kind of abbreviation over clarity. YAGNI is a good argument for not introducing something – I'm looking at the "walrus" monstrosity.
What I think will gain more traction over time is the newish match…case construction. Though this has quite a few quirks and gotchas in it that probably need working out first before it sees wide adoption.
In over twenty years of working with Python code I've never found this to be a problem. It happens occasionally and is easy to fix but most editors mean you don't have to think about it.
The people who complain about whitespace in Python are usually those who've never used it, but find their software stack is often full of Python tools.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
