The proposal is for the Python build process to create run time accessible identification data whose purpose is to facilitate run time building of
a) dynamically loadable binary python module objects *.so, .dll etc) b) external (shell) application tools (.exe etc)
This proposal does not fix the format of the information.
Note that (for Unix at least) all this info is already being gathered by the configure script, and stored in the various Makefile. The info also ends up being installed (look in /usr/local/lib/python1.5/config/). For Windows, since the only supported compiler is VC++, it could be hardcoded. However, there's a very serious problem on Windows with Interscript's approach of invoking the compiler at run-time: most users don't have this compiler. I realize that gcc is available for free, but I think it isn't compatible with VC++. As far as I know, VC++ is required if you want to use any of Mark Hammond's stuff (COM and MFC). I don't know if Tcl/Tk can be used (without recompilation) from a gcc-based app, and I don't know how easy it would be to recompile. (Does gcc on Windows have support for Win32 APIs at all?) --Guido van Rossum (home page: http://www.python.org/~guido/)