boost::python, returning new PyObject references
david.abrahams at rcn.com
Sun Jan 6 20:56:59 CET 2002
----- 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
> > > > included?
> > >
> > > I am referring to the Object Protocol in the Abstract Objects Layer in
> > > 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
> > > 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
> > may be evidence of it. I guess the question is, which of the concepts
> > Number,Mapping,Sequence,Object,Buffer... logically subsume the others?
> > they actually orthogonal (in which case, a Number is not neccessarily an
> > Object)? A list is surely a sequence, but it also supports some
> > so that makes it an Object as well? Maybe it makes sense not to
> > the way that Python has delineated these things, despite the fact that
> > instinct tells me that everything is an Object.
> I don't think I follow this -- maybe because you're imposing your own
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
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?
> 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
> > object wrapping interface in Boost.Python which supplies a syntax
> > that used by Python for operating on generic Python objects, with
> > represent Number,Mapping,List,String,etc.... We're trying to understand
> > the inheritance relationships should be, under the assumption that an
> > wrapper can only be constructed around a PyObject* if the PyObject*
> > the appropriate concept requirements, and if class A is derived from
> > 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.
More information about the Cplusplus-sig