Funny (as in debugging-useful) print format in Python

[RoGeorge]

Found in these random YT suggested videos from Indently channel:
https://youtu.be/EoNOWVYKyo0
https://youtu.be/aa39jL7wdJs

Code: [Select]

a: int = 5000
b: int = 10000
print(f'{a + b = }')
in python 3 will print "a + b = 15000" 
Or, print(f'{a + b = :_.2f}') will print "a + b = 15_000.00" 

[bpiphany]

Python 3.11 or 12 or so to be more specific. Where you may not yet be depending on how far back on the LTS chain you exist.

[SiliconWizard]

Yeah, f-strings allow some funky stuff.
https://realpython.com/python-f-strings/

[janoc]

F-strings are old news, this was added in Python 3.6, back in 2016. I.e. almost a decade back:

https://www.python.org/downloads/release/python-360/

PEP 498, Literal String Formatting

[tszaboo]

Found in these random YT suggested videos from Indently channel:
https://youtu.be/EoNOWVYKyo0
https://youtu.be/aa39jL7wdJs

Code: [Select]

a: int = 5000
b: int = 10000
print(f'{a + b = }')
in python 3 will print "a + b = 15000" 
Or, print(f'{a + b = :_.2f}') will print "a + b = 15_000.00" 

IMHO this falls under the category of programming for side effects.
Which is bad practice.
f string is there to substitute a part of a string with something. So f'{a]' is OK. f'{max(a)}' is questionable, your example is bad practice. Only reason to do it is if there is like a list comprehension or some other code quality reasons, and still you want to have a lot of comments on what the line does. Because 5 minutes from now nobody is going to understand it.

[DiTBho]

this falls under the category of programming for side effects.
Which is bad practice.

An almost incredible tale of "triumph" and "tragedy", but ...
... there is actually people who writes book about this stuff.

what? 

I saw books in Japan about this for CASIO graphing programming calculators.
Practices used onto CASIO Basic + ucPython to take the control via exploits
made on "side effects" that break the interpreter.

[golden_labels]

IMHO this falls under the category of programming for side effects.(…)

This expression has no side effects. That = is a part of the formatting language. This way you can print the expression and its value without having to duplicate code. See the last example. RoGeorge just used a more complicated expression.

[ejeffrey]

IMHO this falls under the category of programming for side effects.
Which is bad practice.

It's neither programming for side effects not bad practice.

f string is there to substitute a part of a string with something.

Which is what it does?

Because 5 minutes from now nobody is going to understand it.

It displays the value of the expression?  I honestly don't know what your are getting at.

[golden_labels]

I suspect tszaboo took that for some obscure quirk of Python. His reply would make sense then.

[tszaboo]

IMHO this falls under the category of programming for side effects.
Which is bad practice.

It's neither programming for side effects not bad practice.

f string is there to substitute a part of a string with something.

Which is what it does?

Because 5 minutes from now nobody is going to understand it.

It displays the value of the expression?  I honestly don't know what your are getting at.

It's bullshit side effect of a design feature, that wasn't intended to be used this way.
Programmers who write code like this make code like this make unmaintainable code.
It's the equivalent of bragging: "Look at me. I'm so smart. I made a calculation implicit instead of explicit. I also obfuscated the code and made it hard to read and understand. "
Nobody likes these people.

[jfiresto]

IMHO this falls under the category of programming for side effects.
Which is bad practice.

It's neither programming for side effects not bad practice.

f string is there to substitute a part of a string with something.

Which is what it does?

Because 5 minutes from now nobody is going to understand it.

It displays the value of the expression?  I honestly don't know what your are getting at.

It's bullshit side effect of a design feature, that wasn't intended to be used this way....

Except that is isn't. The language grammar page gives the syntax. The proposal for its implementation explains its rationale.

[tszaboo]

It is bullshit.
It might print "a + b = 15000" or "5000 + 10000 = " or SyntaxError: invalid syntax
You have no idea what it should print. Bad practice.
There is a more understandable and explicit way of achieving the same.

[ejeffrey]

You have no idea what it should print..

I definitely know exactly what it should print.  It's an explicit design feature and everybody who uses it knows what it does. 

It's also the best way to implement it because there is no chance of mismatch between the printed text and the evaluated expression.  For instance if you do print(f"a+b={a + b}") and later modify it to print(f"a+b={a+b+c}") you are going to have incorrect diagnostic messages.  Same thing if you use a separate temporary variable in the same way. print(f"{a+b=}") on the other hand works correctly with less opportunity for error.

[bpiphany]

