On Mon, Aug 30, 2010 at 6: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).
In other words, PEP 384 should only care to stabilize the ABI as long as the underlying system doesn't change. It sounds a bit foolish for us to try to hide potential unstabilities in the underlying platform. And it's equally foolish to try to forbid people from using well-known system facilities such as FILE* or (worse) errno.
So, perhaps the C API docs can simply mention the caveat of using FILE* (and perhaps errno, if there's a problem there as well) for C extensions under Windows. C extension writers are (usually) consenting adults, for all.
This significantly decrease the value of such an API, to the point of making it useless on windows, since historically different python versions are built with different runtimes. And I would think that windows is the platform where PEP 384 would be the most useful - at least it would for numpy/scipy, where those runtimes issues have bitten us several times (and are painful to debug, especially when you don't know windows so well). cheers, David