Forbid using `f` strings about wemake-python-styleguide HOT 13 CLOSED

.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.

from wemake-python-styleguide.

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

from wemake-python-styleguide.

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.

from wemake-python-styleguide.

Yes 👍

from wemake-python-styleguide.

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.

from wemake-python-styleguide.

No.

from wemake-python-styleguide.

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.

from wemake-python-styleguide.

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?

from wemake-python-styleguide.

No,

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

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

from wemake-python-styleguide.

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'?

from wemake-python-styleguide.

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?

from wemake-python-styleguide.

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.

from wemake-python-styleguide.

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.

from wemake-python-styleguide.