Opened 8 years ago
Last modified 3 years ago
#27753 closed Cleanup/optimization
Cleanups when no supported version of Django supports Python 2 anymore — at Version 13
Reported by: | Aymeric Augustin | Owned by: | |
---|---|---|---|
Component: | Utilities | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Jon Dufresne | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Compatibility with Python 2 is currently being removed in master as part of the Django 2.0 development cycle: see #23919.
However third-party apps may want to remain compatible with all supported version of Django and the corresponding versions of Python, which includes Python 2.
To allow this, compatibility functions or modules aren't removed. They're still importable. They're usually just aliases or no-ops. Here's a list of things to deprecate and remove eventually:
- django.utils.six
- django.utils.lru_cache
- django.utils._os.abspathu, upath, npath
- django.utils.decorators.available_attrs
- django.utils.encoding.python_2_unicode_compatible
- django.utils.encoding.smart/force_text
- django.utils.http.urlquote/urlquote_plus/urlunquote/urlunquote_plus (unmerged commit)
- django.utils.safestring.SafeBytes
- One of either django.utils.safestring.SafeString or django.utils.safestring.SafeText
- django.test.utils.str_prefix()
- django.utils.encoding.DjangoUnicodeDecodeError
Change History (13)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Triage Stage: | Unreviewed → Someday/Maybe |
---|
Those methods don't work on Python 3 (AttributeError: 'dict' object has no attribute 'iterkeys'
) so I don't think they have value for the use case described in the ticket description. A third-party app should use six.iterkeys()
as the old test did (which uses keys()
etc. on Python 3), or am I missing something?
comment:3 by , 8 years ago
The question we discussed on IRC and GitHub with Tim is about deprecating or not deprecating those items.
I would be for a standard deprecation process as I don't see how this is different from any other deprecation. But I'm open to read about use cases which would push for a delayed deprecation process for items related to Python 2.
comment:4 by , 8 years ago
Description: | modified (diff) |
---|
comment:5 by , 8 years ago
Description: | modified (diff) |
---|
comment:6 by , 8 years ago
Description: | modified (diff) |
---|
comment:7 by , 8 years ago
Description: | modified (diff) |
---|
comment:8 by , 8 years ago
Description: | modified (diff) |
---|
comment:9 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:10 by , 8 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
Please don't work on this ticket -- the timetable for these removals isn't decided but it's not for some years. The "Someday/Maybe" "Triage Stage" of the ticket indicates that it's not appropriate to work on right now.
comment:11 by , 8 years ago
Description: | modified (diff) |
---|
comment:12 by , 8 years ago
Description: | modified (diff) |
---|
comment:13 by , 8 years ago
Description: | modified (diff) |
---|
Should we revert the removal of eb0b921c29ace8643a5a4cd136c433727c53dead in this case?