[Python-3000] Windows, sys.argv and unicode
rasky at develer.com
Sat Feb 16 20:08:54 CET 2008
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
More information about the Python-3000