Help to cite appropriately. [1] was http://pypi.python.org/pypi/3to2.
On Sep 14, 10:55 am, Daniel Lindsley <polarc...@gmail.com> wrote: > 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.... > > read more » -- 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.
