On 28.11.2011, at 18:08, Vinay Sajip wrote: > 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.
I see, that's absolutely fine, and to be honest, getting so much progress done is definitely a good problem to have :) >> 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. Ah, that makes sense, in fact your approach is much closer to what I remember doing when pip and virtualenv was ported. In that sense, I'm definitely fine with that. How much of that approach needs to be documented for end users is probably something we can deal with later. >> 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? Honestly, I'm not sure how hard the merge is, as I'm not sure how much changed. Martin could probably shed some light on it how he wants to deal with it (e.g. svnmerge.py or not). >> 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. Fair enough, I just realized that's a discussion we need to have in a separate thread (~"What's the best approach for migrating Django projects from 2.X to 3.X?") that can be handled later in the porting process. When in doubt I would rather use a module like six that has community traction than writing our own though. >> 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). Personally I'm fine with it, but as you say, it requires discipline (I broke pip more than once). But it's definitely something that needs some input from the other core devs, and probably a very good documentation of the dos and don'ts. > 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. Jannis -- 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.
