Microsoft have withdrawn the free Toolkit Compiler
2003. This patch to PCBuild\readme.txt updates the
Python build documentation to reflect this fact.

Logged In: YES 
user_id=1543425

If I interpret the bug tracker correctly, the 2.5 team is 
not about to change the "normal" build process for windows, 
because they refer to a special pcbuild8 directory for 
building with Visual Studio express. Of course if building 
python 2.5 with VC8 is possible, this is an improvement. 

But the problem is:
the "normal" build process of a python distribution is also 
integrated into the setup modules for building extensions (.
pyd-Files). And that means: anyone who wants to build a c-
language extension, has to 

-   either still have the withdrawn MS compiler
-   or build a custom version of python 2.5 (with pcbuild 8
).

And what about distributing the .pyd-Files if she/he uses 
alternative 2? One would have to distribute the custom 
python version too.

My conclusion:
it would be very helpful if the windows version of python 2.
5 were build with the vc8 compiler!

Logged In: YES 
user_id=113328

Please note:

1. Prior to the existence of the free Toolkit compiler,
there was no supported method for building Python with a
free compiler. It's sad (and annoying) that MS withdrew the
compiler version just as support was added to Python, but
it's just a reversion to the prior situation.

2. Building extensions is a separate issue, which is more
related to the compiler used to build the official binaries
than to what options exist for building Python for yourself.

3. If you want to build extensions for Python, you can use
mingw (gcc) as well as MSVC. This has been supported for a
long time now.

4. Mingw does not currently support linking with
msvcr80.dll, so if the official Python build moves to VC8,
we will lose the option of building extensions with mingw.

Therefore, I see no advantage to switching the official
builds to VC8, in terms of extension building. You gain VC
2005 Express as an option, but lose mingw. As mingw is a
long-established option, you in effect lose because you've
gone from a well-tested option to a new, relatively untried one.

Logged In: YES 
user_id=2042

-1 for killing mingw compatibility by using VC8.

Logged In: YES 
user_id=1543425

When will mingw move to msvcrt80.dll?

Logged In: YES 
user_id=113328

mingw-runtime 3.10 (released a few days ago) supports
msvcr80. Python (distutils) would need a patch to supply the
necessary flags when it detects that python.exe is using
msvcr80 (that's non-trivial, as you need to know, and
hard-code, the MSVC compiler version numbers :-(). As we're
in feature-freeze for Python 2.5, this won't happen until
2.6, but I am happy to make a patch for 2.6 to support
msvcr80 in distutils (assuming someone lets me know the
relevant MSVC build numbers when I need them).

By the way, this thread is irrelevant to the actual patch,
which is merely a doc patch...

Logged In: YES 
user_id=21627

Thanks for the patch, committed as r47162.