I was wrong. The equals thing for f-strings was added in 3.8. I believe it was primarily meant as a convenience for debugging, not production code so much.

[ejeffrey]

I was wrong. The equals thing for f-strings was added in 3.8. I believe it was primarily meant as a convenience for debugging, not production code so much.

I would say it's useful for both debugging (a development task) and logging (a production task).  I wouldn't use it for a something end user visible or for persistent serialization.  But that has nothing to do with "side effects" or it being poorly defined.  It's just usually not desirable to export your internal identifier names to end users or to make it part of your behavior contract.

[John B]

I don't really mind that it does it, however it does seem to lack logical consistency in that the curly brackets should be evaluated like a normal line of code. It looks like it should throw a syntax error.

But then again, I'm not a python pythonista who thinks pythonically.

[ejeffrey]

I don't really mind that it does it, however it does seem to lack logical consistency in that the curly brackets should be evaluated like a normal line of code. It looks like it should throw a syntax error.

It is slightly inconsistent but the fstring  already allowed formatting specifiers in the same location like f"{x:.5f}". So it's never been the case that the entire thing in braces is evaluated as an expression. The way it is inconsistent is that it doesn't map to a .format() option because this behavior doesn't make sense for the format method.

[golden_labels]

Permitting format specifiers is no more inconsistent than allowing expressions.

F-strings are Python’s implementation of string interpolation. To be exactly consistent with the pure concept of string interpolation, an f-string should permit nothing more than a single variable name inside curly braces. The style PHP and sh do this with $ (without {…}).

Most languages do extend this basic concept for programmer’s convenience. So does Python, giving us both: expressions and format specifiers. The only quirk of Python is, that it accepts unexpectedly wide range of expressions.⁽¹⁾ But not only it hasn’t been touched in this topic, but what it makes “inconsistent with the idea” is expressions themselves, not the format specifiers.

Note that it should really be “intuitional consistency,” not “logical consistency.” If we’re to be precise.

⁽¹⁾ Those are valid f-strings, despite you probably don’t want them to be:

Code: [Select]

a = f'{" "}'
print(a)

x = 0
b = f'{(x:=4)}'
print(b, x)

y = 10
c = f'{#
    y}'
print(c)

o = {'Foo': 'Bar'}
d = f'{o.pop("Foo")}'
print(d)

it = iter([0, 1, 2, 3])
e = f'{next(it)} {next(it)} {next(it)} {next(it)}'
print(e)

z = None
g = f'{(z := lambda x: x + 4, z(10))[1]}'
print(g)


[SiliconWizard]

The problem with allowing arbitrary expressions in string formats is to allow unwanted execution of code, obviously. How does Python protect against that?

[bpiphany]

But it's not arbitrary any more than what you as the programmer put in there, is it? It's perfectly possible to "execute" arguments to f-formatting in other languages too. The only thing the '=' does is to output the argument as a string as well as the result of it, if I understand it correctly.

[ejeffrey]

The problem with allowing arbitrary expressions in string formats is to allow unwanted execution of code, obviously. How does Python protect against that?

f-string parsing is part of the parser so it only works on string literals, never user input strings.  Essentially the whole f-string implementation is syntactic sugar around the "format" method.

Code: [Select]

print(f"{x}, {y}, {z}")

is transformed by by the parser into:

Code: [Select]

print("{0}, {1}, {2}".format(x, y, z))

Outside of eval() there isn't even an API that would let you inject arbitrary expressions into the formatting code.  It's still true that it puts executable code into something that might look like a string literal.  However any code editor will syntax highlight it as code not string literals.

The = operators is also handled specially by the parser.

Code: [Select]

print(f"{x=}, {y+z}")

is transformed into:

Code: [Select]

print("x={0}, y+z={1}".format(x, y+z))

That is, the parser takes the expression between braces and inserts it both as text into the resulting string literal and also as an argument to the format method.

[SiliconWizard]

The problem with allowing arbitrary expressions in string formats is to allow unwanted execution of code, obviously. How does Python protect against that?

f-string parsing is part of the parser so it only works on string literals, never user input strings.  Essentially the whole f-string implementation is syntactic sugar around the "format" method.

Ok. If there's absolutely no means of building a f-string dynamically, then it kind of answers my question.

There's a simple way of circumventing this though, and it's by using eval():

Code: [Select]

x, y, z = 1,2,-3

F1 = "{x+y*z}"

eval('f"' + F1 + '"')

Now you may reply that it's a potential security issue that has more to do with eval() than with f-strings themselves. But can you build and use f-strings dynamically (resorting to eval()), yes.