Python 2.6, 2.7, and 3.1 are all built with that release (i.e. 2008).
Because of another long tradition, Python extension modules must be
built with the same compiler version (more specifically, CRT version) as
Python itself. So to build extension modules for any of these releases,
you need to have a copy of VS 2008 or VS 2008 Express.
If you are planning to build Python extension modules in the next five
years, I recommend that you obtain a copy of VS Express, just in case
Microsoft removes it from their servers. As mentioned, it's free of
charge. When downloading it for later use, it's probably best to get the
offline ISO image release, available from
http://www.microsoft.com/express/Downloads/#2008-All
Disclaimer: I'm not connected with Microsoft or its release process. Any
claim on future actions that Microsoft may take is purely hypothetical.
Regards,
Martin
Thanks for this idea.
Michel Claveau
> If you are planning to build Python extension modules in the next five
> years, I recommend that you obtain a copy of VS Express, just in case
> Microsoft removes it from their servers.
Thanks for the idea Martin. However I've changed the post title a little because at
first I skipped this post because I thought that it was product spam ;-)
Irmen de Jong.
> Python 2.6, 2.7, and 3.1 are all built with that release (i.e. 2008).
> Because of another long tradition, Python extension modules must be
> built with the same compiler version (more specifically, CRT version) as
> Python itself. So to build extension modules for any of these releases,
> you need to have a copy of VS 2008 or VS 2008 Express.
Is it too late for Python 2.7 to update to using Visual Studio 2010?
It is going to be much easier for people to find and install the current
version of VS than the previous. There is still more than 2 months left
before 2.7 is planned to be released.
Neil
If only Python could do that, just pull the plug out and not offer
archaic versions for download. If that has been the tradition all along
probably people would be rushing to download Python 3 when it's hot and
porting all their code in fear of using a no longer supported compiler
instead of complaining how they're still using python 1.5 and now
there's python 3.0 breaking compatibility.
I guess I'm glad that whatever python program I wrote now would still be
easily runnable with no change in twenty years or so.
Is it sufficient to download just the setup program vcsetup.exe or do people
need to obtain the offline iso which presumably has the full content in it.
--
Robin Becker
As I remember it when installing VS Excpress a few years back, the thin
installer is just a download manager so you should get the full
installer if you want to insure yourself from Microsoft pulling the plug
out.
Most extensions will work okay when compiled with mingw32. However, mingw32 is
still based on MSVCRT6.dll as its C runtime. You would get errors whenever a
FILE* pointer crosses over the boundary. distutils will tell it to link with the
CRT that Python is currently built with, but some of the headers aren't up to
date for that CRT, so some C++ extensions will not work (a command C++ operation
triggers a table lookup in a static table defined in the CRT, but it differs in
size between versions).
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
It's fine if your package supports being compiled with Mingw32. A lot of
source code can't be compiled this way, either because gcc doesn't
support some of the MS extensions (in particular wrt. COM), or because
Mingw32 doesn't provide the header files (in particular wrt. C++), or
because linking with a library is necessary that uses the MSVC mangling,
not the g++ one (again, for C++).
Code written in Cython should work fine with gcc indeed.
> It seems to
> work fine. What is the basis of this claim that you need MS Visual
> Studio to do it?
Just try building Mark Hammond's Win32 extensions or PythonWin with
Mingw32 to see for yourself.
Regards,
Martin
Most definitely. They have switched *again* the way they distribute the
CRT, so major changes to packaging and distutils would be required.
> It is going to be much easier for people to find and install the current
> version of VS than the previous. There is still more than 2 months left
> before 2.7 is planned to be released.
It took us about two years to accommodate the CRT change. This time, it
will be easier, but nowhere near 2 months. I'm skeptical that the switch
to VS 2010 will be ready for 3.2.
Regards,
Martin
> Brian Blais wrote:
>
>> On Apr 12, 2010, at 16:36 , Martin v. Loewis is wrote:
>>
>>> If you are planning to build Python extension modules in the next five
>>> years, I recommend that you obtain a copy of VS Express
>>
>> Am I missing something here? I have heard this before, but I have built
>> extension modules many times under windows (using Cython) and never once
>> used a MS product.
>
> It's fine if your package supports being compiled with Mingw32. A lot of
> source code can't be compiled this way, either because gcc doesn't
> support some of the MS extensions (in particular wrt. COM) ...
But then such code will not be portable to anything but Windows.
> ... or because Mingw32 doesn't provide the header files (in particular
> wrt. C++), or because linking with a library is necessary that uses the
> MSVC mangling, not the g++ one (again, for C++).
Again, that would be code that’s not portable off Windows.
> ... so you should get the full installer if you want to insure yourself
> from Microsoft pulling the plug out.
I wonder how many Windows users will be able to figure that out...
>> ... or because Mingw32 doesn't provide the header files (in particular
>> wrt. C++), or because linking with a library is necessary that uses the
>> MSVC mangling, not the g++ one (again, for C++).
>
> Again, that would be code that’s not portable off Windows.
Not really, part of the issue is that mingw uses ancient gcc (3.x
series), and g++ 3.x has poor C++ support compared to MSVC (or gcc
4.x).
There is also the issue that gcc debugging symbols are totally
incompatible with MSVC, so you cannot debug things from anything but
gdb. Gcc for win64 is also not that stable yet - when porting numpy
and scipy on windows 64, I got numerous issues with it.
None of this has anything to do with portability.
cheers,
David
Probably (although it *is* possible to write code that compiles on
Windows only with MSVC, and compiles fine on Unix with gcc).
However, I wonder what you are trying to imply: that the code is useless
if its not portable? That would be wrong: the code may well be very
useful, and enjoy great popularity, even if it runs on Windows only.
Regards,
Martin
Probably (although it *is* possible to write code that compiles on
Most of such code is for Windows-specific services anyways.
... the 2GB ISO was quicker to download than it was to install - not
even counting the several reboots required.
Since when do you need to REBOOT just to install a development environment?
Sure beats having to recompile a kernel to support 3rd party audio
drivers. But YMMV.
Although I agree, moving away from VS would be nice. Since Unladen
Swallow will eventually be merged with Python, will the dev team
consider trying out Clang as an alternative to VS?
What would Unladen Swallow brings that would allow the development of
CPython to move away from VS? Isn't Unladen Swallow's goal is only to
speed up CPython. Do you mean PyPy?
Never have needed to compile Python on Windows, but some modules only
support older versions (e.g. 2.4 or 2.5), which is irksome. So it's a
good idea to have stuff setup for building extension modules by hand.
I'm curious to know exactly the differences between the c/c++ compilers
you get with various versions of VS and those you get with the (command
line only) Windows SDK (formerly called the platform SDK).
The windows sdk is a free download. Is the compiler you get the same as
the one you get with the full paid version of VS? This web page seems
to suggest it might be
<http://msdn.microsoft.com/en-us/windows/bb980924.aspx>
The primary "difference" is the CRT version that it ships with. Also,
one difference is whether it ships with a compiler at all. For a long
time, the SDK didn't include a compiler at all. Then, for several years,
it included an Itanium compiler and an AMD64 compiler, but no x86
compiler. Now it does, and I don't know what CRT version it links with
(at some point, the SDK would link with crtdll.dll, then msvcrt.dll,
but it's some other version now).
In any case, AFAIK, the SDK binaries will be linked with one specific
version of the CRT, which may or may not be the same as the one used in
one specific version of Visual Studio.
HTH,
Martin
If one relies on the Express Editions, you're basically limited to the
X86 compiler and missing certain things (biggest gripe: profiling). I
believe that the Windows Driver Development Kit (DDK) has X86, AMD64,
and IA64 compilers included. Last time that I looked, it appeared to
be a build similar to Visual C++ 2008 but I didn't have enough spare
time to inspect it's license and general suitability for applications
development.
> Sure beats having to recompile a kernel to support 3rd party audio
> drivers.
Which is a less fraught process than {B7C0D3A0-F949-44AD-ACE5-FB845B8C1EB7}
ing Registry edits, don’t you thin? You never know what
{46E68550-70E4-4CAE-9C69-5C73CE2893CA} it might be having on your machine,
to the point where you are no longer able to {362CAB02-8A1F-4337-
A441-8149848BD319} it.