[Tim]

...

Log Message: David Abrahams tried to compile this as a separate DLL under MSVC, and got a barrage of compile errors that didn't make sense to the C++ brain: MSVC does not allow C (but does allow C++) initializers to contain data addresses supplied by other DLLs. So changed the initializers here to use dummy nulls, and changed module init to plug in the foreign addresses at runtime (manually simulating what C++ does by magic). Tested on Windows, and Guido tested on Linux (thanks!). BTW, the *point* is that people are going to use this module as a template for writing their own subtypes, and it's unusual for extension authors to build their extensions into Python directly (separate DLLs are the norm on Windows); so it's better if we give them a template that works <wink>.

[MAL]

This is a common problem when compiling Windows extensions. Perhaps we should provide some more generic way to help the extension writers here ?! FWIW, I'm using this macro for doing the deferred type init:

#define PyType_Init(x) \ { \ x.ob_type = &PyType_Type; \ }

Hm, alternatively, we could put a statement in PyType_Ready() that initializes ob_type if it's NULL -- then we'd encourage people to call PyType_Ready(), which is a good idea anyway. --Guido van Rossum (home page: http://www.python.org/~guido/)