#23821 closed Cleanup/optimization (duplicate)
Remove bundled six
Reported by: | Markus Holtermann | Owned by: | Markus Holtermann |
---|---|---|---|
Component: | Utilities | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Django historically ships with a bundled version of six in django.utils.six
. Now that ensurepip landed in the Python 2.x branch (http://legacy.python.org/dev/peps/pep-0477/) we can safely use dependencies to other Python projects and should move Django's custom methods to something like django.utils.compat
.
Change History (8)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
I have been looking into whether or not we can get some of our customization's (the assertions) merged into six. We could then probably move the memoryview
stuff elsewhere so we are at least not making customizations. We should talk at the sprints tomorrow. I think we could probably start the deprecation of utils.six
in 1.8, but seconds opinion welcome as I don't fully understand the issues that have historically prevented us from being able to use dependencies.
comment:3 by , 10 years ago
I don't think we should remove django.utils.six until we should drop support for Python 2. The maintenance workload is very low.
We're OK with requiring dependencies for some features, however, I don't think we're OK with requiring dependencies for simply starting a hello-world django project.
comment:4 by , 10 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
+1 to what Aymeric said, I don't see the gain to do that move for a library that is going to die sooner or later.
comment:5 by , 7 years ago
Cc: | added |
---|---|
Resolution: | wontfix |
Status: | closed → new |
Summary: | Remove bundled six and replace it with a upstream dependency → Remove bundled six |
Triage Stage: | Accepted → Unreviewed |
while support for Python 2 was removed, this module is still hanging around in the code and could be removed, couldn't it?
comment:6 by , 7 years ago
It needs to stay until all supported versions of Django only run on Python 3.x.
Until then, we want third-party apps to be able to import django.utils.six
on all supported Django versions.
comment:7 by , 7 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
... which is tracked in #27753.
comment:8 by , 7 years ago
Cc: | removed |
---|
oh sorry, i was looking for 'six' in the summary field, so that didn't turn up.
It's good to see progress on that side, but let's not forget that from a commit in the 2.x branch until it lands on user machines, time may pass. I'm not sure stable distros do patch all these sort of commits. I wouldn't make the move for the Django 1.8 release.