5

Djangoなどのフレームワークでは、ユーザーがページにアクセスし（ "some_page"というビュー関数を実行している）、モジュールの上部にそのビューに関係のない8つのインポートがある場合は、次のようになります。それらのインポートでサイクルを浪費します。私の質問は次のとおりです。

  1. トラフィックの多いWebサイトに影響を与えるのに十分な量のリソースですか？
  2. この目的のために関数の内部をインポートすることは、上記の影響で回避する必要があるほど悪い習慣ですか？

注：これは時期尚早の最適化と見なすことができますが、私はその議論には興味がありません。実用的な理論のために、これは大量のトラフィックを伴う完成したサイトであり、可能な限りあらゆる方法で最適化する必要があり、アプリケーションコードとDBは50人のPhDデータベース管理者と開発者によって完全に最適化されていると仮定します。 、そしてこれらのインポートだけが残っています。

4

5 に答える 5

15

いいえ、これをしないでください。Web上の通常のPython実行環境（mod_wsgi、gunicornなど）では、プロセスの開始時にこれらのインポートが実行され、その後のすべてのリクエストでスクリプトが再実行されることはありません。インポートを関数内に配置すると、関数が呼び出されるたびにインポートを処理する必要があります。

于 2010-11-02T18:18:56.403 に答える
5

はい、関数レベルでインポートすることは悪い習慣です。モジュールの上部でよりスマートなインポートを使用することにより、1回限りの低コストを作成できます。ただし、関数にインポートを配置すると、その関数が実行されるたびにインポートのコストが発生します。したがって、関数にインポートするのではなく、モジュールの上部にインポートするだけです。

インポートをクリーンアップして改善するためにできることがいくつかあります。

  • ワイルドインポートを使用しないでください。from x import *
  • 可能な場合は、通常のインポートを使用してください。import x
  • コードを個別に呼び出すことができる小さなモジュールに分割して、インポートが少なくなるようにしてください

また、モジュールの上部にインポートを配置することはスタイルの問題です。PEP 8で、モジュールを一番上にインポートする必要があると言われているのには理由があります。そうすれば、はるかに読みやすく、保守しやすくなります。

from x import *最後に、関数レベルでの一部のインポートは、関数レベルで有効なPython 3.xではないため、将来的に互換性の問題を引き起こす可能性があります。

于 2010-11-02T18:20:18.973 に答える
4

1）答えはノーです。Django/PythonはPHPとは異なります。PHPインクルードで発生するように、モジュール全体が各ページビューで再解釈されることはありません。モジュールはメモリ内にあり、各ページビューはビューに対して単純な関数呼び出しを行います。

2）はい、ビューレベルでインポートを行うことは逆最適化になります。

于 2010-11-02T18:18:53.970 に答える
1

  1. いいえ。他の回答と同じ理由です。

  2. はい。他の答えと同じ理由。

ところで、あなたは怠惰にインポートを行うこともできます。たとえば、インポートツールキットは最上位コードでモジュールを「インポート」できますが、属性の1つにアクセスするまで、モジュールは実際にはロードされません。

于 2010-11-28T18:44:20.537 に答える
0

ボイラープレートに従うことが理にかなっている場合があります。

foo = None

def foorify():
    global foo
    if not foo: from xxx import foo

    foo.bar()

これは、foorificationがめったに変更されないものを条件としている場合、たとえば、あるサーバーがfoorifyし、別のサーバーが決して変更しない場合、またはアプリケーションの起動時やほとんどのテスト中にfooを安全にインポートしたくない、またはインポートできない場合に意味があります。

于 2012-09-30T14:11:33.023 に答える