[Python-3000] Python 3.0a2 release

[Amaury Forgeot d'Arc]

Paul Moore wrote:
> On 20/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> > Are we going to drop VS 2003 after the 3.0a2 release and use VS 2008 as
> > the default compiler once it has been released, too?
> >
> > In other words: Do we want to support outdated compilers for legacy
> > reasons or can we stick to 2005 as the minimum version? The directory
> > and registry layouts of 8.0 and 9.0 are almost identical. My
> > modifications may work for both compilers.
>
> One key question which will need to be addressed - at the moment, it
> is possible to build Python extensions with mingw, and I believe a lot
> of people do this (I certainly do!) If we move to VS 2005 or VS 2008,
> then this may not be possible (there is specific mingw support for the
> msvcr71 CRT DLL, both in distutils, and in mingw). As things currently
> stand, mingw doesn't seem to ship with even msvcr80 libraries.
>
> If allowing non-core developers to build Windows binaries without
> needing a paid-for compiler is important, then it will be necessary to
> make sure that building extensions works with the free versions of VS
> (preferably without the huge pain of "install VS express, install SDK,
> grab the following extra bits, etc etc" that seems to be the case now
> - at the very least, clear and supported instructions on what needs to
> be installed should be included).
>
> I would strongly advise against going back to the days where a paid MS
> compiler was the only way to build extensions for Windows.
>
> I will help in addressing this issue, but I am limited in my ability
> to do so, as I cannot build Python itself (that *does* need full VS
> 2005/2008, as I understand it) and so all I have to go with is the
> snapshot builds (which use VS 2003, and so don't help...)

That is what I thought 10 minutes ago.
But I just did this experiment:
I started from an "official" python25 distribution, with "official"
distribution of third-party packages. They are compiled with VC2003.
Then I copied the wxPython directory into my own workspace, which I
compile with VC2005 (the only compiler I have here)

And it works: the demo application runs just fine, I did not see any
problem so far.
I checked that both C runtime libraries are loaded in memory:
python25.dll uses msvcr80.dll, and _code.pyd uses msvcr71.dll.

It seems that the restriction that forces you to use the same compiler
for core python and extension modules does not stand.

Of course, you cannot do everything: for example, FILE* pointers
cannot be exchanged between different instances of the C runtime.

Off the top of my head, here are the restrictions such a module would face:

- PyMem_MALLOC and PyMem_FREE are macros to the malloc() and free()
functions of the current source being compiled. So an extension module
must free itself the memory it has allocated.
- Same thing for tp_alloc and tp_dealloc, which must match.
- Do not use API functions using the FILE* type. For example,
PyParser_ParseFile, PyObject_Print, the tp_print slot (which is
removed in py3k btw).
- Do not exchange file descriptors (but sockets are OK)
- Be sure to include "python.h" with the correct alignment options
[#pragma pack(8)]
- Do not use stdin, stdout and stderr if you want correct buffering.
- Do not play with signals, or only through the python API functions.
- The locale functions may behave differently.

It seems to me that these conditions are not difficult to respect.
Many extension modules already fulfill them.

Am I missing something? Should we lift the restrictions we impose on
compilers of extension modules? Can we carefully design the Python API
to accept different compilers/runtime?

-- 
Amaury Forgeot d'Arc