I've started playing around with traits in what I think is the logical first step -- the _transforms extension module.
Before I go too far, a couple of questions arising from the fact that many of the extension types (Point, Bbox, ...) have C members. The biggest concern is that a simple re-implementation in traits would move all this to a Python level and thus presumably slow things down. Is this perceived to be a significant issue?
If yes, then there seem two potential options to re-gain speed from the C level.
Option A: Python classes derive from traits.HasTraits to implement Point, Bbox, etc. but each would have a self._shadow member which is an extension type with its own internal values needed by other C level code (potentially including a copy of the Python-level attributes). Using trait's notification abilities, it shouldn't be any problem to keep the shadow in sync with the Python level, and C code could set attributes as needed through the Python interface. This option seems slightly messy, but probably workable. Also, it would have the benefit of keeping things mostly in Python, at least before optimization.
Option B: re-tool the traits machinery to support extension types. I've thought about two ways to do this and neither seem appealing. Both involve significant changes to the traits infrastructure because for definitions to be available to C without the equivalent of a dict lookup, they would have to be made at compile time. Method 1: make multiple extenstion types that derive from has_traits_object (defined in ctraits.c) rather than PyObject and re-jig the higher level machinery for each of these new extension types. Method 2: drop traits itself and implement traits-like functionality (in CXX?). However appealing this option is in concept, both of these proposed methods would probably require some deep Python magic that I'm not sure we should bother with (even if we presume we have the necessary skills).
I'm attaching a couple of files: First is the beginnings of a new transforms.py which mainly includes the data structures and constructors. I actually wrote this before the above regarding matured, so comments regarding what is and is not needed from the Python level are welcome. (What should be hidden in just the _shadows?) Also, regions marked XXX reflect my uncertainty about other issues -- clarification on these will be appreciated. The second file I'm including is polynomial.py, a pure-Python proof-of-concept implementation of the shadow idea.
What do folks think?
polynomial.py (1010 Bytes)
transforms.py (8.69 KB)