Django-guardian: ANONYMOUS_USER_NAME Нет значения

Да, вы правы, это выглядит хитроумно. Нужен способ иметь возможность по умолчанию использовать «AnonymousUser», не предотвращая явное значение «Нет».

Что, если я изменил код на следующий? Лучше? Это должно установить значение по умолчанию, если ничего не указано, и позволить явно установить его на None.

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"

Я бы сказал, просто удалите две строки, которые я прокомментировал.

Поскольку ANONYMOUS_USER_NAME на самом деле является значением USERNAME_FIELD , ANONYMOUS_USER_NAME может быть адресом электронной почты или чем-то еще. Таким образом, использование по умолчанию "AnonymousUser" вводит в заблуждение. Кроме того, ANONYMOUS_USER_ID запускал функцию, а ANONYMOUS_DEFAULT_USERNAME_VALUE служил именем пользователя. Но теперь они были объединены в одну настройку, которая служит триггером и значением. Так что нет смысла указывать значение по умолчанию.

Поэтому я бы придерживался:

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)

и удалите две упомянутые строки.

У меня смешанные чувства по поводу синтаксиса try...except потому что, хотя правда не в количестве, я никогда не видел, чтобы он использовался для настроек. Классический <SETTING_NAME> = getattr(settings, "<SETTING_NAME>", <default_value>) обычно работает неплохо.

Если мы не предоставим значение по умолчанию для ANONYMOUS_USER_NAME, это приведет к поломке существующих приложений, которые предполагают, что будет предоставлено значение по умолчанию. т.е. мы изменили поведение, когда параметр ANONYMOUS_USER_NAME не указан.

Тогда почему бы не перейти на 1.5.0, удалить ANONYMOUS_DEFAULT_USERNAME_VALUE и значение по умолчанию и не предупредить о критических изменениях?

Я считаю, что целью было разрешить запуск Django Guardian без автоматического создания анонимного пользователя. У вас есть вариант использования для этого? Почему бы просто не игнорировать анонимного пользователя, если вы этого не хотите?

Я думаю, что создание анонимного пользователя по умолчанию - это хорошо, я не вижу причин, по которым мы должны это изменить. Однако нам нужно значение по умолчанию ANONYMOUS_USER_NAME чтобы это работало. Если значение по умолчанию не подходит для вашего приложения, вы всегда можете изменить его.

Синтаксис try ... except хорош тем, что он позволяет различать случаи «Этот параметр не задан?» и "Было ли этому параметру присвоено нулевое значение?" - Возможно, вы сможете использовать для этого getattr, однако я обнаружил, что это может довольно быстро усложнить, особенно если вы хотите сохранить DeprecationWarning. Я не совсем понимаю, что вы имеете в виду, говоря «хотя правда не в количестве».

Я имел в виду, что это не потому, что все делают что-то одно, а это правильный / лучший способ.

Можно было бы принудительно создать анонимного пользователя, но тогда необходимо обновить документы.

Что касается моей ситуации, я использую поле электронной почты в качестве поля USERNAME_FIELD по умолчанию, отсюда и мое первоначальное нежелание создавать экземпляр анонимного пользователя. Но я справлюсь.

Ваше здоровье. И спасибо, что позволили мне надрать твои сучки.

Ребята, я не думаю, что создание анонимного пользователя - хорошая идея. Я давно использую django-guardian и анонимный пользователь никогда не требовался, так зачем менять это сейчас?

Таким образом, моему решению с участием try ... except было дано 2 больших пальца вверх, однако, когда я оправдываю это решение, мне дали 2 больших пальца вниз. Сбивает с толку. Поскольку я действительно не вижу обратных сторон и считаю, что это самый простой способ разрешения регрессии без добавления новых регрессий, я собираюсь применить это решение.

@brianmay Извините за путаницу. : +1: хотя бы для исправления!