Python in MinGW, a "FREE" purist attempt?

Ever since Python 2.5 bring msvcrt71.dll along its installer things are kind of inside M$ territory because that dll used to not bundled with Windows and distributing it means you (who compile) must legally own the product where that file came from aka MSVC++ 2003. With M$ releasing Express Edition (2005, 2008 and 2010) for free without particular restriction on its compiler (generally free compiler is restricted to provide Non-Commercial application only), this edition have rocketing MSVC as a build tool and has gaining more attention than MinGW (the open source alternative) for many open source project.

I have seen Python 2.6 being cross-compiled by opensuse in their repositories, the build system is fully automated (source is feed alongside patches) and updated at least every a couple of day (yes that's true). Though they don't provide static libraries and they also build the packages in more Linux-style in absolutely dynamic linking way of DLL. Which soon I realized will confused many Windows user who prefer more compact and portable binaries (by statically linking everything that possible). Directory structure also look ridiculous to Windows which never have the bin-etc-lib-share structure.



Those difference in Python case resulting libpython2.6.dll as opposed python26.dll, development files has been put in \lib\python2.6\ instead of \libs, include headers is in \include\python26 instead simply \include and no  DLLs folder to store core dependencies (seems to be bundled? I'm not sure).And I don't know will they change this too linux-way in the future but this will of course might break currently released of hundreds extension.

The MinGW compilation give you dependencies only to bundled system32 dlls at least thats the recommended way by using MSVC 6's msvcrt.dll file at minimum. This give many developers (majority are using linux) option to support official binaries in more convenient way without ever touching Windows. If the MinGW Python become widely accepted this could be a great alternative than relying on obscure redist-like dependencies (e.g MSVC2008 redist) that sometime confuse end-user. Or it is juts more convenient if the dependencies already in system or lets do it pure "Open Source" way :)

If you want to try:
http://ftp5.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win32/SLE_11/noarch/
look for python and it has 2 dependencies package if I recall: libdb and readline
there is no extension packaged for this python version though, but if they want it I think they could provide most-used extensions available in days.

Edit:
Huh after writing this post, somehow I felt need to mod my existing python to use renamed libpython2.6 -> python26.dll. Here is

First rename it and place it in C:\Python26

run python throw python prompt with error, "eek this one seems didn't read registry setting heh, need to define PYTHONHOME environment (teh unix way)

set PYTHONHOME to "C:\Python26" in Envoriment Variable

run python again, error again as expected, this is because the dll have hardcoded lib\python2.6\ as I mention above. You could see it using filemon (that python.exe keep searching that path and giveup)

Append C:\Python26\Lib\site-packages and C:\Python26\Lib into PYTHONHOME, this way we maintain compatibility with hundreds existing python extension installer since they mostly put core programs inside site-packages folder.

try again, it now become:

testing pygtk demos, perfect! a full set python for PyGTK without external M$ dependencies. will try to use it in next MyPaint

Oh yeah If you're sure enough and know what you do you may move mingw python26.dll to replace official python dll in system32 directory. So far I don't know whether PyWin32 module still works

ouch.. print sys.platform = mingw -->major breakage..very major!, no registry access, msvcrt, specific windows module certainly doesn't works and sys.platform itself is big conditional breakage (though you could hex it). By the way, it need 2 more dependencies: Libtermcap and zlib
This python simply out of nowhere.