Removing and renaming Django's Python 2 related helpers
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_cache - django.utils._os.abspathu, upath, npath - django.utils.decorators.available_attrs - django.utils.encoding.python_2_unicode_compatible 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? A similar concern applies to django.utils.http's urlquote() and urlquote_plus() (documented) and urlunquote() and urlunquote_plus() (undocumented). Claude has a PR that deprecates them [4] which I think is fine considering they are half documented. A related issue is the naming of the force_text() / force_str() and smart_text() / smart_str() functions. Aymeric proposed a PR to change all force_text() usage in Django to force_str() (they function identically on Python 3) [2], however, I feel this might create some confusion. For example, when backporting to 1.11 and earlier, we'll have to change force_str() to force_text() for Python 2 compatibility. Third-party apps might also be confused on which function to use. Claude proposed a similar that changes ugettext() and ungettext() to gettext() / ngettext() [3]. Would it be less confusing to consider these changes when Python 2 is no longer supported by any version of Django? [0] https://code.djangoproject.com/ticket/23919 [1] https://code.djangoproject.com/ticket/27753 [2] https://github.com/django/django/pull/7913 [3] https://github.com/django/django/pull/7916 -- 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/08121d30-345b-4fe3-964e-5f19578b4bc9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Removing and renaming Django's Python 2 related helpers
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.
Re: Removing and renaming Django's Python 2 related helpers
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. For more options, visit https://groups.google.com/d/optout.
Fellow Report - January 21, 2017
Triaged --- https://code.djangoproject.com/ticket/27730 - Document that template tags with "as" variable assignment don't propogate variables across blocks (accepted) https://code.djangoproject.com/ticket/27742 - Unexpected migration on Parent -> child model inheritence (accepted) https://code.djangoproject.com/ticket/27740 - Allow content_type or object_id of GenericForeignKey to be field on related model (wontfix) https://code.djangoproject.com/ticket/27749 - Documention change gunicorn deployment (worksforme) https://code.djangoproject.com/ticket/27746 - Database migration fail when removing a child model containing only foreignkeys in a multi-table inheritance context on MySQL (duplicate) https://code.djangoproject.com/ticket/27748 - Use callables instead of strings as default error handlers (handler404, etc.) (accepted) https://code.djangoproject.com/ticket/27697 - JSONField with blank=True is rendered as non-required field in a ModelForm (accepted) Authored -- https://github.com/django/django/pull/7856 - Fixed #27735 -- Doc'd form widget l10n change (refs #15667). Reviewed/committed -- https://github.com/django/django/pull/7381 - Fixed #25809 -- Added BRINIndex support in django.contrib.postgres. https://github.com/django/django/pull/7589 - Fixed #27666 -- Delayed model rendering in migration operations. https://github.com/django/django/pull/7589 - Fixed #27666 -- Delayed model rendering in migration operations. https://github.com/django/django/pull/7826 - Fixed #27683 -- Allowed transaction isolation level to be chosen on MySQL. I also reviewed or authored the patches on the Python 2 removal ticket: https://code.djangoproject.com/ticket/23919 -- 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/59da365b-e2f0-4f32-81b0-c2b9cf8bb769%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.