Question

我正在尝试将我的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

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

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

我错过了什么？

Answer 1

我也遇到过这种情况，我缩小了原因。我认为它是Django的回归，但我没有时间写一个完整的错误报告。这就是我所知道的。

Django等到第一次调用django.urls.reverse时，将所有名称空间填充到缓存的dict。

最近对人口程序进行了一些改动。他们添加了a populating flag that is set to True when you start populating，并在对reverse的调用中共享。如果填充过程恰好调用django.urls.reverse，则该标志将阻止无限递归。

人口流程涉及导入网址格式 - 您应用中的urls.py个文件。如果导入过程中的任何内容引发异常，例如在我的情况下，在模块顶层的未定义名称，填充算法没有捕获它，只是完全停止，将填充标志保留为True 。那个错误，至少对我而言，传播到顶层，我在测试运行器输出中看到了它。

对django.urls.reverse的所有后续调用都会导致NoReverseMatch命名空间出现en-us错误。在代码之后，这是因为在填充过程开始时，如果populating标志是真的，那么进程只返回并返回缓存的命名空间dict，它是空的，导致en-us的KeyError ，导致NoReverseMatch的{{1}}。

您应该查看在第一个en-us之前发现的错误，以找到您的罪魁祸首。有关详细信息，我认为this is the commit that introduced the regression。它有一个链接到它修复的Django问题。我认为解决方法是在发生异常时将NoReverseMatch标志设置为False，但我不确定。

Answer 2

我更新到django 1.10.5并且问题消失了。

去图！

Answer 3

运行django system check command它可能会显示潜在问题：

python manage.py check

Answer 4

可能是您的基地urls.py有一个包含urls.py的错误信息。这将导致urlresolvers出现问题。扫描您包含的网址，并确保其中没有美元符号。

另一件需要注意的事情是，如果您有任何视图会在您的任何网址中引发异常。

Answer 5

根据 Tommi Kaikkonen 的回答，urls.py 评估失败的一个原因可能是由于服务器/数据库负载过重导致大量查询集以不可重现的方式在生产中失败。

找到根本原因的最简单方法是在 core queryset evaluation 函数上设置断点并在调试模式下执行 django runserver，在它触发的任何地方，您应该重新编写代码以使其成为如果可能，也可以懒惰地评估和优化查询集。

Answer 6

您的LANGUAGE_CODE设置已设为en_gb。注意下划线字符。它应该是en-gb。

Django 1.9到1.10引发了NoReverseMatch：u＆＃39; en-gb＆＃39;不是注册的命名空间

6 个答案: