python – Django 1.9到1.10引发NoReverseMatch：u’en-gb’不是注册的命名空间 -清零世界

概述

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

我的setting.py文件包含以下内容：

LANGUAGE_CODE = 'en-gb'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True
TIME_ZONE = 'Europe/London'

我错过了什么？

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,但我不确定.

总结

以上是编程之家为你收集整理的python – Django 1.9到1.10引发NoReverseMatch：u’en-gb’不是注册的命名空间全部内容，希望文章能够帮你解决python – Django 1.9到1.10引发NoReverseMatch：u’en-gb’不是注册的命名空间所遇到的程序开发问题。

如果您也喜欢它,动动您的小指点个赞吧

python – Django 1.9到1.10引发NoReverseMatch：u’en-gb’不是注册的命名空间

概述

总结

分类汇总

您的鼓励是对我最大的支持