On Sun, 2008-03-23 at 16:49 -0700, Martin v. Löwis wrote: > At the PyCon sprint, I started porting Django to Python 3.0. In the > process, I had to make a number of changes to Python, so this port > currently requires the Python 3.0 subversion head (soon to be released > as 3.0a4). > > This port is just a start; it runs the tutorial with the sqlite3 > backend, including the admin interface, but probably chokes on larger > applications that use more features. > > The patch is designed to not break Django on any earlier Python > versions. > > I put up the patch and my notes at > > http://wiki.python.org/moin/PortingDjangoTo3k
This is interesting. I read over this during lunch today and it's quite nice. Thanks. Some of the things you've identified as "Django should..." are a little problematic since one of the current requirements (at least for 1.0) is "Django should work out of the box with Python 2.3". Some of your proposed changes don't even work with Python 2.5, so we need to add a few more conditionals. The only potential showstoppers I see are the need to change "except Exception, e:" to "except Exception as e", since that isn't supported in Python 2.5 or earlier and it's going to be hard to fake as it's a major syntactic construction. Also, relative imports aren't supported in 2.4 or earlier whereas they seem to be required to be explicitly specified in 2.6. The latter problem can be fixed a bit by reshuffling some of the import paths, as we've been intending to do in some cases. We use relative imports in a few places to avoid importing a higher-level __init__ file because it does so much (too much) work. That's a change that can be made so everything can do "from django.foo.bar.baz..." and avoid unnecessary "from ." ugliness. Painful and possibly quite disruptive in places, but possible and probably worth doing. We already have a lot of conditional code based on sys.version_info. We'll need to introduce some more. That explains why, e.g., we're using md5 in some places and are testing based on behaviour (try to import hashlib and if that fails, use the fallback). Changing to be a sys.version_info test is not impossible eventually, although it relies on IronPython and Jython being comparable in their version numbering and functionality. Similarly, we can't unconditionally switch to "from io import ...", since that doesn't exist in Python 2.5, let alone earlier versions. Wrapping it in import guards will work, but the code is starting to get a bit ugly to read. Ditto, the reason we use upper-case names when import from email is because that's required by 2.3. They are backwards compatible in later versions, so we intentionally stuck with them. None of this is your fault, Martin, I realise that. I'm just commenting from the notes I took when I read through the patch earlier, more as a record of things we need to think about. Almost all the things you've listed under the new-style classes section are fixed in the queryset-refactor branch. I just checked and I've forgotten to commit one local branch that removes the last ClassType check. We need to retain one use of ClassType to generate the right class type for our own exception subclasses -- they're old-style classes there -- in Python 2.3 and 2.4, but that's guarded by a version_info conditional, so hopefully 2to3.py won't be concerned about that. The one in ModelBase.contribute_to_class can go away, though. That's the one I haven't committed to the branch yet. Anyway, most of those issues will become non-issues once the branch is in trunk. The AdminLogNode sending strings as slices bit me in queryset-refactor, too. I was a bit annoyed that Python allowed it because then I had to work around it. I'm strongly tempted to fix that (i.e. fix AdminLogNode to not be so slack) at a some point, but it's low-priority at the moment, since it breaks indeterminate amounts of code, so I haven't had the energy to work out the impact and/or mitigation. It's kind of cool, though: in Python 2.x, you can write a class that accepts fruit['apple':'banana'] and have it do something. Useful for symbolic enumerated types, I guess. > I would like to know how I should proceed with that; options are > > a) split the patch into separate chunks, and contribute them > separately. > b) hand the entire patch over to somebody interested in completing it > c) complete it, then submit it > d) abandon it > > I would favor option a), even though this means that the django source > repository would only get a part of a working 3.0 port; I might > continue to work on it over the next months, although I would again > hope that regular Django users take over (which I am not). I'm not going to make a call here; I'll leave that up to Jacob and Adrian, but I would hope our plan isn't to leave Python 2.5 (and maybe even 2.4) behind too quickly. It's a bit too easy to be blinkered in Open Source development into thinking others should/must upgrade entire system components (their entire Python install) as fast as we do just because they want to use one package. Our strategy on that front guides our porting strategy for 2.6/3.0 to a large extent. There's also the question of how mainline to make the 3.0 support given it's only in alpha at the moment. So maybe this is work for a branch. *shrug* Anyway, that's just one man's thoughts from reading through the wiki page and the patch. It's interesting to see the level of changes required. Nothing too surprising, although a few of the necessary shuffles strike me as annoying since they imply Python 2.6 is breaking compatibility in potentially unnecessary ways. Nice work, though. Malcolm -- What if there were no hypothetical questions? http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
