Python 3.4 support
|Reported by:||Marc Tamlyn||Owned by:||nobody|
|Cc:||Florian Apolloner, berker.peksag@…, django@…||Triage Stage:||Accepted|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Description (last modified by )
Python 3.4 support should be added in master ready for 1.7, and probably also in 1.6.X as Py3.4 will be out before Django 1.7. As Py3.4 comes with bundled pip and venv, and is a prime target for new python developers and those running classes, it is very important for Django to support it.
I've run the test suite (on sqlite) against 1.6.X and master. A test run on 1.6.X can be seen at https://gist.github.com/mjtamlyn/8195542
The current state of things is as follows:
There are a couple of warnings printed at startup time. These relate to API changes in plistlib (which is OSX specific) and codecs (universal newlines reading of files has been deprecated). Our usage of
HTMLParsershould now always specify the value of
convert_charrefsas it's default will change in Py3.5. This is slightly problematic as Py2.7 does not have this kwarg so we can't universally apply it. Perhaps the best option is a six-like wrapper.
django.utils.module_loading. module_has_submodulehas some issues with eggs.
sys.meta_pathis giving us
importlibas a finder.
importlib.find_moduleis deferred to
importlib.find_spec(new in py3.4), which throws an error (
ImportError: spec missing loader).
There is a failing test in the mail library regarding encoding in the mail module. Florian seemed to know about this. There is a significant issue with signal deregistration. I've been able to ascertain that something is up in the
django.dispatch.saferefmodule, but I don't have a sufficient understanding to work out what's wrong. There seems to be no test which tests this code directly and failures are thrown up at random during tests, test teardown and/or test suite teardown. They show up either as
NoneType is not callableor as
catching classes that do not inherit from BaseException is not allowed.
Umode has been deprecated for files. We use it in
sql, both for management commands. It seems unnecessary in
makemessages, in the
sqlwe will have to be more careful as at present we split on
\n, which may need to be
\r\non windows. However, it may well be fine anyway it probably doesn't matter if we have trailing
\rcharacters on the sql statements.
- There are quite a lot of
ResourceWarnings thrown for unclosed files
(and sockets in the mail tests)