PEP 8、キーワード引数またはデフォルトのパラメーター値の '='の前後にスペースがないのはなぜですか?


103

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によるディスカッション/説明へのリンクがあれば、高く評価されます。

ちなみに、この質問はデフォルト値よりもクワルグについてです。PEP8の表現を使用しました。

私は意見を求めていません。私はこの決定の背後にある理由を求めています。これは、より尋ねるようなものだ、なぜ私が使用する{と同じ行にif、Cプログラムでは文でないかどうか、私はそれを使用するか、またはべきではありません。

回答:


72

キーワード引数は基本的に変数代入とは異なるためだと思います。

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

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

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

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


6
これは事実かもしれませんが、このような適切に設計された言語のコードスタイルの推奨にこのIMOアイコンを導入するのは奇妙に思え、2文字しか節約できません。それはまるで、Javaコードスタイルが{if(同じ文字数を保存する)後に改行を入れるほうがいいと言っているようですが、クラス定義ではそうではありません。また、キーワードパラメータはデフォルト値とは異なりますが、同じスタイルの推奨を使用しています。
ソウルチェック2012年

3
私が言ったように、それらは異なるものです。それらを別の方法で書くことは理にかなっています。
Fortran

6
私はそれが本当にkw1 = kw1, kw2 = kw2;)より読みやすいとは言いませんが、多分それはGuidoとBarryが考えたものでした。
ソウルチェック

1
それがかなり説得力があるので、私はこのanwerを受け入れます。それを確認するリンクを気にしません
soulcheck

5
キーワードの引数が変数の割り当てとは根本的に異なるという事実は、IMOが異なる規則を持つための有効な引数ではありません。これは、違いがコンテキストからすでに明らかであるためです。前者は関数呼び出し内で発生、後者は現在のインデントレベルで独立する必要があります。IMO、5〜6文字より長い変数名(つまり、ほとんどの場合は実際)の場合、スペースのあるバリアントは、ハンドダウンで読みやすくなります。
アクセル

13

私はデフォルトの引数として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 _...


1
これらはキーワード引数です。同様の例がPEPにありますが、読みにくくしました
soulcheck

3
(本質的に)あなたが言っていること:スペースなしのルールを賢明にするために、非常に短い変数名を書きます。ただし、変数名が長すぎる場合、スペースなしのルールにより、雑然とした環境になります。セマンティクスよりも読みやすさを重視し、それが「割り当てのデフォルト値」ではない場合、それ?
PatrickT 2016年

1
@PatrickT「それは割り当てではないので、それらは異なるものです」という議論は、それがなぜであるかを説明するものではありません(哲学的概念)。それはなぜそれがあり得るのかを説明するだけです(構文的な概念)。
Mateen Ulhaq 2017年

11

長所と短所があります。

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

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


まあ、=の周りにスペースを置くことに固執するなら、ツールを使った検索も同じようにすべきです。
NoName

10

IMOは、引数のスペースを省略して、引数と値のペアを視覚的にグループ化します。雑然としていないように見えます。


私は一般的にスペースが好きなので、括弧内にスペースを入れる傾向があるので、すべてのパラメーターはスペースで囲まれています。しかし、私はarg1=40関係がより明白なので、より読みやすいと思います。
Charlie Gorichanaz

3

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

  1. それはスペースを節約し、より多くの関数定義と呼び出しを1行に収めることを可能にし、引数名自体のためにより多くのスペースを節約します。
  2. 各キーワードと値を結合することにより、カンマの後のスペースによって異なる引数をより簡単に分離できます。つまり、指定した引数の数をすぐに確認できます。
  3. 構文は、同じ名前の変数の割り当てとは異なります。
  4. さらに、構文は(さらに)a == b呼び出し内の有効な式にもなり得る等価チェックとは異なります。

3

私にとっては、コードが読みやすくなるため、適切な規則です。

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

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

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.