[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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4