On Mon, Aug 30, 2010 at 6:43 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Mon, 30 Aug 2010 07:31:34 +1000 > Nick Coghlan <ncogh...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
