> I presume this problem would go away if future versions of Python > itself were compiled on Windows with something like MinGW gcc. Also, > this would solve the pain of Python developers attempting to > redistribute py2exe versions of their programs (i.e. they have to own > a Visual Studio license to legally be able to redistribute the > required C runtime) I don't understand enough to know why Visual > Studio was chosen instead of MinGW. Can anyone shed any light on that > decision?
sturlamolden has already given the primary reason: Python, traditionally, attempts to use and work with the system vendor's compiler. On Windows, that's MSC. It's typically the one that best knows about platform details that other compilers might be unaware of. In addition, it's also the compiler and IDE that Windows developers (not just Python core people, but also extension developers and embedders) prefer to use, as it has quite good IDE support (in particular debugging and code browsing). Perhaps more importantly, none of the other compilers is really an alternative. GCC in particular cannot build the Win32 extensions, since it doesn't support the COM and ATL C++ features that they rely on (and may not support other MSC extensions, either). So the Win32 extensions must be built with VS, which means Python itself needs to use the same compiler. Likewise important: gcc/mingw is *not* a complete C compiler on Windows. A complete C compiler would have to include a CRT (on Windows); mingw doesn't (cygwin does, but I think you weren't proposing that Python be built for cygwin - you can easily get cygwin Python anyway). Instead, mingw relies on users having a CRT available to them - and this will be a Microsoft one. So even if gcc was used, we would have versioning issues with Microsoft CRTs, plus we would have to rely on target systems including the right CRT, as we couldn't include it in the distribution. HTH, Martin -- http://mail.python.org/mailman/listinfo/python-list
