RetroSearch Browse

Fri Feb 11 10:29:50 CET 2011 · https://mail.python.org/pipermail/python-dev/2011-February/108004.html

Nick Coghlan wrote:
> On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon <marks at dcs.gla.ac.uk> wrote:
>> Antoine Pitrou wrote:
>>>> Please, don't just document all these.
>>>> Don't add them to the API, unless they are really needed.
>>> We only add functions when they are actually needed (by us, usually).
>> If only you (I presume you mean the CPython devs) need them,
>> why put them in the API.
>> That underscore prefix saves a lot of trouble in the long run ;)
> 
> Keep in mind that you're asking us to change our audience here. When
> we modify the C API, we have precisely *three* audiences in mind:
> 
> 1. CPython developers
> 2. authors of CPython extensions
> 3. developers embedding a CPython interpreter (or interpreters) into
> their application

This makes me wonder who `owns' the API.
Is the CPython developers, the Python community as a whole, the PSF?
(Another one for Python-ideas)

> 
> So if we find something that makes life easier for us in group 1, our
> natural inclination is to make it available to the people in groups 2
> and 3 as well, rather than selfishly reserving it for ourselves. We
> will also take aesthetics and obvious symmetries into account when
> providing convenience functions (as in the case of
> PySys_FormatStdout). It's only when we consider something to be an
> ugly hack, or have some other reason to think we may want to change it
> in the future, that we opt to make it a private implementation detail.
> 
> The audience consisting of "authors of other implementations trying to
> mimic the CPython C API" has never even been on the radar. That's
> quite a significant philosophical shift, so coming in and asking us to
> apply it retroactively to a release in its RC phase comes across as
> being *very* presumptuous.

Sorry to leave it the RC stage,
I just didn't pick up the changes until now.
Don't forget that `other implementations' include future versions of 
CPython.

> 
> Now that the issue has been brought up, it can certainly be taken into
> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is
> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft
> that is a legacy of CPython's long history of development when it was
> the *only* viable Python implementation) may also be worth exploring.

Absolutely. I intend to do just that.

> But no, at this late stage nothing significant is going to be done in
> the context of 3.2, except perhaps describing the C API changes in
> more detail in the What's New document (whether or not that happens is
> up to Raymond - the C API is of very little interest to most Python
> users, who will either use pre-existing C extensions, or else use
> something like ctypes, Cython, Pyrex, Boost or SWIG to deal with the
> details of the C/Python boundary).

I do realise that its rather late in the release process,
so I'll leave it that.

Thanks,
Mark.

> 
> Cheers,
> Nick.
> 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-February/108004.html below:

[Python-Dev] API bloat