Previous algo only worked if the first item was a part of the loop,
and you would get an infinite loop otherwise (see test).
To fix this, it was much easier to do a pre-pass.
A bonus is that you now get an error message that actually helps you debug
the dependency problem.
When the test client detects a redirect to a URL seen in the
currently followed chain it will now raise a RedirectCycleError
instead of just returning the first repeated response.
It will also complain when a single chain of redirects is longer
than 20, as this often means a redirect loop with varying URLs,
and even if it's not actually one, such long chains are likely
to be treated as loops by browsers.
Thanks Preston Timmons, Berker Peksag, and Tim Graham for reviews.
These assertions had been removed in 34ba86706f and 7fe554b2a3,
seemingly because they were referencing the wrong objects, and so
they started failing when the checking of object types (as well as
PK values) was introduced.
This is useful for debugging side effects affecting tests that
are usually executed before a given test. Full suite and pair
tests sort cases more or less deterministically, thus some test
cross-dependencies are easier to reveal by reversing the order.
Thanks Preston Timmons for the review.
The Jython bug was fixed in http://bugs.jython.org/issue1518
(tested on Jython 2.7b3); also updated make_msgid() to be more like
the version in Python 3.2+; refs #23905.
Thanks Simon Charette for testing and review.
- commit/rollback are no longer replaced by nop
- the warning about not using TestCase when testing transactional
behavior belongs to TestCase section, not TransactionTestCase
This rename is very tricky for the case of subclasses which define
get_query_set and haven't been updated yet, which applies to all projects in
the form of RelatedManager from Django 1.5.
Since RequestContext doesn't know its Engine until it's passed to
Template.render() -- and cannot without breaking a widely used public
API -- an elaborate hack is required to apply context processors.
Passed the engine instance to loaders. This is a prerequisite for
looking up configuration on the engine instance instead of global
settings.
This is backwards incompatible for custom template loaders that override
__init__. However the documentation doesn't talk about __init__ and the
way to pass arguments to custom template loaders isn't specified. I'm
considering it a private API.
This reverts commit f36151ed16.
Adding kwargs to deconstructed objects does not achieve useful
forward-compatibility in general, since additional arguments are silently
dropped rather than having their intended effect. In fact, it can make the
failure more difficult to diagnose. Thanks Shai Berger for discussion.
I don't agree with flake8 here about the right indentation, but as long as
we're using it, we should stick to it. I don't want to disable its hanging
indent checks just because of this case.
This change preserves backwards-compatibility for a very common misuse
of render_to_response which even occurred in the official documentation.
It fixes that misuse wherever it happened in the code base and docs.
Context.__init__ is documented as accepting a dict and nothing else.
Since Context is dict-like, Context(Context({})) could work to some
extent. However, things get complicated with RequestContext and that
gets in the way of refactoring the template engine. This is the real
rationale for this change.
