Message from discussion Python 3 and you
Received: by 10.204.142.71 with SMTP id p7mr1883606bku.16.1316014638599;
Wed, 14 Sep 2011 08:37:18 -0700 (PDT)
Received: by 10.204.2.69 with SMTP id 5ls2302614bki.1.gmail; Wed, 14 Sep 2011
08:37:03 -0700 (PDT)
Received: by 10.204.142.71 with SMTP id p7mr1883536bku.16.1316014623366;
Wed, 14 Sep 2011 08:37:03 -0700 (PDT)
Received: by 10.204.142.71 with SMTP id p7mr1883535bku.16.1316014623344;
Wed, 14 Sep 2011 08:37:03 -0700 (PDT)
Received: from mail-bw0-f50.google.com (mail-bw0-f50.google.com [184.108.40.206])
by gmr-mx.google.com with ESMTPS id b12si89268bkt.1.2011.09.14.08.37.03
Wed, 14 Sep 2011 08:37:03 -0700 (PDT)
Received-SPF: pass (google.com: domain of lei...@gmail.com designates 220.127.116.11 as permitted sender) client-ip=18.104.22.168;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of lei...@gmail.com designates 22.214.171.124 as permitted sender) smtp.mail=lei...@gmail.com; dkim=pass (test mode) header...@gmail.com
Received: by bkbzt19 with SMTP id zt19so1542119bkb.9
for <email@example.com>; Wed, 14 Sep 2011 08:37:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
Received: by 10.204.152.154 with SMTP id g26mr6828bkw.34.1316014622281;
Wed, 14 Sep 2011 08:37:02 -0700 (PDT)
Received: from [192.168.68.118] (p578be83d.dip0.t-ipconnect.de. [126.96.36.199])
by mx.google.com with ESMTPS id af16sm605841bkc.10.2011.09.14.08.36.59
Wed, 14 Sep 2011 08:37:00 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1244.3)
Subject: Re: Python 3 and you
From: Jannis Leidel <lei...@gmail.com>
Date: Wed, 14 Sep 2011 17:36:58 +0200
References: <AE84C185-58F8-4784-88F7-DDA3A1524...@gmail.com> <1c72f67c-e94c-4a7d-8534-6a77844f3...@z7g2000vbp.googlegroups.com>
X-Mailer: Apple Mail (2.1244.3)
> "You have my sword." I want to see this happen & would love to be a
> part of it.
> A couple questions:
> * How should patches be provided? Trac? BitBucket?
For now via Trac, that's why we've moved the changes into a SVN branch.
Unless anyone has a better idea I could create a Trac component "Python =
so we can track the tickets easily.
> * Where should feedback go? This mailing list? Somewhere else?
Feedback should go here, on the developers mailing list, to get as many
eyes on it as possible. =20
> * This is further off, but once we have a ported Django, how do get
> the community (specifically pluggable apps) onboard? I'm assuming the
> docs are meant to do this but wondering if there's anything else we
> can be doing (like perhaps a Django-specific 2to3 (extension?) to
> cover common Django conventions).
Very good question, I'm uncertain as to how the "helpers" I mentioned
will look like in the end. Whether they will be part of Django (e.g.
a management command to run 2to3 on an app) or if we "only" provide the
necessary compatibility library (e.g. "six") so that 3rd party app
authors would still keep writing apps with Python 2 but would allow
their apps to be translated to Python 3 automatically. Documenting ways
of how to write a setup.py to do the conversion during install time
is *in* the scope of what we need to provide, IMO. Whether we need
Django-specific 2to3 fixers isn't clear at this time as the porting
has only just begun.
> * Do we have a target date? I know this is hard with a volunteer-only
> effort, but if we setup some sort of timeline, we'd at least have a
> metric & something to shoot/push for.
One assumption of the strategy I outlined was the fact that Django is
as close to 3.X as possible. Django 1.4 will require Python 2.5 or
higher, but I'm not sure how quick we can do the jump to 2.6, which
is recommended by the Python porting docs .
> Finally, a philosophical question on approach: Should we really be
> doing 2to3 (leaving the Django codebase in Python 2.X for a long time)
> or would it be better to port Django over to Python 3 & use 3to2 for
> existing Python 2.X installs? I confess I don't know much about the
> current state of 3to2 (nor how most other Python libraries are
> handling the transition). But I do know Django will continue to grow
> over time & I worry that, at some point in the future we'll be making
> more even more work for someone else to do the 3-only work.
I personally haven't ported a 2.X library completely to 3.X yet, so I
can also only guess. But from what I've seen in the community I'm afraid
of a "clean cut" port because it has a high risk of leaving many =
and apps behind. In that sense it seems more sensible to me to see the
port to Python 3 just as another step of our Python version deprecation
policy, which we at some point take with a complete conversion. =
a "burn bridges as soon as everyone is safe" approach :)
I don't dare to guess when that moment could be though, but it would =
happen after a potential Python 2.7 only release of Django -- whenever =
> On Sep 14, 8:03 am, Jannis Leidel <lei...@gmail.com> wrote:
>> Hi all,
>> After last week's sprint I wanted to get you up-to-speed about the
>> current state of porting Django to Python 3.
>> As some may be aware Martin von L=F6wis has been working on a port =
>> a while  but only recently I've had the chance to meet with him =
>> talk through the porting process.
>> I'm not going to hide the fact that it'll be a long process, but I'm
>> also convinced it's an important step for Django to make. I'm writing
>> this in the hope to find volunteers to join the porting efforts.
>> To allow Django to run on Python 3 there are several goals to =
>> some of which are our respsonsibility, some depend on 3rd party =
>> we use internally and some left to the users that use Django to build
>> their websites. It's my understanding that we can't solve everything
>> at once, so take this with a grain of salt:
>> - get Django to run on Python 3
>> - provide helpers and docs for porting Django-based projects
>> - help out 3rd party projects we rely only to make the jump (if =
>> Porting strategies
>> As you can imagine there are still quite a few open questions at
>> the moment about specific porting problems but taking from the
>> experience in the Python community I think we have a good general
>> There are a few assumptions we're applying either because it's
>> unrealistic or impossible to maintain as long as Python 2.X is in
>> use for the forseeable future; so these strategy *don't* work:
>> - Create a Python 3 only port ("burning the bridges")
>> This is outright a no-go since it would leave all the Python 2.X
>> projects in dead water. Instead we need to provide a migration
>> path for them.
>> - Maintaing a separate Python 3 branch ("dual releases")
>> While this would allow for new projects to use Python 3, I'm
>> convinced this has the potential to split the community. It'd
>> also be a major burden for the core team to maintain both
>> branches. Instead we need a combined effort.
>> So as a result of that the only viable option is to support both =
>> versions of Python at the same time, with the same code base.
>> Fortunately the Python community gained lots of experience in the =
>> years to make this happen (e.g. Lennart Regebro's book ). There =
>> also tools to ease the transition of Django and the Django-based
>> projects. Some of which are:
>> - six  -- a compatibility library that includes many (if not all)
>> needed import proxies and utilities to prepare Django and =
>> projects to be ported to Python 3.X. This only applies to API that
>> isn't syntactically changed, but only moved or enhanced in 3.X.
>> - 2to3  -- an extensible library which is able to translate the =
>> of the Python 2 code to the Python 3 equivalent. For every Django
>> specific feature that isn't covered by the default 2to3 "fixers" we =
>> write our own if needed. It integrates with distutils (in Python =
>> and is able to convert Django at installation time. Installing =
>> with Python 2 wouldn't trigger the translation process, of course.
>> Code status
>> During the sprint we've moved Martin's code from a Bitbucket clone to
>> an own SVN branch:
>> Some notable changes:
>> - a modified ``setup.py`` which automatically calls 2to3 during =
>> - a ``py3ktest`` helper bash script which -- for now -- installs =
>> a directory called "3k" in the same directory to trigger the =
>> from Python 2 to Python 3 code and then run the tests from the =
>> directory directly because they are not part of the installation in =
>> because we don't include it. This script should be seen a temporary
>> workaround till we've found a better way to run the tests (Could we =
>> tox instead? ).
>> - a new django.utils.py3 module which contains some helpers that are =
>> throughout the code as a common API to ease the pain of maintaining =
>> project that runs on both Python 2 and 3. I expect it to grow in =
>> while we port Django, but even then it may not be complete enough =
>> be useful for Django-based user projects. Which is why I think =
>> should ship the "six" library  instead, on the long run ("six" =
>> the advantage of being maintained by a Python core developer).
>> A good overview of the current changes can be seen on Bitbucket:
>> Right now it's mostly changes to how byte and unicode strings are =
>> by using a b() and u() function instead of the 'u' prefix. That said,
>> this is far from complete.
>> How to help
>> We have multiple big pieces of the puzzle to solve:
>> - Try out the branch by running the tests with the ``py3ktest`` =
>> and fix the failed tests (needs an installed ``python3`` binary), =
>> by one. This may be repetitive work, but could also be the chance =
>> you to dive into the internals of Django.
>> - Write a tutorial to prepare a Django app to for Python 3 by using =
>> of the tools we provide. Have a look at the official porting guides =
>> for inspiration.
>> - Help port the 3rd party libraries we rely on in Django (e.g. =
>> by getting in touch with their community.
>> There are probably lots of other small steps to make, but I'm =
>> we'll figure them out on the way.
>> Let's start the porting, Python 3 is waiting for us,