I can't recall if I mentioned this before, but it can't hurt to mention it
again.
The py3k branch is looking in pretty good shape - it should build correctly
for py3k and pass most tests. Most interestingly, the Python code is also
looking in excellent shape. What I do is take a copy of the pywin32 trunk,
then execute:
2to3 -f basestring -f exec -f except -f dict -f import -f imports -f next -f
nonzero -f print -f raw_input -f long -f standarderror -f types -f unicode
-f urllib -f xrange com win32 Pythonwin pywin32_postinstall.py setup.py
And compare the re-written files with the py3k branch. The only real
differences left are b'' literals and a few other misc things, like sorting.
On the 'py3k integration' branch (maintained in 2.x syntax), setup.py also
restricts the number of fixers used, which helps speed things up a lot.
Also FWIW, I'm using 'kdiff3' from sourceforge as a merging tool - it does a
pretty good job at comparing trees and merging selected changes between
them.
Roger: please let me know if you will have any more time to continue your
work in the shorter term, and if so, what you think you might be looking at,
just so I don't step on your toes more than I probably already have. My
next job will probably be to merge all the "module init" and "getattro"
changes from the branch - probably all but the win32ui and COM in thse first
instance, so I can closely review the inheritance related changes in these
modules separately.
Either way, I will probably try and get a new pywin32 build out this year -
even before the branches are fully merged. The more I get merged the better
though, as the more problems we can shake out in a first "experimental" type
release, the better.
Thanks!
Mark
|
