boost::python, returning new PyObject references

[Guido van Rossum]

I have to end my contributions to this discussion -- I simply can't
find the time to keep it up.  Here's one last installment.

> > The concepts are fine to explain things.  The break down when you try
> > to pin down exact definitions.
> 
> What are they good for explaining?

In the tutorial, we use the concept of sequence to explain the
similarity between strings, tuples and lists, for example, and the
concept of numbers to explain mixed-mode numerical operations.

> > IMO the concepts are sufficiently well-defined.
> 
> Sufficient for what purpose, though? From my POV, they're well-defined
> enough to lead people like Paul Dubois and me astray, without being
> sufficiently well-defined to be useful for anything. AFAICT, they're not
> defined at all, but rather hinted at in various ways.

The source of the problem seems to be with attempts to impose the C++
view of the world onto Python (or the other way around).  At the
boundaries of languages that are so different, you are going to find
things that don't map cleanly, no matter how you try it.

> > You only get in
> > trouble when you mistakenly try to map them to a class hierarchy.
> 
> I'm not sure that's the problem. Surely:
> * List is a refinement of Sequence
> * Sequence is a refinement of Object
> ??

But there is no base class Sequence.

> > > Of course, it's much better if you can try to delineate all of the
> > > useful gradations in a particular domain at once, so that the
> > > community doesn't end up with lots of different names for the same
> > > concept. You might provide Sequence and MeasurableSequence, for
> > > example.
> >
> > That's exactly the problem: there are too many sub-concepts.
> > E.g. sliceable sequence, mutable sequence, sliceable mutable sequence,
> > and so on.
> 
> Dividing it that way is clearly going to cause an explosion. However,
> granular concepts can be combined. It would make sense to say:
> 
> "x fulfills the requirements of Sequence, Sliceable, and Callable"
> 
> (for example). When defining Sequence, you can even add requirements that
> depend on other concepts. For example, if there's a separate way to
> determine the mutability of any type, you can require that if a Sequence is
> also Mutable, it must support setattr, for example. Also, not every
> allowable granule makes a useful concept, so for example there is no point
> in defining a concept around support for inplace ^= (numeric concepts would
> probably group related operations into concepts like AbelianGroup and
> Floating). I don't think it's an intractable problem, and I don't think a
> useful start needs to solve it completely (if that's even possible).
> 
> > I don't know enough of the other constraints on your system to be of
> > much help here.  I only note that in 2.2 I am moving away from making
> > the concepts concrete in the implementation.
> 
> That's as it should be, in some sense. Concepts are supposed to be abstract.
> It's just a quirk of the relationship between Python and C++ that allows us
> to think about representing them with classes.
> 
> > A type has exactly those
> > slots filled that it implements (and there's a complex mechanism that
> > sets or clears the tp_foo slot when a __foo__ method is added to the
> > class or removed from it.
> 
> Acknowledged.
> 
> Thanks for letting me harangue you about this,
> Dave

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