[Python-Dev] API bloat

Antoine Pitrou solipsis at pitrou.net
Wed Feb 9 11:56:00 CET 2011


On Wed, 09 Feb 2011 10:37:11 +0000
Mark Shannon <marks at dcs.gla.ac.uk> wrote:
> > 
> > Why redundant?
> 
> Because they are all attribute getter and setters. For example:
> 
> PyUnicodeDecodeError_GetStart(exc, x) <=>
> PyObject_GetAttr(exc, "start", x)
> 
> This sort of redundancy seems sensible for list, tuple and such.
> It just seems like bloat for classes like UnicodeDecodeError.

It's not exactly the same thing, still. PyObject_GetAttr()
will do a full blown attribute access, while I guess (I didn't check) 
PyUnicodeDecodeError_GetStart() accesses the C struct member directly.

Also, the latter gives you a Py_ssize_t object, which relieves you from
having to do a conversion explicitly.

I do agree that it doesn't seem widely used, according to Google Code
Search :)

> >> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
> >> Should this be in the public API?
> > 
> > While this question is valid, it *should* have been asked 8 years ago, when
> > the functions were actually added.
> 
> The functions may have been add to CPython 8 years ago, but they were
> added to the API when they appeared in the docs, between 3.1 and 3.1.3.
> 
> How is the API defined, if not by the documentation?
> The header files do not specify what is API and what is implementation
> specific.

True. But if they were added to the documentation, it's certainly
because they were *intended* to be part of the API from the start.
(after all, core CPython code can just access the C struct fields
directly rather than go through a function call)

Take it as acknowledging that it has *always* been part of the intended
API.

These days, we try to follow a stricter naming convention: when we want
an API to remain explicitly private, we often prefix it with an
underscore. But that has not been the case in the past, I admit.

> > Any changes in API are definitely forbidden before 3.2.
> 
> If that is the case then the API, as defined by
> http://docs.python.org/py3k/c-api/index.html
> should be same for 3.2 as for 3.1, plus a few functions,
> that are explicitly marked as "New in version 3.2".
> 
> Unfortunately, that is not currently the case.

How so? Can you give an example?

Regards

Antoine.




More information about the Python-Dev mailing list