14

django.conf を見ると、設定が次のように実装されていることに気付きました。

class LazySettings(LazyObject):     
...

設定オブジェクトを遅延させる理由は何ですか?

4

3 に答える 3

17

Django コーディング スタイルのこのセクションを確認してください。その理由はそこに説明されています（以下引用）。

パフォーマンスに加えて、サードパーティ モジュールは、インポート時に設定を変更できます。この構成が最初に行われるように、設定へのアクセスを遅らせる必要があります。

一般に、モジュールは最上位の django.conf.settings に格納されている設定を使用しないでください (つまり、モジュールのインポート時に評価されます)。これについての説明は次のとおりです。

設定の手動構成 (つまり、DJANGO_SETTINGS_MODULE 環境変数に依存しない) は許可されており、次のように可能です。

from django.conf import settings

settings.configure({}, SOME_SETTING='foo')

ただし、settings.configure 行の前に何らかの設定にアクセスすると、これは機能しません。(内部的には、設定がLazyObjectまだ構成されていない場合、設定にアクセスしたときに自動的に構成されます)。

したがって、次のようなコードを含むモジュールがあるとします。

from django.conf import settings
from django.core.urlresolvers import get_callable

default_foo_view = get_callable(settings.FOO_EXAMPLE_VIEW)

...次に、このモジュールをインポートすると、設定オブジェクトが構成されます。つまり、サードパーティが最上位でモジュールをインポートする機能は、設定オブジェクトを手動で構成する機能と互換性がないか、状況によっては非常に困難になります。

上記のコードの代わりに、 、 、 などの怠惰または間接的なレベルを使用する必要がdjango.utils.functional.LazyObjectあり django.utils.functional.lazy()ますlambda。

于 2013-01-09T02:16:07.567 に答える
5

実際の設定ファイルを抽象化し、必要な設定に実際にアクセスするまで軽量化するプロキシ オブジェクトです。属性へのアクセスを開始すると、オンデマンドでロードされます。アイデアは、必要になるまで設定をロードする際のオーバーヘッドを削減することです。

于 2012-06-28T05:36:36.583 に答える
-2

開発者目線で設定を簡素化するのが目的だと思います。したがって、各プロジェクトは、他のすべての Django 設定も定義する必要なく、独自の settings.py ファイルを持つことができます。ラッパーのLazySettings種類は、Django の global_settings.py とローカル設定のすべてを組み合わせたものです。開発者は、どの設定を上書きするか、デフォルトのままにするか、または追加するかを決定できます。

LazySettings本当に怠け者ではないと思うので、クラスはおそらく間違った名前です。from django.conf import settings設定オブジェクト全体がスコープ内にあるようなことをしたら。

于 2012-06-28T07:05:52.273 に答える