Which compiler will Python 2.5 / Windows (Intel) be built with?

["Martin v. Löwis"]

meyer at mesw.de wrote:
> thanks for the tip, I wasn't fully aware of that. OTOH, though GCC
> might be a theoretical alternative, it isn't a practical one for many
> situations:
> 
> * In a professional environment, it opens up another can of potential
> problems, where one would rather like to stay with one single
> compiler/build system.

That's a theoretic argument to me: Can you name four or five problems
out of that can?

> * I suppose Python's distutils have to be tweaked to work with GCC

No, it should work out of the box. If it doesn't: contributions are
welcome.

> * The Makefiles/build system will need to be changed to work with the
> GCC toolchain

If you are using distutils, you don't need a Makefile, and the
setup.py won't have to be tweaked. If you are not using distutils,
but, say, nmake already, then you will already have an earlier version
of the compiler - how else did you create the nmake files in the first
place?

> * The different semantics of GCC and Microsoft C often need rewriting
> some of the code

For C code, the semantic differences are really minor. You almost
never need any rewriting when moving from MS compilable code to
gcc; if you do, it is fairly straight forward to formulate the
code so that it compiles with both compilers

> * There is no support for MFC/ATL in GCC

That's true.

> * The code created by the Windows GCC is not as good as the one created
> by the Microsoft compiler

I never found that relevant for practical purposes. While it is possible
to create hand-crafted programs that show a difference, real-world
programs are often more limited by the performance of the OS (disk
IO, database IO, GUI) than raw processor speed.

Still, if you really cannot use gcc, then go ahead and compile with
VS 2005. Just make sure you link with mscvr71.dll. If you absolutely
need that to work, you will find a way to make it work.

Regards,
Martin