Pythonでは、assert
はステートメントであり、関数ではありません。これは意図的な決定でしたか? assert
を関数ではなくステートメント(および予約語)にすることには利点がありますか?
thedocs によると、_assert expression1, expression2
_はに展開されます
_if __debug__:
if not expression1: raise AssertionError(expression2)
_
ドキュメントには、「現在のコードジェネレーターは、コンパイル時に最適化が要求されたときに、assertステートメントのコードを出力しない」とも記載されています。詳細がわからないので、これを可能にするためには特別なケースが必要だったようです。ただし、特別な場合を使用して、assert()
関数への呼び出しを最適化することもできます。
assert
が関数の場合、次のように書くことができます。
_assert(some_long_condition,
"explanation")
_
ただし、assert
はステートメントであるため、タプルは常にTrue
と評価され、次のようになります。
_SyntaxWarning: assertion is always true, perhaps remove parentheses?
_
それを書く正しい方法は
_assert some_long_condition, \
"explanation"
_
これは間違いなくあまりきれいではありません。
Assertを関数ではなくステートメント(および予約語)にすることには利点がありますか?
pythonおよび他の言語(具体的にはC)のassert
のすばらしい点の1つは、正しい_#define
_(オプションで)を追加するだけで、それらを削除してコードを最適化できることです。コマンドラインで、これまでに使用したコンパイラ)または最適化フラグ(Pythonでは_-O
_)。 assert
が関数になった場合、組み込みのassert
関数があるかユーザー定義かが実行時までわからないため、この機能をpythonに追加することはできません。同名の機能。
また、Pythonでは、関数呼び出しはかなり高価であることに注意してください。インラインをコード_if __debug__: ...
_に置き換えることは、関数呼び出しを行うよりもおそらくはるかに効率的です。これは、パフォーマンスが重要なルーチンにassert
ステートメントを配置した場合に重要になる可能性があります。
私はPythonの専門家ではありませんが、パフォーマンスが最大の理由の1つだと思います。
関数としてassert(expression、description)がある場合、式の評価にコストがかかる場合、非デバッグモードであっても、Pythonは、両方の式を評価して、assert関数に渡す必要があります。 。
アサーションを展開することにより、式と説明のステートメントは、本当に必要な場合を除いて、実際には評価されません(debugがtrueと評価された場合)。必要のないときにパフォーマンスに影響を与えない(つまり、本番システムでパフォーマンスが低下しない)アサートを行う場合は重要だと思います。
他の回答(および一種のオフトピック)に加えて、ヒント。バックスラッシュの使用を避けるために、括弧内に暗黙の線結合を使用できます。 ;-)
の代わりに:
assert some_long_condition, \
"explanation"
あなたは書くことができます:
assert some_long_condition, (
"explanation")