Daniel, > I wasn't trying to suggest we leave anyone behind, far from it. I > was suggesting move the code to Python 3 now, while there's less code > there (than some future date) but using 3to2[1] to help others on > Python 2.X. Since Django still supports 2.5, it's possible that this > isn't even an option, as I don't know if 3to2 can translate back that > far reliably. Simply getting the question out there for others to mull > over.
Apologies for the misunderstanding. This is definitely an option which should be tried out instead of forward porting with 2to3. That said, it seems like there are a few technical limitations: "However, there is no Distribute support for 3to2 and also Python 2.5 or earlier also do not include the required lib2to3 package. Therefore 3to2 currently remains only an interesting experiment, although this may change in the future." -- http://python3porting.com/strategies.html#using-3to2 Besides that, I could also think that missing Python 3 expertise in the community would prevent a smooth direct transition to Python 3. There is no doubt that it needs to happen eventually but we just need to figure out if we're ready for it. Jannis > On Sep 14, 10:36 am, Jannis Leidel <lei...@gmail.com> wrote: >> Daniel, >> >> >> Huzzah! >> >> >> >> 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 3" >> so we can track the tickets easily. >> >> >> Feedback should go here, on the developers mailing list, to get as many >> eyes on it as possible. >> >> >> 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. >> >> >> 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]. >> >> >> 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 :) >> >> 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. >> >> Jannis >> >> 1:http://docs.python.org/py3k/howto/pyporting.html#try-to-support-pytho... -- 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.
