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.
This avoids calling date.tzinfo.utcoffset(date) twice. It's also
robust to cases where that function returns None -- which never
happens in practice :-)