Wemake-python-styleguide: 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: https://github.com/gforcada/flake8-pep3101/issues/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.