Django-guardian: ANONYMOUS_USER_NAME Ningún valor

Sí, tienes razón, eso parece poco fiable. Necesita una forma de poder establecer de forma predeterminada 'AnonymousUser' sin evitar que se establezca explícitamente en Ninguno.

¿Qué pasa si cambio el código a lo siguiente? ¿Mejor? Esto debería establecer el valor predeterminado si no se especifica nada y permitir establecerlo explícitamente en Ninguno.

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"

Yo diría que elimine las dos líneas que comenté.

Dado que ANONYMOUS_USER_NAME es en realidad el valor de USERNAME_FIELD , ANONYMOUS_USER_NAME podría ser un correo electrónico o cualquier otra cosa. Por lo tanto, el valor predeterminado de "AnonymousUser" es engañoso. Además, ANONYMOUS_USER_ID estaba activando la función y ANONYMOUS_DEFAULT_USERNAME_VALUE sirvió como nombre de usuario. Pero ahora, se han fusionado en un solo escenario, que sirve como disparador y valor. Por tanto, no tiene sentido proporcionar un valor predeterminado.

Así que me quedaría con:

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)

y elimine las dos líneas mencionadas anteriormente.

Tengo sentimientos encontrados sobre la sintaxis try...except porque, aunque la verdad no es una cuestión de números, nunca la he visto usada para configuraciones. El clásico <SETTING_NAME> = getattr(settings, "<SETTING_NAME>", <default_value>) suele funcionar bastante bien.

Si no proporcionamos un valor predeterminado para ANONYMOUS_USER_NAME, esto romperá las aplicaciones existentes que asumen que se proporcionará un valor predeterminado. es decir, hemos cambiado el comportamiento para cuando no se proporciona la configuración ANONYMOUS_USER_NAME.

Entonces, ¿por qué no pasar a 1.5.0, eliminar ANONYMOUS_DEFAULT_USERNAME_VALUE y el valor predeterminado, y advertir sobre cambios importantes?

Creo que la intención era permitir la ejecución de Django Guardian sin que creara automáticamente un usuario anónimo. ¿Tiene un caso de uso para esto? ¿Por qué no ignorar al usuario anónimo si no lo desea?

Creo que crear un usuario anónimo de forma predeterminada es algo bueno, no veo ninguna razón por la que debamos cambiar esto. Sin embargo, necesitamos un valor predeterminado de ANONYMOUS_USER_NAME para que esto funcione. Si el valor predeterminado no es apropiado para su aplicación, siempre puede cambiarlo.

La sintaxis try ... except es buena porque permite distinguir los casos de "¿No se proporcionó esta configuración?" y "¿Se le dio a esta configuración un valor nulo?" - Es posible que pueda usar getattr para esto, sin embargo, he encontrado que esto puede complicarse bastante rápido, especialmente si desea mantener DeprecationWarning. No estoy seguro de lo que quiere decir con "aunque la verdad no es una cuestión de números".

Lo que quise decir es que no es porque todos hacen una cosa que es la mejor o la mejor manera.

Forzar la creación de un usuario anónimo podría ser un camino a seguir, pero luego los documentos deberían actualizarse.

Con respecto a mi situación, estoy usando un campo de correo electrónico como el USERNAME_FIELD predeterminado, de ahí mi desgana inicial para crear la instancia de usuario anónimo. Pero puedo arreglármelas.

Salud. Y gracias por dejarme reventar tus bolas.

Chicos, realmente no creo que requerir la creación de un usuario anónimo sea una buena idea. He estado usando django-guardian durante mucho tiempo y nunca fue necesario tener un usuario anónimo, así que ¿por qué cambiar eso ahora?

Entonces, mi solución que involucra try ... except recibió 2 pulgares hacia arriba, sin embargo, donde justifico esta solución, me dieron 2 pulgares hacia abajo. Confuso. Como realmente no veo ningún inconveniente, y creo que esta es la forma más sencilla de resolver la regresión sin agregar nuevas regresiones, voy a aplicar esta solución.

@brianmay Perdón por la confusión. : +1: ¡para la solución, sin embargo!