Due to a mixup between text and bytes, iteration over
a File instance was broken under Python 3.

Thanks to trac user pdewacht for the report and patch.

Thanks Igor Mitrenko for the report.

Thanks david-schultz at gmx.net for the suggestion.

Thanks to Objectivesea and Guttorm Flatabø (dittaeva)!

Thanks matklad for the report.

This provides better backwards compatibility for those constructing these
objects manually.

Refs #13721.

Instead of crashing with a CommandError, now a non-writable location
of mo files will only make compilemessages complain and continue.
Thanks Ramiro Morales for the review.

This option is not actually very useful in the general case
because it doesn't override sys.stdin.

It's still marginally useful for testing some features of
the createsuperuser command so it was moved there.
This commit also makes the detection of a TTY in createsuperuser
a bit more robust, after a suggestion of appolo13.

And without causing a circular import. Thanks Akis Kesoglou for
the report.

Previously, doing so resulted in invalid data or crash.

Thanks jtiai for the report and Karol Jochelson,
Jakub Nowak, Loic Bistuer, and Baptiste Mispelon for reviews.

Thanks to trac user galaxy4sale for the original report
and to AeroNotix for the patch.

This makes testing certain features easier.

Thanks to AeroNotix for the original patch.

Fixed #22030 -- Don't assume that all fields have a swappable_setting at...

With this pull request, request #878 should considered closed.

Thanks to nvie for the patch.

That method was introduced in 9db4271b.

Refs #21765.

Thanks to lee for the report.

Refs #21765.

Thanks to kezabelle for the quick report and to onjin
for providing the patch.

Thanks Marc Tamlyn for the suggestion.

Thanks to nedbatchelder for the report.

Commit 79558c78 cleaned up the (undocumented) interface of Resolver404
exception, which breaks compatibility with code messing with .args[0]
directly. Revert the cleanup part and simply leave the fix itself.

Thanks to mondone for fruitful colaboration.

Thanks brycenesbitt for the report.

Thanks to cjerdonek for the suggestion.

When django.core.urlresolvers.resolve was called from a view, failed
and the exception was propagated and rendered by technical_404_response,
the URL mentioned on the page was the current URL instead of the URL
passed to resolve().

Fixed by using the path attribute from the Resolver404 exception instead
of request.path_info. Also cleaned up the exceptions to use standard
named parameters instead of stuffing a dict in args[0]

Thanks tunixman for the report and Baptiste Mispelon and
Shai Berger for reviews.