Having survived the update of pywin32 to python 3, let me say that both comments are correct: 1) you do NOT create a fork, you convert the existing code so that it will run through 2to3 2) it takes a LOT of hand refactoring of older 2.x code to get ready for 2to3. and, may I add: 3) it's worth the work. The refactoring tends to clean up rough edges that have been hanging around the old code from long, long ago. IMHO it is absolutely necessary for one or more core developers to be intimately involved with the conversion. Such things as conversion to new style classes and byte buffer creation objects will very likely reach into a majority of the existing modules, so the volume of patches will be very large. If these patches are not integrated into the tip branch(es) rapidly, it is likely that new work will get very confusing. I personally found it very helpful to incorporate suggestions from the guys doing the 2-to-3 conversion directly into the development branch I was working on -- so that within a day my development branch became the 2-to-3 conversion branch as well. By the time I finished my next incremental update, it was 2to3 ready.
Cheering from the sidelines is not enough. By the way, the pywin32 modules work in all versions of Python from 2.3 to 3.1 (mine works in IronPython as well.) 2.6 is helpful for a conversion effort, but not necessary. -- Vernon Cole On Jan 13, 7:22 am, Karen Tracey <kmtra...@gmail.com> wrote: > On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa <hanne....@gmail.com> wrote: > > 2010/1/13 Tobias McNulty <tob...@caktusgroup.com>: > > > I am by no means an expert on the matter, but I remember seeing a comment > > > awhile back suggesting that it generally makes more sense to fix the 2to3 > > > script than to maintain two branches of the same library. Might that be > > the > > > case here as well? > > > Py3K does not support old-style classes. Django uses these quite a > > lot, for instance the Meta-class of a model is old-style. I don't > > think it is in any way possible to have an automatic script convert > > these in a sensible way as django is deliberately utilizing the > > difference between old and new style in no doubt a django-specific > > way. If django on 2.x could be rewritten to no longer depend on > > old-style classes, and was made to depend on python 2.6 or newer, then > > 2to3 would have a chance to do its magic. > > I'm no expert either, but as I understanding it maintaining single source > for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the > 3.x version during install may be a viable option. This is the approach > that was taken by Martin v. Löwis when he got an initial port working back > in late 2008: > > http://wiki.python.org/moin/PortingDjangoTo3k > > He cites bugs in 2to3 as a barrier to getting the approach to work at that > time, but doesn't note anything insurmountable he ran across in the Django > source. It is true the port only verified that getting through the tutorial > worked, but that covers the basics of models certainly. > > Karen
-- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
