[Python-Dev] API bloat

[Nick Coghlan]

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

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.

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.
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).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia