>>> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
