[Python-Dev] PEP 384 status

David Cournapeau cournape at gmail.com
Mon Aug 30 05:16:52 CEST 2010


On Mon, Aug 30, 2010 at 6:43 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 30 Aug 2010 07:31:34 +1000
> Nick Coghlan <ncoghlan at 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


More information about the Python-Dev mailing list