python黑色风格差异
我正在使用 black 以格式化我的python代码。我观察到以下行为。我承认这是一个非常具体的情况,但我的紧张感。
假设我有以下代码:
@pytest.mark.parametrize(
"first",
["second"],
)
black
不会更改它。但是,如果我在之后删除尾随逗号[“第二”]
:
@pytest.mark.parametrize(
"first",
["second"]
)
black
可以重新排序:
@pytest.mark.parametrize("first", ["second"])
另一方面,让我们查看以下内容:
@pytest.mark.parametrize(
"This is a very long line. Black will not be able to to a linebreak here.",
["second"],
)
在这种情况下,同样,黑色
不会更改任何内容。到目前为止,一切都很好。现在,我在之后删除尾随逗号[“ second”]
:
@pytest.mark.parametrize(
"This is a very long line and black will not be able to do a line break here.",
["second"]
)
由于行太长,black
不会像以前那样很好地重新排序为一行。但是,black
在[“ second”]
之后添加了一个尾随逗号:
@pytest.mark.parametrize(
"This is a very long line and black will not be able to do a line break here.",
["second"],
)
我不喜欢那样。当我面对我的代码中的此类列表时,我总是倾向于删除尾随逗号以强制执行一行重新排序。但是,在大多数情况下,black
再次添加它...
I am using black to format my python code. I observed the following behavior. I admit that it is a very specific case but it goes on my nerves.
Let's suppose I have the following code:
@pytest.mark.parametrize(
"first",
["second"],
)
black
does not change that. But, if I remove the trailing comma after ["second"]
:
@pytest.mark.parametrize(
"first",
["second"]
)
black
makes a nice reordering:
@pytest.mark.parametrize("first", ["second"])
On the other hand, let us see the following:
@pytest.mark.parametrize(
"This is a very long line. Black will not be able to to a linebreak here.",
["second"],
)
In this case, again, black
does not change anything. So far, so good. Now, I remove the trailing comma after ["second"]
again:
@pytest.mark.parametrize(
"This is a very long line and black will not be able to do a line break here.",
["second"]
)
As the line is too long, black
does not do a nice reordering into one line as before. But instead, black
adds a trailing comma after the ["second"]
:
@pytest.mark.parametrize(
"This is a very long line and black will not be able to do a line break here.",
["second"],
)
I do not like that. When I am confronted with such lists in my code, I always tend to remove the trailing comma to enforce one line reordering. But then, in most of the cases, black
adds it again ...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
从我的理解中可以预期黑色行为,因为目的之一是限制git差异内部的变化数量。
如果行太长,您已经在多行写作中。而且,如果您是在多行写作中,那么它应该以逗号结尾。
这样,如果您在元组,列表中添加元素或方法或功能中的参数,它将不会为添加逗号的线生成差异。
如果您的单行写作不长,那么黑色会考虑是否添加了尾随逗号。如果落后逗号,它将进行多行,如果没有,它将鼓励单线。
The black behavior is expected from my understanding, because one of the purpose is to limit the number of changes inside a git diff.
If the line is too long, you already are in a multiline writing. And if you are in a multiline writing, then it should end with a comma.
That way if you add elements in the tuple, list, … or arguments in method or function, it will not generate a diff for the line where you add the comma.
If a contrario you are in a mono-line writing that is not too long, black will consider if you have added a trailing comma. If trailing comma, it will go to multi-line, if not it will encourage mono-line.