On Sat, 16 Feb 2008 18:29:07 +0000, Paul Moore wrote: >> >>BTW: is there a long-time plan to make the Python core *not* link >> >>against msvcrt dll anymore but only rely on Windows APIs (or maybe >> >>also the static C runtime, I don't really care)? >> > >> > How would this affect using MinGW to build Python extensions? >> >> AFAICT, it would make python.dll not depend on any msvcrt.dll, and thus >> being compatible with any extension, compiled with any compiler (with >> any version of msvcrt, or without msvcrt at all). >> >> Putting an end to this annoying "what version of Visual Studio / msvcrt >> do I need for this version of Python?" is a sensible goal, IMHO. > > Actually, it would mean that there was no way of building extensions, as > Python would be using a static C runtime, which extensions wouldn't have > access to (so a FILE* from an extension would be totally incompatible > with the core CRT, a memory block malloc'd in an extension couldn't be > freed by the core, etc...)
Yes. In fact, what I really meant was to get rid of any C-ism from the Python API, so that these problems you are listing simply do not arise. For instance, memory allocation is not a problem as far as I can see, as extensions always use core calls to allocate objects (and those objects get freed through core calls too). But yes, one would have to get rid of the APIs with FILE* and a few others (I wonder if anybody has already made a list). It does not seem like a terrible big deal to me in practice, but I don't know how hard it would be implementation-wise. Consider for instance that it was even proposed to rewrite fileobject.c to use OS native file support (eg: CreateFile on Windows), as the theoretically-portable C API has too many quirks in small details which makes it hard to really provide a Python fileobject consistent across operating systems. In such a scenario, an API like PyFile_FromFile() does not make much sense (but a PyFile_FromDescriptor() might still be useful of course). -- Giovanni Bajo _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
