[Python-Dev] Compiler used to build Python for Windows

["Martin v. Löwis"]

>>> I think the best lesson here is Tcl. Because it uses stubs mechanism,
>>> you don't need to depend on tclXX.dll, you don't deal with really
>>> direct implementation details, you don't care about runtimes,
>>> everything is much easier. Maybe it's possible (and not too late) for
>>> Python to somehow embrace such mechanism?
>> It would be possible, but it would be a fairly large project. You would
>> have to remove a lot of things from the Python header files, and that
>> would cause significant breakage in existing extension modules.
> 
> Hmm, would it? I mean, you can currently build extensions with MinGW (at least
> from what I heard, I never managed to do so as it would require cross
> compiling for Windows), so why would you say you'd have to update the header
> files?

I wasn't talking about building with other compilers, but about the 
subject of the Tcl stub mechanism being applied to Python. As others
noted, that mechanism doesn't help at all with the issue of different
CRTs.

It does help with another issue, though, namely the constant ABI
changes that we see. Every time the ABI changes, extension modules
have to be recompiled. With a scheme similar to Tcl stubs, that need
could go away. This would be particularly useful on Windows, where
each feature release comes up with the new DLL name. With such a
mechanism in place, we could do "python3.dll" (rather than python30.dll,
python31.dll, and so on).

To implement such a system, you need to get all ABI dependencies out
of the header files; this includes the structure layouts in particular.
You might want to keep struct _object, for sake of INCREF/DECREF. You
then need to specify which of the remaining functions officially belongs
to the ABI, and freeze them for the lifetime of Python 3. New functions
can be added, but when changing the signature, the old functions must
remain in place. In Tcl stubs, that is achieved through a function
vector, IIUC.

HTH,
Martin