D'Arcy asked if I could port basicproperty, basictypes, wxoo, etceteras to Python3.  Not really high on the priority list, but why not dash it off; add 2to3, see happy Python3-ers.  Will log any issues as they arise here...

Python3.2 testing virtualenv can't install anything (not even pip).  Seems that the distribute and distutils code are fighting about string/unicode mis-matches, possibly this virtualenv is from before a system python update?  Okay, blow away and rebuild the testing virtualenv.  Sorts that.

BasicProperty is some pretty old code. Last heavily worked on in the Python 2.2 era IIRC, with shims that allowed Python 2.2 to use some of the cool new features in Python 2.3 (such as true booleans).  Oops, those cause syntax errors in Python3 (assigning to True/False).  Okay, drop Python 2.2 support, that's fine; though IIRC one of the biggest projects using this library is actually still on Python 2.2 due to some dependency not having been ported beyond that; no big deal, that code-base is nailed to the perch as far as I am concerned.

"new" module is gone, turns out it's been deprecated since 2.6.  Use types.MethodType to replace new.instancemethod.

Was using "import X", which 2to3 translated to "from . import X", which then failed with trying to use relative import when not in a package when I tried to run the test suite directly.  Okay, write all of those with full-path imports.  This is all from pre-nose days, should really rewrite with that instead.

No types.InstanceMethod any more.  No types.UnboundMethodType any more.  Those need to be conditionally added to the set of function-like things when you want to check for function-like-ness.

Exceptions can no longer be any class, need to be Exception subclasses.

x < y can now fail if the two values are of different types.  That's going to break things later on if I can get that far.

Code was (somewhat) unicode/string aware.  Seeing subtle-seeming errors where code tries to do unicode operations on what turn out to be strings, or string operations on what turn out to be unicode.  Guessing 2to3 has converted previously "str" literals into unicode values.  Those look annoying to trace down, and not something I want to dive into after a long day at work... I don't think I'm going to finish today.

egenix-mx-base doesn't install with pip yet, will have to look into whether there's a Python-3 branch that can be installed.  Definitely not finishing today.  Blocks the test suite until I can rework it not to require egenix on import.

Most of the changes so far are not so bad.  The comparison TypeErrors will be a pain if I ever get around to the higher-level libraries, as lots of the code higher up expects to be able to put two objects into a list and be able to sort reliably. All code that was explicitly unicode aware is likely going to have to be combed over to find the areas where 2to3 assumed naive code.

It took about 2 hours to get the basicproperty/basictypes code base somewhat almost just-about maybe-soon translated.  I can't begin to guess at the amount of time it will take to track down the remaining errors, and I haven't the interest to do it tonight.  The upper-level code (the ORM and GUI layers) will likely take at least as much time to port.  Probably more time than most projects of similar size (about 5300LOC), as it is fairly "meta" and fairly old, thus references more obscure features that aren't caught by 2to3.

There are a handful of projects using the code-base, but none of them, is in active development.  I certainly have quite a few scripts (such as py3d.py) and tools that use it.  So far it has taken far longer than I'd hoped, and I've run into more road-blocks than I'd hoped, but at least it is helping me set up estimates for porting costs for other projects.

For reference, PyDispatcher took a full morning to port (it is around 1000LOC), but PyOpenGL (around 55,000LOC, but mostly auto-generated) was ported with a few small patches from users. (With the caveat that the level of porting is unknown, as I haven't ported OpenGLContext over to be able to test it). OpenGLContext is actually much larger than PyOpenGL in terms of the amount of non-generated code; it's got something like 25,000LOC in the library and tests, as well as another 5000LOC or so in secondary libraries on top of dependencies on PyDispatcher *and* SimpleParse (7000LOC).