Opened 10 years ago
Last modified 2 years ago
#23919 closed Cleanup/optimization
Cleanups for when we drop Python 2 compatibility — at Version 101
Reported by: | Tim Graham | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | |
Severity: | Normal | Keywords: | |
Cc: | cmawebsite@…, Tom Forbes | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
This is a tracking ticket of things that we can remove when we drop Python 2 compatibility in Django 2.0. Please edit the description of the ticket as you come across new items.
#23905django.core.mail.message.make_msgid()
django.dispatch.weakref_backports
(remains for Python 3.4)django.http.cookie
workaroundsdjango.utils.2to3_fixes
django.utils.decorators.ContextDecorator
django.utils.encoding
@python_2_unicode_compatible
force/smart _unicode- either force/smart _text or force/smart _str PR
django.utils.html_parser.use_workaround
django.utils.http
functions likeurlquote_plus
-- I think the versions of these functions on Python 3 don't have the unicode characters bug we are working around PRStop usingdjango.utils.lru_cache
Figure the deprecation plan for(staying for now)django.utils.lru_cache
django.utils.six
from __future__ import unicode_literals
str()
stuff for environment variables, e.g. 0bfb53866199f366ed140d49938fd185e5898156str()
stuff fortype(name)
and__name__
Inheriting fromobject
indjango.core.servers.basehttp
(and perhaps other places) ala 4ee06ec3fc8e94d164afbd2f9c880c60c658a9acgit grep 'long int'
(mostly docs)django.utils._os [npath,upath]
In tests:contextlib.closing(self.urlopen
(contextlib.closing
no longer needed)Support for pysqlite (doesn't support Python 3)ReplacePRsuper(ClassName, self)
withsuper()
Remove(that's the default on Python 3)# -*- coding: utf-8 -*-
source file encoding- Evaluate replacement of custom
__del__
methods by weakref.finalize Remove__ne__
from objects already defining a__eq__
Remove note about PYTHONHASHSEED (see #26243)Remove Field.creation_counter (replace by metaclass(see comment:95)__prepare__
returningOrderedDict()
, https://docs.python.org/3/reference/datamodel.html#preparing-the-class-namespace)django.test.utils.reset_warning_registry()
ReplacePRerrno
checks byIOError
subclasses defined by PEP 3151django.utils.glob
(remains for Python 3.4 compatibility)django.utils.cookies.SimpleCookie
django.test.mock
Replacetempfile.mkdtemp
+ remove withtempfile.TemporaryDirectory
context managerReplaceio.open()
by a plainopen()
Evaluate need forassertRegex
,assertRaisesRegex
in tests. Some usage is merely to account for differences in messages between Python 2 and 3.- PR 7879re.U
,re.UNICODE
(default behavior of Python 3)- remove empty init.py (and init.py-tpl) files?
Change History (101)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Description: | modified (diff) |
---|
comment:3 by , 10 years ago
Description: | modified (diff) |
---|
follow-up: 32 comment:4 by , 10 years ago
I believe we can get rid of the Field.creation_counter hack. In Python 3 it is possible to store the attrs in a sorted dictionary. See http://stackoverflow.com/questions/4459531/how-to-read-class-attributes-in-the-same-order-as-declared.
comment:5 by , 10 years ago
Description: | modified (diff) |
---|
comment:6 by , 10 years ago
Description: | modified (diff) |
---|
comment:7 by , 10 years ago
Description: | modified (diff) |
---|
comment:8 by , 10 years ago
Cc: | added |
---|---|
Description: | modified (diff) |
comment:9 by , 10 years ago
Description: | modified (diff) |
---|
comment:10 by , 10 years ago
In far too many tests we rely on the fact six aliases builtins [like input] instead of using mock.
I submitted a patch recently to clean up a couple of these I found, but I am finding more.
comment:11 by , 10 years ago
Description: | modified (diff) |
---|
comment:12 by , 9 years ago
Description: | modified (diff) |
---|
comment:13 by , 9 years ago
Description: | modified (diff) |
---|
comment:14 by , 9 years ago
Description: | modified (diff) |
---|
comment:15 by , 9 years ago
Description: | modified (diff) |
---|
comment:16 by , 9 years ago
Description: | modified (diff) |
---|
comment:17 by , 9 years ago
Description: | modified (diff) |
---|
comment:18 by , 9 years ago
Description: | modified (diff) |
---|
comment:19 by , 9 years ago
Description: | modified (diff) |
---|
comment:20 by , 9 years ago
Description: | modified (diff) |
---|
comment:21 by , 8 years ago
Description: | modified (diff) |
---|
comment:22 by , 8 years ago
Description: | modified (diff) |
---|
comment:23 by , 8 years ago
Description: | modified (diff) |
---|
comment:24 by , 8 years ago
Description: | modified (diff) |
---|
comment:25 by , 8 years ago
Description: | modified (diff) |
---|
comment:26 by , 8 years ago
Description: | modified (diff) |
---|
comment:27 by , 8 years ago
Description: | modified (diff) |
---|
comment:28 by , 8 years ago
Note that I have a local branch which does some boring removals (unicode_literals, utf-8 preambles, some six usage). So ping me as soon as the Django 2.0 deprecated stuff is removed and I'll offer a patch for that.
comment:29 by , 8 years ago
I am also working to remove python2 workarounds by following a module by module approach.
follow-up: 31 comment:30 by , 8 years ago
If Claude has already prepared these changes, perhaps you should wait for his patch instead of duplicating his work?
comment:31 by , 8 years ago
Replying to Aymeric Augustin:
If Claude has already prepared these changes, perhaps you should wait for his patch instead of duplicating his work?
Yes I talked with Claude on IRC to pause before his work is merged.
comment:32 by , 8 years ago
Replying to Anssi Kääriäinen:
I believe we can get rid of the Field.creation_counter hack. In Python 3 it is possible to store the attrs in a sorted dictionary. See http://stackoverflow.com/questions/4459531/how-to-read-class-attributes-in-the-same-order-as-declared.
We could also remove this when we support python 3.6, as class attributes retain their order. I'm guessing this is a consequence (or the cause of) dictionaries retaining insertion order. https://docs.python.org/3.6/whatsnew/3.6.html#pep-520-preserving-class-attribute-definition-order
comment:35 by , 8 years ago
Triage Stage: | Someday/Maybe → Accepted |
---|
PR for removing Python 2 references from docs.
comment:40 by , 8 years ago
Description: | modified (diff) |
---|
comment:41 by , 8 years ago
Description: | modified (diff) |
---|
comment:42 by , 8 years ago
Description: | modified (diff) |
---|
comment:46 by , 8 years ago
Description: | modified (diff) |
---|
comment:47 by , 8 years ago
Description: | modified (diff) |
---|
comment:49 by , 8 years ago
Description: | modified (diff) |
---|
comment:55 by , 8 years ago
Description: | modified (diff) |
---|
comment:63 by , 8 years ago
Description: | modified (diff) |
---|
comment:64 by , 8 years ago
Description: | modified (diff) |
---|
comment:69 by , 8 years ago
Description: | modified (diff) |
---|
comment:75 by , 8 years ago
Description: | modified (diff) |
---|
comment:77 by , 8 years ago
Description: | modified (diff) |
---|
comment:79 by , 8 years ago
Description: | modified (diff) |
---|
comment:87 by , 8 years ago
Description: | modified (diff) |
---|
comment:91 by , 8 years ago
Description: | modified (diff) |
---|
comment:92 by , 8 years ago
Description: | modified (diff) |
---|
comment:95 by , 8 years ago
I had an attempt at dropping the creation_counter for model fields, but I *think* it might be more costly than the current method, considering so many things rely on the order being consistent. My attempt was here, with associated discussion I'll copy some of below: https://github.com/django/django/pull/7983
I'm not sure this is worth continuing with, at least not in the same way. Too many systems rely on the fields being ordered, which isn't going to be possible without maintaining another list of fields such as definition_order = []. This can be done for local fields, but then proxy/parent fields will need to be returned in the same definition order. This might be something like:
parent_fields + [field for field in self.definition_order if field in local_fields]
Then we'd need to account for private and hidden fields. But what's the point? We'd now be storing a separate list of all field references for each model, rather than a counter (int) on each field, and reordering fields in _get_fields() whether or not they need to be ordered. Of course I'd be happy to see a better solution that worked, I'm just giving up on this particular method for the moment.
comment:96 by , 8 years ago
Description: | modified (diff) |
---|
I also looked briefly at models field and manager usage of creation_counter
but it wasn't obvious if the __prepare__()
approach was feasible or if it would be simpler. I think we can defer that task for now.
comment:101 by , 8 years ago
Description: | modified (diff) |
---|
Can we remove empty init.py (and init.py-tpl) files?
Various
nonlocal
workarounds (example).