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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4