RE: PROPOSAL: A Generic Python Object Interface for Python C Modules

Hammond, Mark (MHammond@jm.cmutual.com.au)
Tue, 28 Feb 95 09:25:00 PST

> PROPOSAL: A Generic Python Object Interface for Python C Modules

Before I start, this looks very good, and very worthwhile. Some comments:

> if(is_tupleobject(o))
> e=gettupleitem(o,i)
> else if(is_listitem(o))
> e=getlistitem(o,i)
Ahhh - it will be great to remove this sort of code!

>
> The Python C object interface will provide four protocols: object,
> numeric, sequence, and mapping. Each protocol consists of a
snip
>
> Number Protocol:
...
> 3
> PyObject *PyNumber_Add(PyObject *o1, PyObject *o2)
>
> Returns the result of adding o1 and o2, or null on failure.
> This is the equivalent of the Python expression: o1+o2.

[Please excuse my C++ background :-)]

Im not sure that "Number Protocol" is a good name. PyNumber_Add should work
for any objects that the equivilent "o1+o2" works for. This gets important
as Python allows operator overloads.

Take, for example, C++'s preference of overloading lshift for IOStreams.
For example, if the following code is valid in (a future) Python (via
operator overloading):
sys.stdout << "Hello"
Then I feel there should be a way of saying:
PyObject *PyWhatver_Lshift( obSysStdOut, obStrHello );

Maybe a better name than "Number" would be "Operator" - eg:
PyObject *PyOperator_Name(ob1, ob2);
implying that the ob1.operatorName(ob2) will be invoked, regardless of the
types.

This would mean that:
> int PyNumber_Check(PyObject *o)
>
> Returns 1 if the object, o, provides numeric protocols, and
> false otherwise.
>
> This function always succeeds.
Is not really valid any more. An object may override "operator +", but not
"operator -", meaning that PyOperator_Add() would succeed, but
PyOperator_Subtract would fail.

Additionally, you say:
> The Python C object interface will provide four protocols: object,
> numeric, sequence, and mapping. Each protocol consists of a
> collection of related operations. If an operation that is not
> provided by a particular type is invoked, then a standard exception,
> NotImplementedError is raised with a operation name as an argument.
I cant see any point in this new error. I would prefer to maintain
consistency with Python itself.
Almost every example has the note "This is the equivalent of the Python
expression: ???". IMHO, the same error should be returned to the C
interface, as would be printed by the Python interpreter if the operation as
described was attempted within Python.

Eg, in the example above, presumably attempting to call the
"PyOperator_Add() function would return an AttributeError is the operation
was not defined.

I think this proposal is excellent, and the cleanup of the memory management
is also a bonus. Good stuff!

Regards,

Mark (MHammond@cmutual.com.au)