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 with a thorough documentation of backwards-incompatible changes, it 
helps many developers put up with changes, even those they don’t understand, 
disagree with, or require significant work to adapt applications.

For this reason, in the context of the transition from Python 2 to Python 3, 
which is very backwards incompatible for people who haven’t been able to 
anticipate it, I’m in favor of a generous application of the deprecation policy.

I’m +1 on deprecating rather than removing utilities that were mentioned in the 
documentation, notably python_2_unicode_compatible, which was a public API 
until it got merged into six and we started using six’ version.

I’m +0 on deprecating rather than removing modules that a developer of a 
pluggable app would reasonably use for Python 2 compatibility, such as 
django.utils.lru_cache or django.utils.six.

I’d just remove less visible functions such as django.utils._os.abspathu, 
provided they clearly fall in the “private API” bucket.

Best regards,

-- 
Aymeric.



> On 21 Jan 2017, at 21:55, Tim Graham <timogra...@gmail.com> wrote:
> 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers 
> <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
>  
> <https://groups.google.com/d/msgid/django-developers/08121d30-345b-4fe3-964e-5f19578b4bc9%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
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/5446F829-EAFA-4125-8D93-730B80A13636%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to