I'm not going to rehash everything Vernon says below, but I will say that as someone who maintains a module which installs and runs on Python 2.4 - 3.2, Vernon's comments are spot on.
We first started supporting Python 3.0 almost immediately after its release and we had a few misconceptions going in - some of the same misconceptions I'm seeing here by people who have not done this yet. But after working with it for a while now, those misconceptions are gone (for me). You really do maintain one codebase to run in the lowest version of python you support (with forward thinking code) and have setup.py automagically run 2to3 when installing on Python 3+. That is the only workable solution. I realize there are various articles/tutorials out there which talk about how to write code which runs on both 2.x and 3.x without conversion. While it is possible, it is a bear to maintain and IMO should only apply to the setup.py file itself (this means you need to test setup.py in 2.x & 3.x every time you make a change to it - not something we're used to testing regularly). The exception may be a small one file module, which Django certainly is not. On Thu, Sep 15, 2011 at 5:42 AM, VernonCole <vernondc...@gmail.com> wrote: > >> 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 [1]. >> > Don't confuse "recommended" with "necessary." I maintain a module > which installs and runs very nicely on any version of Python >= 2.3. > The automatic operation of 2to3 during the install is like magic. It > really works very well. > >> > Finally, a philosophical question on approach: Should we really be >> > doing 2to3 (leaving the Django codebase in Python 2.X for a long time) > > Yes, that's exactly what you do -- just like you code everything in > Python 2.4 until everyone is ready (or able) to jump to 2.5. You > simply avoid using new language features until that point. If > fortunate people have a later version, then they can use new language > features in their code, just us module authors cannot use them. But > we plan for them. For example, we add __enter__() and __exit__() > methods to objects where that makes sense. If the programmer is using > an older compiler, then they will never get called, but they will be > present when someone with a new compiler uses a "with" statement. We > cannot use "with" in module code, though, until all python 2.4 users > have disappeared. > > Same thing when moving to Python 3.x -- you cannot use any new > features, but you have to refactor your old code in such a way that > 2to3 can do the right thing when it installs. Mostly this means > cleaning up old code which was probably due for a maintenance pass > anyway. Get rid of string exceptions. Make all class definitions > into new style classes. Things like that. > >> > 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. > > Noooo! There is no 3-only work until the last 2.7.n user upgrades. > When that glorious day happens, we will make an archive copy of the > old version, and then run 2to3 for the last time. After that, code > would be maintained in the oldest supported 3.x version. >> >> 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 projects >> 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. Basically >> a "burn bridges as soon as everyone is safe" approach :) > > Yes, that is exactly correct -- and I HAVE ported a 2.x library. I'm > guessing that the jump will be from 2.7 to about 3.3. No sense > supporting obsolete 3.x versions.. >> >> I don't dare to guess when that moment could be though, but it would probably >> happen after a potential Python 2.7 only release of Django -- whenever that >> is. >> > Years .... lots of years, before 2.7 disappears. Hopefully, by then, > others will have been running 3.x versions for years, and will have > long since worked out the kinks. > -- > Vernon > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
