boost::python, returning new PyObject references

[David Abrahams]

----- Original Message -----
From: "Guido van Rossum" <guido at python.org>

> > From: "Arnaldur Gylfason" <arnaldur at decode.is>
> >
> > > > What is the PyObject_* interface? Is
> > > >     int PyMapping_Size(PyObject *o)
> > > > included in it, for example? What are the criteria which decide
what's
> > > > included?
> > >
> > > I am referring to the Object Protocol in the Abstract Objects Layer in
the
> > > Python/C API, chapter 6.1.
> > > PyMapping_Size would not be included (Mapping Protocol chapter 6.4).
> > > I put PyObject_GetItem and SetItem into the mapping
interface/protocol.
> > > The Mapping protocol adds PyMapping_GetItemString for key strings.
> >
> > Hmm, I see.
> >
> > I had a conversation with Guido some time ago about the Python concept
> > model. He said that they had been having trouble formalizing it, and
this
> > may be evidence of it. I guess the question is, which of the concepts
> > Number,Mapping,Sequence,Object,Buffer... logically subsume the others?
Are
> > they actually orthogonal (in which case, a Number is not neccessarily an
> > Object)? A list is surely a sequence, but it also supports some
attributes,
> > so that makes it an Object as well? Maybe it makes sense not to
second-guess
> > the way that Python has delineated these things, despite the fact that
my
> > instinct tells me that everything is an Object.
>
> I don't think I follow this -- maybe because you're imposing your own
> teminology?

I don't think so. We're at least trying to follow the Python terminology as
given in chapter 6 of the Python/C API reference.

> *Everything* in Python is an object, period.

What does "is-a" mean in this case? It certainly doesn't mean that
everything supports all operations of the Object Protocol. I expect this
calls PyObject_GetItem:

>>> 1[2]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsubscriptable object

I would expect a KeyError or IndexError if the protocol were "supported",
but maybe there's a more appropriate defintion for "supported" in this case.
If everything "is-a" Object, then we can ask, is a List a Number? It
supports some of the operations in the number protocol, after all (e.g. +=).
How does one decide the answer to that question in general?

> Number,
> mapping, sequence are mostly orthogonal, except that they overload
> some of the same operators (e.g. + and * apply to numbers and
> sequences, getitem/setitem apply to sequences and mappings).

Yes, that's understood.

> > [Guido: the context for this discussion is that Arnaldur is reworking
the
> > object wrapping interface in Boost.Python which supplies a syntax
similar to
> > that used by Python for operating on generic Python objects, with
classes to
> > represent Number,Mapping,List,String,etc.... We're trying to understand
what
> > the inheritance relationships should be, under the assumption that an
object
> > wrapper can only be constructed around a PyObject* if the PyObject*
meets
> > the appropriate concept requirements, and if class A is derived from
class
> > B, one can assume that an A supplies all the requirements of B].
> >
> > -Dave
>
> Since Python doesn't base its categorization on inheritance, I'm not
> sure how I can help.

Inheritance is only relevant in the sense that C++ supplies implicit
derived->base conversions. We want to structure things so that more-general
protocols are represented by bases of the classes which represent the
specific protocols including the more-general ones. It sounds like on the
basis of what you've said, that all the other classes should be derived from
the one for Object, but it isn't clear exactly how the rest of this universe
should be structured. The fact that it seems there's no requirement in
Python that all elements of a Protocol are implemented, and that the
response to unimplemented operations is very close to that for operations
which are not called correctly (an exception) makes it hard to decide what's
what. At this point, I'm resorting to the vision of the designer for some
insight, since I can't find any empirical way to make the determination.

-Dave