> 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.
