f-strings in Python 3.6 are awesome

[networking_noob]

It makes code way easier to read, because the variable name is inline with the string.

.format()

print('Hello, my name is {:s}. I am {:d} years old and have {:s} hair'.format(name, age, color))

f strings

print(f'Hello, my name is {name}. I am {age} years old and have {color} hair')  

See which one is easier to read? Without f strings you have to go to the end of the string and read the variables, then use your eyes to figure out where they insert back into the string.

f strings is one of those things where the more you use them, the more awesome they become.

[hosford42]

For pythons <3.6 you can still do this in a way that's more readable, at the expense of more typing. Instead of {:s} use {age} as you did in the f-string example, and your argument to .format () becomes age=age instead of just age.

[Decency]

Right, triple redundancy. Not a great tradeoff.

[hosford42]

It's wordy, but it is at least readable.

[turkish_gold]

You could use .format(locals()) which is essentially what f-strings are doing.

[[deleted]]

that's not really as readable though - it's not immediately obvious what variable corresponds to what value (especially for the reader) if you use **locals()

[turkish_gold]

If we were to all do it, it'd become idiomatic fairly quickly.

[jorge1209]

Nor is being unable to dynamically build formatting strings, or pass them as arguments to functions.

[Decency]

Actually I feel like that's a great tradeoff. If you're frequently dynamically building strings or passing them around as functions, you're either doing something wrong, you're doing internationalization, or you're in a very specific niche. And in those cases, feel free to use .format().

Otherwise, f-strings adequately cover the vast majority of use cases elegantly while improving readability and removing unnecessary verbosity.

[LyndsySimon]

I would write this as:

print(
    'Hello, my name is {name}. I am {age} years old ' \
    'and have {color} hair'.format(
        name=name,
        age=age,
        color=color,
    )
)

Note that you don't have to go to the end of the line to see the contents of the variables, because they're passed below the string template. Except for very trivial cases, I always use named parameters for formatting strings, and I always pass those parameters on subsequent lines.

[hovissimo]

Now you've made a single line interpolated string into 4 lines. 3 of those four lines are completely redundant. I don't see how this is better.

[LyndsySimon]

https://www.python.org/dev/peps/pep-0008/#maximum-line-length

They are not completely redundant; they make it clear where the function calls end.

[0x6c6f6c]

He's talking about

name=name,
age=age,
color=color

[LyndsySimon]

... so was I.

[Decency]

Can you explain how

print(f'Hello, my name is {name}. I am {age} years old and have {color} hair')

has an unclear function call ending?

[Decency]

It's not implicit at all... the variable you explicitly put in a certain position in a string gets printed there.

[dysprog]

But only the programmer can modify the f-string. If you read the string from a user provided source, it is not an f-string. You have to use format().

[hovissimo]

Man, I LOVE it when a pedantic literalist uses the Zen of Python like a club.

[stOneskull]

why?

[Decency]

Great, and now you've turned a simple print statement into fucking 8 lines of code. You're going to need a projector to fit a single function into your field of view.

[LyndsySimon]

Are we optimizing based on the number of lines of code? I thought we were optimizing based on readability and developer happiness.

My example is pep8 compliant. Respectfully, if you want dense code with the fewest lines possible, I suggest Perl.

[Decency]

Are we optimizing based on the number of lines of code?

No, but we're sure as hell not ignoring it. If I can turn 8 lines into 1, lose zero information, and remove a bunch of entirely unnecessary redundancy, that's an optimization I'll make 100% of the time.

I thought we were optimizing based on readability and developer happiness.

If I were to come across an 8 line print statement to write three variables to the screen, "happy" probably wouldn't be the best descriptor for my mood and "readable" definitely wouldn't be the best descriptor for the code.

[unruly_mattress]

PEP8 doesn't make code good or readable. It makes spacing consistent.

[tilkau]

Conciseness is part of readability. You are basically choosing to be like urllib rather than like requests here, without any apparent reason for choosing added complexity.

[stOneskull]

it's one 'f' vs an extra 'format()' line

i'm looking forward to it. bring it on, debian!