On Mon, Aug 30, 2010 at 7:43 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Mon, 30 Aug 2010 07:31:34 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
Since part of the point of PEP 384 is to support multiple versions of the C runtime in a single process, [...]
I think that's quite a maximalist goal. The point of PEP 384 should be to define a standard API for Python, (hopefully) spanning multiple versions. Whether the API effectively guarantees a standard ABI can only depend on whether the system itself hasn't changed its own conventions (including, for example, function call conventions, or the binary representation of standard C types).
FILE* is very different from the other things you mention. Function call conventions and binary representations are defined in the C standard. FILE*, on the other hand, is explicitly called out as an opaque reference completely under the control of the specific C runtime implementation. Since the Linkage section of PEP 384 specifically states the availability of a generic "python3.dll" that dynamically redirects to the relevant "python3y.dll" to allow an extension module to run against any 3.2 or later Python version as a goal of the PEP, I would say that allowing mixing of C runtimes is definitely one of the PEP's goals. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia