>> 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 :-)]
I have one too. Also Smalltalk.
> 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.
My proposal is based on the current Python type system which expects
most operator overloading to be done for things that behave generally
like numbers. My proposal is also based on the underlying mechanism
Python uses to manage this information. Perhaps this exposes too much
of the underlying Python implementation.
I personally would be perfectly happy to make these part of the Object
protocol, or to make them part of an Operator protocol. If we do
this, however, I would tend to want remove PySequence_Concat and
PySequence_Repeat, treating them as special cases of PyOperator_Add
and PyOperator_Multiple. This is really more consistent with the
interpreter.
Guido, What are your thoughts?
> 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.
Given the above remarks, I could perhaps see dropping PyNumber_Check,
however, I would *not* want to drop PySequence_Check or
PyMapping_Check as these are used by applications to decide how to
treat objects. For example, I have a number of modules that take
objects as arguments and make decisions based on whether objects are
"scaler" or are "collections". I suppose that there could be
applications that want to distinguish between numeric and non-numeric
scalers.
It is, in general, useful to have tools to test whether objects
conform to broad protocols. In Smalltalk, this is often done with
expressions like:
someObject isNumber
or
someObject isKindOf: Integer
(The second example really tests something else, but it is useually
close enough.)
Given Python's type system, it certainly seems reasonable to have
standard ways of testing for strings, numbers, sequences,
mappings, and callable objects.
> 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.
Yes.
> 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.
Yes.
> Eg, in the example above, presumably attempting to call the
> "PyOperator_Add() function would return an AttributeError is the operation
> was not defined.
You are right. NotImplementedError is not needed. AttributeError fits
the bill.
Thanks for the comments.
--
-- Jim Fulton jfulton@mailqvarsa.er.usgs.gov (703) 648-5622
U.S. Geological Survey, Reston VA 22092
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.