Comments (13)
.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:
- readability
- performance
- 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.
Related Issues (20)
- def func(): ... causes false positives for WPS220, E704 and WPS473 HOT 6
- WPS508 on negating chain comparison HOT 4
- `self._tokens[1]`: `IndexError: list index out of range`
- Question about WPS324 — Enforce consistent return statements. HOT 2
- How to set up WPS (wemake-python-styleguide) autocheck in PyCharm HOT 1
- Drop `astor` in favour of `ast.unparse`
- Remove usage of deprecated nodes: `ast.Num`, `ast.Str`, `ast.Bytes`, etc
- Better detect literal nodes with `wps_op_eval`
- Do we still need `fix_line_number`?
- Too many exceptions in one `except`
- WPS221 wrong case
- WPS331 should recommend the opposite HOT 2
- Drop the abandoned `flake8-commas` plugin from deps HOT 2
- WPS602 features a dead link
- WPS474 False Positive
- Docstring errors reported on the line after the comment in certain cases
- Flakehean not maintained HOT 1
- Compare with ruff in README.md
- `WPS347` and `N811` rules conflict HOT 1
- IndexError on first run HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wemake-python-styleguide.