#21721: Python 3.4 support
---------------------------------+------------------------------------
     Reporter:  mjtamlyn         |                    Owner:  nobody
         Type:  Bug              |                   Status:  new
    Component:  Python 3         |                  Version:  master
     Severity:  Release blocker  |               Resolution:
     Keywords:                   |             Triage Stage:  Accepted
    Has patch:  0                |      Needs documentation:  0
  Needs tests:  0                |  Patch needs improvement:  0
Easy pickings:  0                |                    UI/UX:  0
---------------------------------+------------------------------------

Old description:

> 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 `HTMLParser` should now always specify the value of
> `convert_charrefs` as 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_submodule` has some issues
> with eggs.  `sys.meta_path` is giving us `importlib` as a finder.
> `importlib.find_module` is 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.saferef`
> module, 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 callable` or as
> `catching classes that do not inherit from BaseException is not
> allowed`.~~
> - `U` mode has been deprecated for files. We use it in `makemessages` and
> in `sql`, both for management commands. It seems unnecessary in
> `makemessages`, in the `sql` we will have to be more careful as at
> present we split on `\n`, which may need to be `\r\n` on windows.
> However, it may well be fine anyway it probably doesn't matter if we have
> trailing `\r` characters on the sql statements.
> - There are quite a lot of `ResourceWarning`s thrown for unclosed files
> ~~(and sockets in the mail tests)~~

New description:

 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 `HTMLParser` should now always specify the value of
 `convert_charrefs` as 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_submodule` has some issues with
 eggs.  `sys.meta_path` is giving us `importlib` as a finder.
 `importlib.find_module` is 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.saferef`
 module, 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 callable` or as
 `catching classes that do not inherit from BaseException is not
 allowed`.~~
 - `U` mode has been deprecated for files. We use it in `makemessages` and
 in `sql`, both for management commands. It seems unnecessary in
 `makemessages`, in the `sql` we will have to be more careful as at present
 we split on `\n`, which may need to be `\r\n` on windows. However, it may
 well be fine anyway it probably doesn't matter if we have trailing `\r`
 characters on the sql statements.
 - There are quite a lot of `ResourceWarning`s thrown for unclosed files
 ~~(and sockets in the mail tests)~~

--

Comment (by mjtamlyn):

 The `pdistlib` error is in fact a lack of dogfood in python itself:
 http://bugs.python.org/issue20229

-- 
Ticket URL: <https://code.djangoproject.com/ticket/21721#comment:18>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.284c473784b66f0ff2a91ce4861f7d13%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to