Jannis,
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. Daniel On Sep 14, 10:36 am, Jannis Leidel <lei...@gmail.com> wrote: > Daniel, > > > "You have my sword." I want to see this happen & would love to be a > > part of it. > > Huzzah! > > > 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 3" > 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. > > > * 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 [1]. > > > 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 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... > > > > > > > > > > > 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öwis has been working on a port for > >> a while [1] but only recently I've had the chance to meet with him and > >> 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. > > >> Goals > >> ----- > > >> To allow Django to run on Python 3 there are several goals to achieve, > >> some of which are our respsonsibility, some depend on 3rd party libraries > >> 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 needed) > > >> 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 > >> strategy. > > >> 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 major > >> versions of Python at the same time, with the same code base. > > >> Fortunately the Python community gained lots of experience in the past > >> years to make this happen (e.g. Lennart Regebro's book [4]). There are > >> also tools to ease the transition of Django and the Django-based > >> projects. Some of which are: > > >> - six [3] -- a compatibility library that includes many (if not all) > >> needed import proxies and utilities to prepare Django and Django-based > >> 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 [2] -- an extensible library which is able to translate the rest > >> 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 can > >> write our own if needed. It integrates with distutils (in Python 3.X) > >> and is able to convert Django at installation time. Installing Django > >> 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: > > >> https://code.djangoproject.com/browser/django/branches/features/py3k/ > > >> Some notable changes: > > >> - a modified ``setup.py`` which automatically calls 2to3 during > >> installation > > >> - a ``py3ktest`` helper bash script which -- for now -- installs Django in > >> a directory called "3k" in the same directory to trigger the translation > >> from Python 2 to Python 3 code and then run the tests from the build > >> directory directly because they are not part of the installation in "3k" > >> 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 use > >> tox instead? [5]). > > >> - a new django.utils.py3 module which contains some helpers that are used > >> throughout the code as a common API to ease the pain of maintaining a > >> project that runs on both Python 2 and 3. I expect it to grow in size > >> while we port Django, but even then it may not be complete enough to > >> be useful for Django-based user projects. Which is why I think Django > >> should ship the "six" library [3] instead, on the long run ("six" has > >> the advantage of being maintained by a Python core developer). > > >> A good overview of the current changes can be seen on Bitbucket: > > >> https://bitbucket.org/django/django/compare/features/py3k..default > > >> Right now it's mostly changes to how byte and unicode strings are handled > >> 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`` script > >> and fix the failed tests (needs an installed ``python3`` binary), one > >> by one. This may be repetitive work, but could also be the chance for > >> you to dive into the internals of Django. > > >> - Write a tutorial to prepare a Django app to for Python 3 by using one > >> of the tools we provide. Have a look at the official porting guides [6] > >> for inspiration. > > >> - Help port the 3rd party libraries we rely on in Django (e.g. MySQLdb [7]) > >> by getting in touch with their community. > > >> There are probably lots of other small steps to make, but I'm confident > >> that > >> we'll figure them out on the way. > > >> Let's start the porting, Python 3 is waiting for us, > >> Jannis > > >> 1:https://bitbucket.org/loewis/django-3k/ > >> 2:http://docs.python.org/library/2to3.html > >> 3:http://pypi.python.org/pypi/six > >> 4:http://python3porting.com/ > >> 5:http://tox.readthedocs.org/ > >> 6:http://docs.python.org/py3k/howto/pyporting.html > >> 7:http://sourceforge.net/projects/mysql-python/forums/forum/70460/topic... -- 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.
