Django-guardian: ANONYMOUS_USER_NAME Nenhum valor

Sim, você está certo, isso parece duvidoso. Precisa de uma maneira de ser capaz de usar como padrão 'AnonymousUser' sem evitar que seja explicitamente definido como Nenhum.

E se eu alterar o código para o seguinte? Melhor? Isso deve definir o valor padrão se nada for especificado e permitir explicitamente defini-lo como Nenhum.

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"

Eu diria apenas remover as duas linhas que comentei.

Como ANONYMOUS_USER_NAME é na verdade o valor de USERNAME_FIELD , ANONYMOUS_USER_NAME pode ser um e-mail ou qualquer outra coisa. Padronizar para "AnonymousUser" é, portanto, enganoso. Além disso, ANONYMOUS_USER_ID estava ativando o recurso e ANONYMOUS_DEFAULT_USERNAME_VALUE servia como nome de usuário. Mas agora, eles foram fundidos em uma configuração, que serve como gatilho e valor. Portanto, não há nenhum ponto em fornecer um valor padrão.

Então, eu iria me limitar a:

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)

e remova as duas linhas acima mencionadas.

Tenho dúvidas sobre a sintaxe try...except porque, embora a verdade não seja uma questão de número, nunca a vi usada para configurações. O clássico <SETTING_NAME> = getattr(settings, "<SETTING_NAME>", <default_value>) geralmente funciona muito bem.

Se não fornecermos um valor padrão para ANONYMOUS_USER_NAME, isso interromperá os aplicativos existentes que presumem que um valor padrão será fornecido. ou seja, mudamos o comportamento para quando a configuração ANONYMOUS_USER_NAME não é fornecida.

Então, por que não ir para 1.5.0, removendo ANONYMOUS_DEFAULT_USERNAME_VALUE e o valor padrão, e avisando sobre alterações importantes?

Acredito que a intenção era permitir a execução do Django Guardian sem criar automaticamente um usuário anônimo. Você tem um caso de uso para isso? Por que não simplesmente ignorar o usuário anônimo se você não quiser?

Acho que criar um usuário anônimo por padrão é uma coisa boa, não vejo nenhuma razão para mudar isso. No entanto, precisamos de um valor padrão de ANONYMOUS_USER_NAME para que isso funcione. Se o padrão for inadequado para o seu aplicativo, você pode alterá-lo a qualquer momento.

A sintaxe try ... except é boa porque permite distinguir os casos de "Esta configuração não foi fornecida?" e "Esta configuração recebeu um valor nulo?" - Você pode usar getattr para isso, mas descobri que isso pode se complicar rapidamente, principalmente se você quiser manter o Aviso de depreciação. Não tenho certeza do que você quer dizer com "embora a verdade não seja uma questão de número".

O que eu quis dizer é que não é porque todo mundo faz uma coisa que é a maneira certa / melhor.

Forçar a criação de um usuário anônimo pode ser um caminho a percorrer, mas a documentação deve ser atualizada.

Em relação à minha situação, estou usando um campo de e-mail como o USERNAME_FIELD padrão, por isso minha relutância inicial em criar a instância de usuário anônimo. Mas eu consigo.

Saúde. E obrigado por me deixar quebrar sua b * lls.

Pessoal, eu realmente não acho que exigir a criação de um usuário anônimo seja uma boa ideia. Eu uso django-guardian há muito tempo e nunca foi necessário ter um usuário anônimo, então por que mudar isso agora?

Portanto, minha solução envolvendo try ... except recebeu 2 polegares para cima, no entanto, onde eu justifico essa solução, recebi 2 polegares para baixo. Confuso. Como realmente não vejo nenhuma desvantagem e acredito que esta seja a maneira mais simples de resolver a regressão sem adicionar novas regressões, vou aplicar esta solução.

@brianmay Desculpe pela confusão. : +1: para a correção, no entanto!