我正在尝试将我的1.9应用程序更新为1.10,并且在运行所有单元测试时出现以下错误：
Traceback (most recent call last): File "/home/…/tests/views/test_configurator.py",line 261,in test_view_configurator_post
args=[self.configurator.id]),File "/home/…/.virtualenvs/intranet/lib/python2.7/site-packages/django/urls/base.py",line 87,in reverse
raise NoReverseMatch("%s is not a registered namespace" % key) NoReverseMatch: 'en-gb' is not a registered namespace
LANGUAGE_CODE = 'en-gb' TIME_ZONE = 'UTC' USE_I18N = True USE_L10N = True USE_TZ = True TIME_ZONE = 'Europe/London'
我错过了什么？
解决方法
我也遇到了这个,我缩小了原因.我认为这是Django的一个回归,但我没有时间写一个完整的错误报告.这就是我所知道的.
Django等到第一次调用django.urls.reverse时将所有命名空间填充到缓存的dict中.
最近这个人口程序发生了一些变化.
他们添加了a populating flag that is set to True when you start populating,并且在通话转换中共享.如果填充过程恰好调用django.urls.reverse,则该标志将阻止无限递归.
填充过程涉及导入URL模式 – 您的应用程序中的urls.py文件.如果导入过程中的任何内容引发异常,例如在我的情况下,在模块顶层的未定义名称,填充算法没有捕获它,只是完全停止,并将填充标志保留为True.这个错误,至少对我而言,传播到了顶层,我在测试运行器输出中看到了它.
对django.urls.reverse的所有后续调用都会为en-us命名空间引发NoReverseMatch错误.在代码之后,这是因为在填充过程开始时,如果填充标志是真实的,那么进程只返回并返回缓存的命名空间dict,它是空的,导致en-us的KeyError,导致NoReverseMatch为en -我们.
您应该查看在第一个NoReverseMatch之前发生的错误,以找到您的罪魁祸首.有关更多信息,我认为this is the commit that introduced the regression.它有一个链接到它修复的Django问题.我认为解决方法是在异常的情况下将填充标志设置为False,但我不确定.