Hi All,
django.utils.six _is_ documented, so I think it should go through the
normal deprecation timeline.
https://docs.djangoproject.com/en/1.11/topics/python3/#writing-compatible-code-with-six
Seems fine to me to start the deprecation in 2.0, but I'm sure people would
appreciate starting the t
A difference is that a deprecation starting in 2.2 is in 2 releases (2.2,
2.3) while the deprecation starting in 3.0 is in 3 releases (3.0, 3.1, 3.2).
On Wednesday, January 25, 2017 at 10:30:40 AM UTC-5, Aymeric Augustin wrote:
>
> Hello Tim,
>
> On 25 Jan 2017, at 16:11, Tim Graham >
> wrote:
>
Hello Tim,
On 25 Jan 2017, at 16:11, Tim Graham wrote:
> - in Django 2.2 for removal in Django 3.1 (August 2020)
> - in Django 3.0 for removal in Django 4.0 (Dec. 2021)
Either option seems fine to me.
Are there advantages to starting the deprecation in a LTS (2.2) vs. in the
release that fol
If we go the deprecation route, when do you want to start those
deprecations? If deprecation start in Django 2.0, the removal happens in
Django 3.0 (December 2019). Do you think third-party apps will drop support
for Python 2 by then?
For removal at a later date, the deprecations could start:
-
Hi,
An alternative option with 'six' is to replace it with an alias of six
propper (not vendored), something like this:
# django/utils/six.py
try:
from six import *
except ImportError:
raise ImportError((
"`django.utils.six` is deprecated, install six from pypi "
Hello,
Django is earning a lot of goodwill from its well-defined deprecation policy.
It was recently improved to allow pluggable apps to work without import shims
and without deprecation warnings from one LTS to the next. I don’t know the
exact details but I believe that's the intent.
Combined
I don't think a deprecation warning is necessary for removing the vendored
libraries. The main things that are used are django.utils.six and
django.utils.lru_cache which are both easily available separately on PyPI
for Python 2/3 compatibility anyway. The warning would probably just make
libraries
Considering the things mentioned so far are zero maintenance effort for
Django (the only downside I see is 30kB for the bundled six), I'd rather
keep the shims until 2025 rather than spend any time on a more complex
solution. These removals are all very straight forward find/replaces, so I
don'
On Saturday 21 January 2017 22:55:51 Tim Graham wrote:
>
> I'm advocating to remove the undocumented things in Django 3.0 (released
> Dec. 2019) or later without a deprecation. By that time, I hope third-party
> apps won't support Python 2 either and so part of adding Django 3.0
> compatibility wi
As we worked on removing Python 2 compatibility code from master this week
[0], we collected a number of import shims and functions that are only
needed for code that wants to support Python 2 [1].
So far there is django.utils.six, as well as some undocumented things:
- django.utils.lru_cach
10 matches
Mail list logo
