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 move to the PyPI versions whilst they still support Python 2.
On 21 January 2017 at 22:51, Tim Graham <timogra...@gmail.com> wrote: > 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't think warnings provide much benefit in identifying them. Even if you > want to check your third-party apps, you can grep your virtual environment > directory. My 2 cents, but I'm an enthusiast and less interested users may > find warnings useful, I suppose. > > > On Saturday, January 21, 2017 at 4:41:59 PM UTC-5, Shai Berger wrote: >> >> 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 will include formally dropping support for Python 2 (if >> not >> > done already) and removing usage of this stuff (a fairly easy >> find/replace, >> > hopefully). >> > >> > Others have advocated to deprecate all these things, but I don't see >> much >> > advantage. If I were maintaining an app, I'd rather be able to use >> import >> > shims without warnings until Python 2 is gone. What's your preference? >> > >> >> I think that in order to help 3rd-party apps manage the move towards >> dropping >> Python 2 support, we should decouple the deprecation of Py2 shims from >> other >> Django deprecations. So, I'm thinking we should have a new warning class, >> something like "Python2DeprecationWarning"; this would be easy enough to >> silence for people who want to keep using them -- we could even provide a >> context-manager based on warnings.catch_warnings() that would >> specifically >> silence this warning, so 3rd-parties could silence it on their own uses >> easily. >> >> That's eating the warnings cake while keeping it whole, as far as I can >> see. >> >> Shai. >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/b941c792-57c7-4913-82f3- > 68a2ce357390%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/b941c792-57c7-4913-82f3-68a2ce357390%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3rhuypW4b57QLdcM3CHfmeWZ%2BrLP%2BeiwPZM0PY6V0esA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
