boost::python, returning new PyObject references

[Guido van Rossum]

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

What's the "Object Protocol"?  Are we still talking about Python here?

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

You're missing something here.  The TypeError is part of the defined
behavior: some objects "support" the abstract "getitem" operation and
others don't.  Not supporting "getitem" doesn't make them not an
object.

> 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?

By asking you to unask the question.  Python doesn't have a
classification like this, so there's no point in trying.  There's a
set of possible operations and each object type can decide which
subset of those it supports.  Certain subsets make the type smell more
numeric, others make it smell like a sequence, but there's no absolute
answer.  It's *possible* though unlikely to have a sequence that
doesn't support len(), for example.

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

I hope the above helps.

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