Backporting some Python 3 support features to 1.4.x?

[Aymeric Augustin]

Hello,

Several people have started porting their apps for Python 3, but they're running into trouble when they try to support both Django 1.4 and master. They end up with regrettable patterns such as:

try:

    from django.utils.six import PY3

except ImportError:

    PY3 = False

Authors of pluggable apps generally chose to support the current and the previous version of Django. Thus their users can alternatively upgrade Django and their apps, which makes upgrades less scary.

Now we have two alternatives:

1) tell them to roll their own compat or wait until they can target 1.5 + 1.6 — quite a downer,

2) add some forwards compatibility tools to 1.4.

We generally don't add features to minor releases, but there's a precedent (csrf_noop), and the patch is as harmless as they come (see attachment).

What do you think?

--
Aymeric.

[Mark Lavin]

Hi,

I am one such author and I wanted to share my experience. I have ported my code and test suites for 3 applications to run on Django 1.3-1.5dev and Python 2.6, 2.7 and 3.2 (1.5dev only).

Those are https://github.com/mlavin/django-responsive, https://github.com/mlavin/django-ad-code and https://github.com/mlavin/django-scribbler. There are fairly new apps and don't

have many users/active deployments and so made good candidates for this work.

For the most part these were fairly easy to port. Adding unicode_literals everywhere was most of the work. There were a few places where I needed to make use of django.utils.six.

The largest pain point was trying to follow the recommendation for models __str__/__unicode__ in https://docs.djangoproject.com/en/dev/topics/python3/#str-and-unicode-methods

If you are trying to support Django 1.4 then you can't really use this recommendation without backporting the decorator because of the way it was written to be no-op for

Python 3 rather than Python 2. I understand why this decision was made and in the long run it is the right decision. For now I think app maintainers will have a bit of pain without

some of these features being backported to a 1.4.X release. You do have the option of using the hack you referenced (which I am doing) or a similar conditional import 

along with conditional __str__/__unicode__ which this decorator was meant to avoid. It's certainly not hard to do but it feels dirty.

My work now has been focused on getting the tests to pass and now they do. Another piece will be to actually deploy a project using one of these app.

I'll be continuing to do this work while at DjangoCon and I'll happily chime in any other stumbling blocks I run into while I port some other larger applications.

Best,

Mark

[Donald Stufft]

Just as an additional aside, the apps can also depend on the actual six library itself instead of Django's embedded version (It could be an optional dependency on Django < 1.5). The major things I think would be anything Django specific that don't come from six.

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Attachments:

- python3-forwards-compat-for-django-14.diff

[Andrew Godwin]

I'm definitely +1 on this - I have a few codebases I want to start converting but also want to keep running on 1.4, and the patch looks sensible to me. There is precedent for this, and even if there wasn't, this is a nice way to get the migration cycle started.

Andrew

[Luke Plant]

On 06/09/12 19:09, Aymeric Augustin wrote:

> Now we have two alternatives:
> 1) tell them to roll their own compat or wait until they can target 1.5
> + 1.6 — quite a downer,
> 2) add some forwards compatibility tools to 1.4.
>
> We generally don't add features to minor releases, but there's a
> precedent (csrf_noop), and the patch is as harmless as they come (see
> attachment).
>
> What do you think?

This was something I was going to bring up myself, since it is a major
obstacle to re-usable django apps actually providing Python 3
compatibility. I'm +1 on adding forwards compatibility to 1.4.X,
assuming a safe patch.

Luke

--
"In your presence there is fullness of joy; at your right hand are
pleasures forevermore" Psalm 16:11

Luke Plant || http://lukeplant.me.uk/

[Aymeric Augustin]

Given the positive replies, I'll commit this patch (with suitable docs).

Thank you all for your feedback.

--
Aymeric.