Python 3 port - notes for people wanting to review changes/port apps

[Vinay Sajip]

I've created a page on the Django Wiki indicating what guidelines I
used when porting Django from 2.x to a single codebase for 2.x/3.x,
and which can also be followed by people wanting to port apps across
on the same basis. The first cut is at

https://code.djangoproject.com/wiki/PortingNotesFor2To3

and I would welcome your comments - I'm sure I've missed a thing or
two. I will update the page as things occur to me or in response to
feedback about it.

Regards,

Vinay Sajip

[Jacob Kaplan-Moss]

Reading through these notes, a lot of the changes seem reasonably
automatic. What do you think about using lib2to3 to write some custom
fixers to do some of this grunt work automatically? Might help people
port their Django sites/apps a bit easier, right?

Jacob

[Vinay Sajip]

On Dec 10, 8:49 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:

> What do you think about using lib2to3 to write some custom
> fixers to do some of this grunt work automatically? Might help people
> port their Django sites/apps a bit easier, right?

On the face of it, I'd say it's doable, and perhaps worth it - it
would be part of a generic toolset for single-code-base porting, and
not especially Django-specific. But it won't make things automatic,
there will probably always be *some* manual intervention required
(unless a *lot* of time was spent putting intelligence into the fixers
- that might be "how long is a piece of string?" territory). But yes,
it would remove a fair bit of the grunt work.

Of course, you need to be sure that a single code base strategy makes
sense for you. Reading some of Chris McDonough's posts on reddit and
elsewhere, it looks as if Pyramid is using the same approach. Perhaps
the time is ripe to develop some special 2to2plus3 fixers ...

Regards,

Vinay Sajip

[Mikhail Korobov]

Great effort!

What about using 

    from __future__ import unicode_literals

instead of wrapping every constant with a "u" or "b" functions? 

Python 2.6 support 'b' notation so if python 2.5 is not supported there is no need for "u" and "b" functions.

[Mikhail Korobov]

The similar applies to octal constant suggestion: If python 2.5 is not supported is may be better to replace 0777 with 0o777.

* http://docs.python.org/whatsnew/2.6.html#pep-3112-byte-literals

* http://docs.python.org/whatsnew/2.6.html#pep-3127-integer-literal-support-and-syntax

[Ian Kelly]

On Dec 17, 2011 10:12 PM, "Yo-Yo Ma" <baxters...@gmail.com> wrote:
>
> Is this a prank, or is there really going to need to be a u('') for
> every u'' (of which there are thousands, since everything is Unicode
> in Django) in my Django apps, in order to use P3K? Removing the "u" is
> one thing, but adding another text function seems absurd, no?
>
> name = models.CharField(_(u('name'))). # eek :/

The plan is to drop Python 2.5 support on the same timeline as merging this, so no, you won't need to do that, since 2.6+ support the Python 3 literal syntax with a __future__ import.