web-dev-qa-db-ja.com

Pythonでメソッドをチェーンするときの改行のスタイルを修正

このようなコードがいくつかあります。休憩は期間の前または後に発生する必要がありますか？

# before
my_var = somethinglikethis.where(we=do_things).where(we=domore).where(we=everdomore)

# this way
my_var = somethinglikethis.where(we=do_things) \
                          .where(we=domore) \
                          .where(we=everdomore)

# or this way
my_var = somethinglikethis.where(we=do_things). \
                           where(we=domore). \
                           where(we=everdomore)
pythoncoding-styleline-breakspep8
42
JiminyCricket

PEP 8では、\が不要になるように括弧を使用することをお勧めします。また、後ではなくbefore二項演算子を分割することをお勧めします。したがって、コードをフォーマットする好ましい方法は次のとおりです。

my_var = (somethinglikethis
          .where(we=do_things)
          .where(we=domore)
          .where(we=everdomore))

関連する2つのパッセージは、 Maximum Line Length セクションからの次のパッセージです。

長い行を折り返す好ましい方法は、括弧、括弧、および中括弧内でPythonの暗黙の行継続を使用することです。式を括弧で囲むことにより、長い行を複数の行に分割できます。これらは、行の継続にバックスラッシュを使用するよりも優先して使用する必要があります。

...および バイナリ演算子の前後で改行する必要がありますか？ セクション：

二項演算子の前後で改行する必要がありますか？

何十年もの間、推奨されるスタイルは二項演算子の後にブレークすることでした。しかし、これは2つの方法で読みやすさを損なう可能性があります。演算子は画面上の異なる列に散らばる傾向があり、各演算子はオペランドから離れて前の行に移動します。ここでは、どのアイテムが追加され、どのアイテムが減算されるかを判断するために、特別な作業を行う必要があります。

# No: operators sit far away from their operands
income = (gross_wages +
          taxable_interest +
          (dividends - qualified_dividends) -
          ira_deduction -
          student_loan_interest)

この読みやすさの問題を解決するために、数学者と出版社は反対の慣習に従います。 Donald Knuthは、彼のComputers and Typesettingシリーズで伝統的なルールを説明しています。「段落内の数式は常にバイナリ演算と関係の後に壊れますが、表示される数式は常に二項演算」

数学の伝統に従うと、通常、コードが読みやすくなります。

# Yes: easy to match operators with operands
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)

Pythonコードでは、規則がローカルで一貫している限り、バイナリ演算子の前後でブレークすることができます。新しいコードの場合は、Knuthのスタイルが推奨されます。

上記の引用で示されているように、PEP 8usedが演算子を迂回する場所について反対のアドバイスを与えることに注意してください。

長い行を折り返す好ましい方法は、括弧、括弧、および中括弧内でPythonの暗黙の行継続を使用することです。式を括弧で囲むことにより、長い行を複数の行に分割できます。これらは、行の継続にバックスラッシュを使用するよりも優先して使用する必要があります。継続行を適切にインデントしてください。二項演算子を回避する好ましい場所は、演算子の前ではなく、afterです。いくつかの例：

class Rectangle(Blob):

    def __init__(self, width, height,
                 color='black', emphasis=None, highlight=0):
        if (width == 0 and height == 0 and
            color == 'red' and emphasis == 'strong' or
            highlight > 100):
            raise ValueError("sorry, you lose")
        if width == 0 and height == 0 and (color == 'red' or
                                           emphasis is None):
            raise ValueError("I don't think so -- values are %s, %s" %
                             (width, height))
        Blob.__init__(self, width, height,
                      color, emphasis, highlight)
63
Bastien Léonard

PEP 8は、オペレーターの前にブレークすることが望ましいと述べています。

ドナルド・クヌースは、彼のコンピューターと組版シリーズの伝統的なルールについて説明しています。「段落内の数式は常にバイナリ演算とリレーション後に壊れますが、表示された数式は常にバイナリ演算前に壊れます」.

...

Pythonコードでは、規則がローカルで一貫している限り、バイナリ演算子の前後でブレークすることができます。新しいコードの場合は、Knuthのスタイルが推奨されます。

https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator

4
Neapolitan

FWIW、 autopep8 （--aggressiveフラグ）元のコードからこれを生成しました：

my_var = somethinglikethis.where(
    we=do_things).where(
    we=domore).where(
    we=everdomore)

しかし、私は同意します-Bastienのソリューションはよりエレガントです。

2
Amanda

動作することを行います。

また、Pythonのインデントの神話に関するこのホワイトペーパーをチェックしてください。それは見つけることができますここ。

以下で始まります：

「Pythonソースコードで空白は重要です。」

いいえ、一般的ではありません。ステートメントのインデントレベルのみが重要です（つまり、ステートメントの左端の空白）。他のすべての場所で、空白は重要ではなく、他の言語と同じように好きなように使用できます。また、何も含まない空の行（または任意の空白のみ）をどこにでも挿入できます。

それがお役に立てば幸いです。

1
Mr_Spock