[Python-Dev] PySet API
gmccaughan at synaptics-uk.com
Tue Mar 28 16:07:17 CEST 2006
> We're clearly going in circles here, and it's obvious we're not going to
> The fact that PySet_Next() can be used incorrectly is no reason not to
> include it.
For what it's worth, I think Raymond is absolutely on crack here.
 Not necessarily very much. There is none of my code in Python,
so far as I know.
* Simple API:
The complexity of an API is not determined by the number of methods
in it but by the variety of different things you can ask it to do,
and it's not any simpler to have
than to have
API complexity is measured in brain cells, not in methods.
* Ease of making mistakes:
The Python API is absolutely stuffed with places where you can go wrong
by forgetting about subtle refcounting issues. Sure, it's nice to minimize
that pain, but it's never going to be possible to write much code that
uses the C API without being alert to such issues.
(Incidentally, the more things you have that can only be done by
invoking PyObject_CallMethod, the more places you have where you
have to assume that arbitrary Python code may have been called and
that reference counts may have changed behind your back.)
* Duck typing:
Yup, supporting duck typing is good. That's why we have an abstract API.
There are concrete APIs for all sorts of particular kinds of Python object;
it seems pretty clear to me that this isn't a mistake, and that sets should
be one such type. Clients get to choose how to trade off the benefits in
efficiency, conciseness and clarity from using the concrete API against
the benefits in generality from using the abstract one.
And when PySet_Add is the obvious way to add items to sets, how much
C code using sets is likely to work with things that merely walk and
quack like sets, anyway?
Anyone measured this? The mere fact that the overhead of (say) emptying
a set using PyObject_CallMethod is O(1) doesn't mean it's insignificant.
For many applications the size of your sets is O(1) too. (Often with
quite a small implicit constant, too.)
More information about the Python-Dev