1

Djangoサイトのスクリプトを実行しようとしてmanage.pyいますが、次のエラーで失敗します。

Traceback (most recent call last):
  File "manage.py", line 2, in <module>
    from django.core.management import execute_manager
  File "/scratch/tools/lib/python2.5/site-packages/django/core/management/__init__.py", line 4, in <module>
    from optparse import OptionParser, NO_DEFAULT
ImportError: cannot import name NO_DEFAULT

これは、Python 2.5.1または2.6.1（Fedoraパッケージ）のどちらを使用しているかに関係なく発生します。インタラクティブなPythonセッションでインポートを実行すると、エラーを再現できます。

これは、にリストされておらず、ドキュメントにもリストされていNO_DEFAULTないことを考えると、それほど驚くことではありませoptparse.pyん。__all__optparse

驚くべきことに、私自身のワークステーションではfrom optparse import NO_DEFAULT、Python 2.5.5と2.6.6（Debianパッケージ）の両方で正常に実行できます。

私の質問は2つあります：

  • に記載されていないものをインポートできるのは__all__どうしてですか？
  • Djangoを修正するにはどうすればよいmanage.pyですか？可能であれば、Python2.5で動作させたいと思います。
4

1 に答える 1

0

Pythonではいつものように、これ__all__はルールというよりもガイドラインです。それは、ドキュメント*-importで次のように説明されている、私たちが嫌いなものであるために発生します

識別子のリストがスター（'*'）に置き換えられた場合、モジュールで定義されたすべてのパブリック名は、 importステートメントのローカル名前空間にバインドされます。

ここにはすぐに技術的な問題があります。通訳者はモジュールのパブリック名をどのように知る必要がありますか？モジュール内のanで始まらない名前はすべて_パブリックであるという規則があります。最初の概算として、モジュールの名前空間にそのような名前をすべてインポートするだけでよいと思うかもしれません。残念ながら、パッケージを導入すると、これはより複雑になります。パブリック名の計算は、さまざまなインポート、パスの書き換え、ファイルの読み取り、および何を行うかを含む大きなタスクになるためです。これは良いことではありません。したがって、モジュールで定義することにより、モジュールの作成者がパッケージ内のどの名前を*-importからインポートするかを正確に指定できるようにするという単純化の決定が行われました__all__。

ただし、*-インポートしない場合（インポートする変数の名前をインタープリターに指定する場合）、すべてのグローバル名を見つけることを心配する必要がないため、無視__all__して検索するだけです。モジュールの名前空間内の名前。

これは、アンダースコアで始まら__all__ないサブセットと同じではない可能性があることを意味しlocals().keys()ます。特に、*-importsによってエクスポートされない完全に優れたオブジェクトがモジュールに存在する可能性があります。これはで起こることNO_DEFAULTです。

于 2011-07-18T12:29:47.567 に答える