> I disagree;

 i would say that you're entitled to disagree, but i have to point
 out that unless you've actually been through the process of trying
 to port python to mingw32 you're not really in a position of ...
 how can i put this best... you're entitled to say "i disagree"
 but that doesn't actually carry any weight.

 if you said "i've tried compiling this patch, and i looked at
 it and i disagreed with the decision to create a new platform,
 so i removed that code, here's an updated patch, i found it to
 work absolutely fine" THEN i would say that you are in a position
 of authority to "disagree".

 so - question: have you actually _tried_ compiling python with
 mingw32, with the latest patch?


> programs compiled with mingw32 run on Windows, and use the MSVC 
> runtime.

 they do indeed.  this however has absolutely no relevance.

> It's the same platform as the current win32 build.
> It's even possible to use mingw32 to compile extensions
> for the VS9.0 based python.exe.
 
 it is indeed.  the patch that i did allowed you to specify
 a gcc spec file which did exactly that: i added options to
 compile not only extensions but also the entire python.exe
 to use a different MSVCRT runtime.

 _and_ it did assemblies, too.


> A different compiler does not make a new platform.

 ok.

 unfortunately, as the work that i did was well over a year ago,
 i'm going from memory - but basically, i'm very very sorry to
 have to point out that you don't know what you're talking about,
 here.

 let me try and go through it.

 look at the platform detection code: it parses the gcc version
 string.  it goes "if compiler has string gcc but also has win32
 then it must be cygwin platform".

 otherwise it goes "this must be MSVC win32 platform".

 this _simply_ doesn't work, hence the need to do further
 detection, hence the need to have a separate compiler type.
 ... but it doesn't end there: there are subtle differences
 between MSVC win32 and MINGW32 win32 (differences in the
 build .lib files that specify what functions are available
 in the DLLs. mingw32 is a reverse-engineering project,
 remember?)

 to be honest i can't remember if i actually set sys.platform to
 mingw32 - but the more time i spent getting more and more modules
 to compile, the more blindingly obvious it was that a new platform
 type was needed.

 i encountered dozens of assumptions that "if sys.platform == 'win32'
 then you MUST be building using visual studio: f*** off with your
 attempt to compile this module using gcc".
 
 over the eight to ten week period in which i focussed on this
 non-stop for about 13 hours a day, the list just went on and on
 of discrepancies that had to be solved, and if i _hadn't_ set a
 new platform type, it would have been necessary to add extra
 tests instead:

  "if sys.platform == 'win32' and not {something to detect mingw32}":

 mingw32 _really_ does fall between both worlds: not just the
 compiler type is different, but there are even features and
 functions _missing_ from mingw32 that are present in MSVC.
 i had to work with roumen to get patches to mingw32 upstream
 in some cases!

 so please _do_ stop putting road-blocks in the way.  this is
 a complex enough project, having to fit half way between
 two disparate worlds, without it being stymied by "disagreement"
 when you haven't _actually_ tried compiling this code (if you
 have, i apologise).

 btw if you'd like to try compiling it, but are adamant about
 staying away from proprietary operating systems, i _did_
 manage to get python 2.5 and 2.6 cross-compiled to run under wine.
 ironically there were long-standing bugs in wine that ended up
 getting fixed as a result of running the 25,000 python unit tests,
 but that's another story... :)

 l.

 p.s. msys runs under wine as well, but the configure stage takes
 well over an hour.  the patch i created cut out most of configure
 and replaced it with a pcconfig.h just like win32, which i had
 to create by hand.  this was quicker than waiting for configure
 to run.