Forbid using f strings

[sobolevn]

I don't see any reasons why we should use them.
Let's use .format() instead.

P.S. For a reason we can not forbid % usage: gforcada/flake8-pep3101#23

[vergeev]

f strings are shorter, look nicer and allow to remove redundancy:

def str(self):
  return '{name} with {item}'.format(name=self.name, item=self.item)

vs

def str(self):
  return f'{self.name} with {self.item}'

The only reason not to use them all the time is backwards compatibility.

UPD: Although it would be nice to have a way of enforcing The Only Way of formatting strings on a project.

[kxepal]

I guess, @sobolevn really wants just linters for f-strings code and some heuristic to forbid doing complex things inside f-strings.

[vergeev]

we can not forbid % usage

We can actually forbid the usage in the form of string literal % anything else (it's a common one). It's the variable % variable that's impossible to forbid by static analysis.

[sobolevn]

.format() can be short too:

def some(self):
     return '{0} with {1}'.format(name, item)

But, for me being shorter is not a valid argument. What matters is:

1. readability
2. performance
3. consistency

Readability

My old habits put .format() over f, since I am just used to it. This is highly subjective, but that's my point.

But, what really makes a difference is that we can not put logics inside .format(), while we can do bizarre things inside f strings:

>>> f'{random.randint(1, 12)}'
'3'

That is so wrong, that I can not allow this.

Performance

Yes, f is slightly faster than .format(). But it is safe to say that they are almost the same.

Consistency

There should be one-- and preferably only one --obvious way to do it.
(c) Tim Peters

I don't see any use-cases of f strings that can not be covered with .format().
So, let's stick to a single way to format strings.

[vergeev]

I'm starting to agree with you.

Here's another one: if you have a long multiline string that you need to format, you probably better off putting the string in another file and using a template engine. The f-string will make it easier to put the long strings inside code, polluting it.

[malinoff]

No.

[dadwin]

Hey, folks 👋

about Readability

What's the big difference between this two lines?
'v={v}'.format(v=random.randint(1, 12)) f'{random.randint(1, 12)}'
from the perspective of putting logic inside these seems quite the same, no?

[sobolevn]

No,

the template part is pure: v={v}, so you can write this code like this:

template = 'v={v}'
string = template.format(v=...)

[dadwin]

well, i can, but not forced to.
am i right the key point here: template and formatting can be separated for 'format', bot not for 'f-string'?

[sobolevn]

Yes 👍

[thatbirdguythatuknownot]

Consistency

There should be one-- and preferably only one --obvious way to do it.
(c) Tim Peters

Even though this is closed, I want to reply to this:
There are many things in Python that has more than one obvious way to do. You're telling me that you're picking on this one feature that was recently added?

[sobolevn]

You're telling me that you're picking on this one feature that was recently added?

No, we also try to forbid all other things 🙂
Check the amount of our consistency rules.

[thatbirdguythatuknownot]

You're telling me that you're picking on this one feature that was recently added?

No, we also try to forbid all other things 🙂 Check the amount of our consistency rules.

O.K. then.