122

PEP 8=がキーワード引数またはデフォルトのパラメータ値の前後にスペースを入れないことを推奨するのはなぜですか？

=これは、Pythonコードで出現する他のすべての前後にスペースを推奨することと矛盾していますか？

方法：

func(1, 2, very_long_variable_name=another_very_long_variable_name)

より良い：

func(1, 2, very_long_variable_name = another_very_long_variable_name)

PythonのBDFLによるディスカッション/説明へのリンクをいただければ幸いです。

念のために言っておきますが、この質問はデフォルト値よりもkwargsに関するものです。私は、PEP8の言い回しを使用しました。

私は意見を求めていません。私はこの決定の背後にある理由を尋ねています。それは、Cプログラムのステートメントと同じ行で、それを使用する必要があるかどうかではなく、なぜ使用するのかを尋ねるようなものです。{if

4

7 に答える 7

83

キーワード引数が変数代入とは本質的に違うからだと思います。

たとえば、次のようなコードはたくさんあります。

kw1 = some_value
kw2 = some_value
kw3 = some_value
some_func(
    1,
    2,
    kw1=kw1,
    kw2=kw2,
    kw3=kw3)

ご覧のとおり、まったく同じ名前のキーワード引数に変数を割り当てることは完全に理にかなっているため、スペースなしでそれらを表示するための読みやすさが向上します。キーワード引数を使用していて、それ自体に変数を割り当てていないことを認識しやすくなります。

また、パラメータは同じ行に配置される傾向がありますが、割り当ては通常、それぞれが独自の行に配置されるため、スペースの節約が重要な問題になる可能性があります。

于 2012-01-13T15:40:43.483 に答える
25

長所と短所があります。

私はPEP8準拠のコードがどのように読み取られるかを非常に嫌います。very_long_variable_name=another_very_long_variable_name私は、より人間が読める形式になる可能性 のある議論に賛成しませんvery_long_variable_name = another_very_long_variable_name。これは人々が読む方法ではありません。これは、特に構文の強調表示がない場合の追加の認知的負荷です。

ただし、大きなメリットがあります。間隔の規則が守られている場合は、ツールのみを使用してパラメーターを検索する方がはるかに効果的です。

于 2016-05-25T10:12:57.577 に答える
16

デフォルトの引数としてvery_long_variable_nameは使用しません。したがって、これを考慮してください：

func(1, 2, axis='x', angle=90, size=450, name='foo bar')

これ以上：

func(1, 2, axis = 'x', angle = 90, size = 450, name = 'foo bar')

また、変数をデフォルト値として使用することはあまり意味がありません。おそらくいくつかの定数変数（実際には定数ではありません）であり、その場合は、すべて大文字で、説明的でありながら可能な限り短い名前を使用します。したがって、another_very_..はありません。

于 2012-01-13T15:43:17.323 に答える
12

argsのスペースを省略したIMOは、arg/valueペアの視覚的なグループ化をより明確にします。散らかっていないように見えます。

于 2014-03-26T21:00:51.087 に答える
6

私にとって、それはコードをより読みやすくするので、良い慣習です。

変数の割り当てと関数のキーワードの割り当てのスタイルの主な違いは=、前者の場合は1行に1つだけであるのに対し=、後者の場合は1行に複数あることです。

他に考慮事項がない場合は、をお勧めfoo = 42しfoo=42ます。後者は通常の等号のフォーマットではなく、前者は変数と値を空白で視覚的にうまく分離しているためです。

ただし、1行に複数の割り当てがある場合は、前者はいくつかの割り当てを空白で視覚的に分離するのに対し、後者はそうではないため、キーワードと値のペアがどこにあるかを確認するのが少し難しくなるため、を優先f(foo=42, bar=43, baz=44)します。f(foo = 42, bar = 43, baz = 44)

別の言い方をすると、規則の背後には一貫性があります。その一貫性はこれです：「最高レベルの分離」はスペースを介して視覚的に明確になります。より低いレベルの分離はそうではありません（より高いレベルを分離する空白と混同されるため）。変数の割り当ての場合、最高レベルの分離は変数と値の間です。機能キーワードの割り当ての場合、最高レベルの分離は、個々の割り当て自体の間です。

于 2019-07-03T21:48:54.367 に答える
5

これにはいくつかの理由があると思いますが、私は合理化しているだけかもしれません。

  1. スペースを節約し、より多くの関数定義と呼び出しを1行に収めることができ、引数名自体のためにより多くのスペースを節約できます。
  2. 各キーワードと値を結合することにより、コンマの後のスペースで異なる引数をより簡単に区切ることができます。これは、提供した引数の数をすばやく確認できることを意味します。
  3. その場合、構文は、同じ名前を持つ可能性のある変数割り当てとは異なります。
  4. a == bさらに、構文は、呼び出し内で有効な式になることもできる等価性チェックとは（さらに）異なります。
于 2014-06-08T07:17:17.507 に答える
0

=個人的には、プログラミング/マークアップ言語に関係なく、すべての代入演算子の前後の単一のスペースを標準にする必要があると感じています。これは、異なるチャネルのトークンを目で区別するのに役立つためです（つまり、変数/パラメーター名トークンを代入演算子トークンから分離する）。=、値トークン/式の値トークンのシーケンスから）。

3つの異なるチャネルの3つのトークンを1つの「パラメータ名-代入-演算子-値/式-タプル」トークンにまとめることは、読みやすく直感的でもありません。

たとえば、区切られていないトークンについて考えてみましょう。

def my_func(par1: str, par2: str):
    print('%s %s' % (par1, par2))

cond = 'conditional string'
my_func(par1='string with a lot of spaces', par2=cond if not cond == None else 'no string')

確かに、渡される値はpar2、「3項」式として渡されるのではなく、おそらく変数に格納される必要があります。

par2 = cond if not cond == None else 'no string'
my_func(par1='string with a lot of spaces', par2=par2)

...しかし、とにかく三項式を使用することにした場合、代入演算子の前後に区切りスペースを追加すると、辞書オブジェクト（Pythonパラメーターシーケンスは基本的に）のように読みやすくなります。

my_func(par1 = 'string with a lot of spaces', 
        par2 = cond if not cond == None else 'no string')
# OR
par2 = cond if not cond == None else 'no string'
my_func(par1 = 'string with a lot of spaces', par2 = par2)
于 2021-07-08T17:33:19.197 に答える