Django-guardian: ANONYMOUS_USER_NAME 값 없음

예, 당신 말이 맞습니다. 명시 적으로 없음으로 설정되는 것을 방지하지 않고 '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"

내가 언급 한 두 줄을 제거한다고 말하고 싶습니다.

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 구문은 "이 설정이 제공되지 않았습니까?"의 대소 문자를 구분할 수 있기 때문에 좋습니다. 및 "이 설정에 null 값이 지정 되었습니까?" -이를 위해 getattr을 사용할 수 있지만, 특히 DeprecationWarning을 유지하려는 경우이 작업이 다소 빠르게 복잡해질 수 있음을 발견했습니다. "진실은 숫자의 문제가 아니지만"가 무슨 뜻인지 잘 모르겠습니다.

내가 의미하는 바는 모든 사람이 옳고 / 더 나은 방법을 한 가지하기 때문이 아니라는 것입니다.

익명 사용자 생성을 강제하는 것이 방법이 될 수 있지만 문서를 업데이트해야합니다.

내 상황과 관련하여 이메일 필드를 기본 USERNAME_FIELD로 사용하고 있으므로 처음에는 익명 사용자 인스턴스를 만드는 것을 꺼립니다. 하지만 관리 할 수 ​​있습니다.

건배. 그리고 당신의 물건을 파산하게 해주셔서 감사합니다.

여러분, 저는 익명의 사용자 생성을 요구하는 것이 좋은 생각이라고 생각하지 않습니다. 오랫동안 django-guardian 를 사용해 왔으며 익명 사용자가 필요하지 않은데 지금 변경해야하는 이유는 무엇입니까?

그래서 try ... except 와 관련된 내 솔루션에는 2 개의 엄지 손가락이 주어졌지만이 솔루션을 정당화하는 곳에서는 2 개의 엄지 손가락을 받았습니다. 혼란 스럽습니다. 저는 실제로 어떤 단점도 보지 않고 이것이 새로운 회귀를 추가하지 않고 회귀를 해결하는 가장 간단한 방법이라고 믿기 때문에이 솔루션을 적용 할 것입니다.

@brianmay 혼란에 대해 죄송합니다. : +1 : 그래도 수정을 위해!