Django-guardian: ANONYMOUS_USER_NAMEなしの値

はい、あなたは正しいです、それは危険に見えます。 明示的にNoneに設定されることを妨げずに、デフォルトで「AnonymousUser」に設定できる方法が必要です。

コードを次のように変更した場合はどうなりますか？ 何か良いですか？ これにより、何も指定されていない場合はデフォルト値が設定され、明示的に「なし」に設定できるようになります。

try:
    ANONYMOUS_USER_NAME = settings.ANONYMOUS_USER_NAME
except AttributeError:
    try:
        ANONYMOUS_USER_NAME = settings.ANONYMOUS_DEFAULT_USERNAME_VALUE
        warnings.warn("The ANONYMOUS_DEFAULT_USERNAME_VALUE setting has been renamed to ANONYMOUS_USER_NAME.", DeprecationWarning)
    except AttributeError:
        ANONYMOUS_USER_NAME = "AnonymousUser"

コメントした2行を削除してください。

ANONYMOUS_USER_NAMEは実際にはUSERNAME_FIELDの値であるため、 ANONYMOUS_USER_NAMEは電子メールなどである可能性があります。 したがって、デフォルトで"AnonymousUser"と、誤解を招く可能性があります。 さらに、 ANONYMOUS_USER_IDが機能をトリガーし、 ANONYMOUS_DEFAULT_USERNAME_VALUEがユーザー名として機能しました。 しかし今、それらは1つの設定に統合され、トリガーと値として機能します。 したがって、デフォルト値を指定しても意味がありません。

だから私は固執するでしょう：

ANONYMOUS_USER_NAME = getattr(settings, 'ANONYMOUS_USER_NAME', None)

if ANONYMOUS_USER_NAME is None:
    ANONYMOUS_USER_NAME = getattr(settings, 'ANONYMOUS_DEFAULT_USERNAME_VALUE', None)
    if ANONYMOUS_USER_NAME is not None:
        warnings.warn("[...]", DeprecationWarning)

前述の2行を削除します。

try...except構文については、真実は数の問題ではありませんが、設定に使用されるのを見たことがないため、さまざまな感情があります。 古典的な<SETTING_NAME> = getattr(settings, "<SETTING_NAME>", <default_value>)は通常かなりうまく機能します。

ANONYMOUS_USER_NAMEのデフォルト値を指定しないと、デフォルト値が提供されると想定している既存のアプリケーションが破損します。 つまり、ANONYMOUS_USER_NAME設定が指定されていない場合の動作を変更しました。

それなら、1.5.0にぶつかって、 ANONYMOUS_DEFAULT_USERNAME_VALUEとデフォルト値を削除し、変更を壊すことについて警告してみませんか？

匿名ユーザーを自動的に作成せずにDjangoGuardianを実行できるようにすることが意図されていたと思います。 これのユースケースはありますか？ 匿名ユーザーが必要ない場合は、無視しないのはなぜですか？

デフォルトで匿名ユーザーを作成するのは良いことだと思います。これを変更する必要がある理由はわかりません。 ただし、これを機能させるには、デフォルト値のANONYMOUS_USER_NAMEが必要です。 デフォルトがアプリケーションに不適切な場合は、いつでも変更できます。

try ... except構文は、「この設定が指定されていませんか？」の場合を区別できるため、優れています。 および「この設定にはnull値が指定されましたか？」 -これにはgetattrを使用できる可能性がありますが、特にDeprecationWarningを維持したい場合は、これがかなり迅速に複雑になる可能性があることがわかりました。 「真実は数の問題ではないのに」とはどういう意味かわかりません。

私が言いたかったのは、それが正しい/より良い方法であるということを誰もが1つのことをするからではないということでした。

匿名ユーザーの作成を強制することもできますが、ドキュメントを更新する必要があります。

私の状況に関しては、デフォルトのUSERNAME_FIELDとして電子メールフィールドを使用しているため、匿名ユーザーインスタンスを作成することに最初は抵抗があります。 しかし、私は管理することができます。

乾杯。 そして、私にあなたのb * llsをバストさせてくれてありがとう。

皆さん、匿名ユーザーの作成を要求するのは良い考えではないと思います。 私は長い間django-guardianを使用していて、匿名ユーザーを持つ必要はありませんでした。なぜ今それを変更するのですか？

したがって、 try ... exceptを含む私のソリューションには、2つの親指が与えられましたが、このソリューションを正当化する場合、私は2つの親指を下げました。 紛らわしい。 マイナス面は実際には見られず、これが新しい回帰を追加せずに回帰を解決する最も簡単な方法であると信じているので、このソリューションを適用します。

@brianmay混乱してすみません。 ：+1：ただし、修正のために！