python黑色风格差异

发布于 2025-01-23 06:24:56 字数 1499 浏览 2 评论 0原文

我正在使用 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

东北女汉子 2025-01-30 06:24:57

从我的理解中可以预期黑色行为,因为目的之一是限制git差异内部的变化数量。

如果行太长,您已经在多行写作中。而且,如果您是在多行写作中,那么它应该以逗号结尾。

这样,如果您在元组,列表中添加元素或方法或功能中的参数,它将不会为添加逗号的线生成差异。

如果您的单行写作不长,那么黑色会考虑是否添加了尾随逗号。如果落后逗号,它将进行多行,如果没有,它将鼓励单线。

a = [1, 2,]
# goes to
a = [
    1,
    2,
]

# and

a = [1, 2]
# remains:
a = [1, 2]

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.

a = [1, 2,]
# goes to
a = [
    1,
    2,
]

# and

a = [1, 2]
# remains:
a = [1, 2]
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文