On Nov 28, 1:04 pm, Jannis Leidel <lei...@gmail.com> wrote: > > I'm a bit concerned that you didn't get in touch with us before you > started with the work, since tracking the changes would have been > easier. FWIW, Martin von Löwis, Alex and me would be those you can > ask if you need any further help, usually also on IRC in #django-dev. >
Well, it's only been about a week of elapsed time. I always start these sort of ports on an experimental-and-potentially-throwaway basis, and I didn't know until I started how things would progress - and well, once I was into it, I was just dipping in and out amidst doing other things, so I suppose I just focused on the task at hand rather than the big picture. > Have you worked on top of the current py3k branch in SVN (which should > be mirrored in the Mercurial repo)? Also, did you get in touch with > Martin von Löwis who has previously spearheaded the porting efforts > for a while and has been granted commit privileges to the py3k branch? Yes, I used the BitBucket repo and the features/py3k branch within that. I didn't contact Martin directly about this, as my approach is a little different to what he had started, in that Martin's approach is based on running 2to3 on the code to get new 3-friendly code, whereas my approach is to have a single codebase with runs on 2.x and 3.x. It's more than a small philosophical difference - I value the information that 2to3 gives, but it just acts as the driver for porting "by hand" with my standard development tools. > I'm asking simply because I'm wondering how we should get your changes > reviewed and committed to the official repo, it's a bit like facing a > done deal. Well, I undertook the approach you mentioned in the "Python 3 and you" thread back in September, which was to look at the features/py3k branch and focus on test failures. Of course I didn't use the py3ktest script (which involves the 2to3 pass), running just plain runtests.py instead. And it's only been a little over a week, so it can't be that hard to merge the changes assuming you agree with the approach. Even if you start over, it's still less than a person-week of effort, right? > Aha, meaning that you've copied over parts of the six module? Would you > (also as a way for helping out Django users later to port their code) > recommend putting six completely in Django? We've previously done that > with other libraries, e.g. unittest2. I have no strong views on using six directly as a dependency, and I've only used small parts of it (with_metaclass, reraise) directly. It's certainly not needed as a dependency - you can see that the django.utils.py3 module (which provides the functionality needed by Django) is pretty small. > Yeah, we've talked about that and don't consider 3.0 or 3.1 to be sensible to > support in the future (given obvious bugs and/or lack of support from Python > core). Good, that rhymes with my thinking on it :-) > Indeed they are, so the next step is to review them bit by bit and align > it with the work done before your work. Ideally committing it to SVN. Right, and I can provide some help with that (other work permitting). Possibly some work could be done to look at merging the default branch with the features/py3k branch, as a first step - presumably default tracks SVN trunk closely. The main thing is to see whether you are comfortable with the single codebase approach (requires some small additional discipline from developers to consider str/bytes issues carefully, do imports from utils.py3 where appropriate, etc. - nothing too onerous). Carl Meyer may be able to chime in with his experience re. pip/virtualenv, which were ported using the same approach a while ago, and have seen maintenance work and new releases since then. Also it's worth looking at the way metaclasses have been done in the port and to see if you can identify any issues. A lot of the changes are pretty mechanical, wrapping literals with u() and b() - nothing too contentious there. Escape character handling esp. in regexes is another area where closer inspection would be worthwhile. The test codebase contained a lot of Unicode literals (i.e. Unicode literals in the source code, which would have been encoded in UTF-8 in the files actually stored on disk) and I have converted these to use Unicode escapes, as this is more portable. Regards, Vinay Sajip -- 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.
