mirror of
https://github.com/django/django.git
synced 2024-12-23 01:25:58 +00:00
5a6f12182e
In Django < 1.6, override_settings restores the settings module that was
active when the override_settings call was executed, not when it was
run. This can make a difference when override_settings is applied to a
class, since it's executed when the module is imported, not when the
test case is run.
In addition, if the settings module for tests is stored alongside the
tests themselves, importing the settings module can trigger an import
of the tests. Since the settings module isn't fully imported yet,
class-level override_settings statements may store a reference to an
incorrect settings module. Eventually this will result in a crash during
test teardown because the settings module restored by override_settings
won't the one that was active during test setup.
While Django should prevent this situation in the future by failing
loudly in such dubious import sequences, that change won't be backported
to 1.5 and 1.4. However, these versions received the "allowed hosts"
patch and they're prone to "AttributeError: 'Settings' object has no
attribute '_original_allowed_hosts'". To mitigate this regression, this
commits stuffs _original_allowed_hosts on a random module instead of the
settings module.
This problem shouldn't occur in Django 1.6, see #20290, but this patch
will be forward-ported for extra safety.
Also tweaked backup variable names for consistency.
Forward port of
|
||
|---|---|---|
| .tx | ||
| django | ||
| docs | ||
| extras | ||
| scripts | ||
| tests | ||
| .gitattributes | ||
| .gitignore | ||
| .hgignore | ||
| AUTHORS | ||
| CONTRIBUTING.rst | ||
| INSTALL | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| setup.cfg | ||
| setup.py | ||
Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Thanks for checking it out. All documentation is in the "docs" directory and online at http://docs.djangoproject.com/en/dev/. If you're just getting started, here's how we recommend you read the docs: * First, read docs/intro/install.txt for instructions on installing Django. * Next, work through the tutorials in order (docs/intro/tutorial01.txt, docs/intro/tutorial02.txt, etc.). * If you want to set up an actual deployment server, read docs/howto/deployment/index.txt for instructions. * You'll probably want to read through the topical guides (in docs/topics) next; from there you can jump to the HOWTOs (in docs/howto) for specific problems, and check out the reference (docs/ref) for gory details. * See docs/README for instructions on building an HTML version of the docs. Docs are updated rigorously. If you find any problems in the docs, or think they should be clarified in any way, please take 30 seconds to fill out a ticket here: http://code.djangoproject.com/newticket To get more help: * Join the #django channel on irc.freenode.net. Lots of helpful people hang out there. Read the archives at http://django-irc-logs.com/. * Join the django-users mailing list, or read the archives, at http://groups.google.com/group/django-users. To contribute to Django: * Check out http://www.djangoproject.com/community/ for information about getting involved. To run Django's test suite: * Follow the instructions in the "Unit tests" section of docs/internals/contributing/writing-code/unit-tests.txt, published online at https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#running-the-unit-tests