boost::python, returning new PyObject references

[Guido van Rossum]

> 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?  *Everything* in Python is an object, period.  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).

> [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.

--Guido van Rossum (home page: http://www.python.org/~guido/)