With this change, it's expected to survive anything except errors
that make it impossible to import the settings. It's too complex
to fallback to a sensible behavior with a broken settings module.
Harcoding things about runserver in ManagementUtility.execute is
atrocious but it's the only way out of the chicken'n'egg problem:
the current implementation of the autoreloader primarily watches
imported Python modules -- and then a few other things that were
bolted on top of this design -- but we want it to kick in even if
the project contains import-time errors and django.setup() fails.
At some point we should throw away this code and replace it by an
off-the-shelf autoreloader that watches the working directory and
re-runs `django-admin runserver` whenever something changes.
* When some old files contain errors, the second call to
gen_filenames() should return them.
* When some new files contain errors, the first call to
gen_filenames(only_new=True) should return them.
Refactored tests to use a sample project.
Updated extraction:
* Removed special handling of single percent signs.
* When extracting messages from template text, doubled all percent signs
so they are not interpreted by gettext as string format flags. All
strings extracted by gettext, if containing a percent sign, will now
be labeled "#, python-format".
Updated translation:
* Used "%%" for "%" in template text before calling gettext.
* Updated {% trans %} rendering to restore "%" from "%%".
Commit 15f82c7 ("used pyinotify as change detection system when
available") introduced a regression where editing a file in vim with
default settings (writebackup=auto) no longer causes the dev server
to be restarted. On a write, vim moves the monitored file to a backup
path and then creates a new file in the original. The new file is not
monitored as it has a different inode. Fixed this by also watching for
inotify events IN_DELETE_SELF and IN_MOVE_SELF.
Implemented __str__() to return the string-representation of the
proxied object, not the proxy itself, if the lazy object didn't have
a string-like object in its resultclasses.
This avoids calling date.tzinfo.utcoffset(date) twice. It's also
robust to cases where that function returns None -- which never
happens in practice :-)
This patch does three major things:
* Merges the django.template.debug implementation into django.template.base.
* Simplifies the debug implementation.
The old implementation copied debug information to every token and node.
The django_template_source attribute was set in multiple places, some
quite hacky, like django.template.defaulttags.ForNode.
Debug information is now annotated in two high-level places:
* Template.compile_nodelist for errors during parsing
* Node.render_annotated for errors during rendering
These were chosen because they have access to the template and context
as well as to all exceptions that happen during either the parse or
render phase.
* Moves the contextual line traceback information creation from
django.views.debug into django.template.base.Template. The debug views now
only deal with the presentation of the debug information.
There's no reason to assume that sys.path[0] is an appropriate location
for generating code. Specifically that doesn't work with extend_sys_path
which puts the additional directories at the end of sys.path.
In order to create a new migrations module, instead of using an
arbitrary entry from sys.path, import as much as possible from the path
to the module, then create missing submodules from there.
Without this change, the tests introduced in the following commit fail,
which seems sufficient to prevent regressions for such a refactoring.
The stated reason for its introduction in d18d37ce no longer applies
since Django's code repository was switched from Subversion to git.
Furthermore it never had any effect because shutil.rmtree ignores its
onerror argument when ignore_errors is True.
The reason for its use in template management commands is unclear.
This dramatically improves performance on PyPy. The following benchmark:
python -mtimeit -s "from django.utils.functional import allow_lazy; from django.utils.translation import ugettext_lazy; f = allow_lazy(lambda s: s, str)" "f(ugettext_lazy('abc'))"
goes from 390us per loop to 165us.
The function no longer flushes zfile after each write as doing so can
lead to the gzipped streamed content being larger than the original
content; each flush adds a 5/6 byte type 0 block. Removing this means
buf.read() may return nothing, so only yield if that has some data.
Testing shows without the flush() the buffer is being flushed every 17k
or so and compresses the same as if it had been done as a whole string.
Since this package is going to hold both the implementation of the Django
Template Language and the infrastructure for Multiple Template Engines,
it should be untied from the DTL as much as possible within our
backwards-compatibility policy.
Only public APIs (i.e. APIs mentioned in the documentation) were left.
Refs #7261 -- Made strings escaped by Django usable in third-party libs.
The changes in mark_safe and mark_for_escaping are straightforward. The
more tricky part is to handle correctly objects that implement __html__.
Historically escape() has escaped SafeData. Even if that doesn't seem a
good behavior, changing it would create security concerns. Therefore
support for __html__() was only added to conditional_escape() where this
concern doesn't exist.
Then using conditional_escape() instead of escape() in the Django
template engine makes it understand data escaped by other libraries.
Template filter |escape accounts for __html__() when it's available.
|force_escape forces the use of Django's HTML escaping implementation.
Here's why the change in render_value_in_context() is safe. Before Django
1.7 conditional_escape() was implemented as follows:
if isinstance(text, SafeData):
return text
else:
return escape(text)
render_value_in_context() never called escape() on SafeData. Therefore
replacing escape() with conditional_escape() doesn't change the
autoescaping logic as it was originally intended.
This change should be backported to Django 1.7 because it corrects a
feature added in Django 1.7.
Thanks mitsuhiko for the report.
mark_safe and mark_for_escaping should have been kept similar.
On Python 2 this change has no effect. On Python 3 it fixes the use case
shown in the regression test for mark_for_escaping, which used to raise
a TypeError. The regression test for mark_safe is just for completeness.
Zan Anderle
Alexandre Pocquet
Maxime Lorant
Aymeric Augustin
Claude Paroz
Denis Cornehl
Doug Beck
Rigel Di Scala
Edward Henderson
Vlastimil Zíma
darkryder
Chris Bainbridge
Tim Graham
Marten Kenbeek
Moritz Sichert
Tomasz Kontusz
Matthew Somerville
Raphael Michel
Tomáš Ehrlich
zauddelig
Piotr Jakimiak
Markus Bertheau
Michal Čihař
Josh Smeaton
Curtis Maloney
Bas Peschier
Preston Timmons
Rik
Benjamin Wohlwend
Aymeric Augustin
Lukas Klein
Alex Gaynor
Varun Sharma
Adam Taylor
Gavin Wahl
Collin Anderson
Oscar Ramirez