是的,您是对的,看上去确实很狡猾。 需要一种能够默认为“ AnonymousUser”而又不会阻止将其显式设置为None的方法。
如果我将代码更改为以下内容怎么办? 好点? 如果未指定任何内容,则应设置默认值,并允许将其显式设置为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:不过,修复!
最有用的评论
如果我将代码更改为以下内容怎么办? 好点? 如果未指定任何内容,则应设置默认值,并允许将其显式设置为None。