[Python-3000] Python 3.0a2 release

["Martin v. Löwis"]

> 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.

I wouldn't call that "it works", if it can actually crash.

The real constraint, of course, is "it works if you don't do any
of the things that don't work, but we can't give an exhaustive,
easy-to-verify list of the things that don't work".

> 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.

Right. Many modules also would crash, and have crashed in the past.

People who understand the rules may break them (or bend them), of
course.

> 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?

What you are missing is that your above list
a) may not be complete, and
b) is difficult to verify for somebody building an extension module
   (whose code he might never look at)

Not sure what you mean by "lift the restrictions" - they have
never really existed, and have been lifted in Python 2.5.
(More precisely - you could always build extensions with
any compiler of your choice that is capable of creating DLLs,
and if you use distutils, you can use any compiler in 2.5 with
proper setup)

Regards,
Martin