Didn't touch comments where it wasn't obvious that the code adhered to
the newer standard.
Backport of ac77c55bc5fc54cd763a7ae426784650a8cc97c9 from master
The errors='replace' parameter to force_text altered the URL before checking
it, which wasn't considered sane. Refs 24fc935218 and ada7a4aef.
Backport of 552f03869e from master.
Shallow copying of `django.utils.functional.LazyObject` or its subclasses has
been broken in a couple of different ways in the past, most recently due to
35355a4.
Backport of 13023ba86746980aace2341ba32a9419e7567751 from master
This only happens if USE_TZ = False and pytz is installed (perhaps not
the most logical combination, but who am I to jugde?)
Refs #23714 which essentially fixed the same problem when USE_TZ = True.
Thanks Florian and Carl for insisting until I wrote a complete patch.
Backport of 1014ba026e879e56e0f265a8d9f54e6f39843348 from master
Pickling a `SimpleLazyObject` wrapping a model did not work correctly; in
particular it did not add the `_django_version` attribute added in 42736ac8.
Now it will handle this and other custom `__reduce__` methods correctly.
Backport of 35355a4ffedb2aeed52d5fe3034380ffc6a438db from master
Without an explicit 'level', only messages at WARNING or higher
are handled. This makes the config consistent with the docs
which say, "The django catch-all logger sends all messages at
the INFO level or higher to the console."
The ``item_enclosures`` hook returns a list of ``Enclosure`` objects which is
then used by the feed builder. If the feed is a RSS feed, an exception is
raised as RSS feeds don't allow multiple enclosures per feed item.
The ``item_enclosures`` hook defaults to an empty list or, if the
``item_enclosure_url`` hook is defined, to a list with a single ``Enclosure``
built from the ``item_enclosure_url``, ``item_enclosure_length``, and
``item_enclosure_mime_type`` hooks.
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.
