Removing and renaming Django's Python 2 related helpers

2017-01-21 Thread Tim Graham
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

2017-01-21 Thread Shai Berger
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

2017-01-21 Thread Tim Graham
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

2017-01-21 Thread Tim Graham


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.