boost::python, returning new PyObject references

[David Abrahams]

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

> The concepts are fine to explain things.  The break down when you try
> to pin down exact definitions.

What are they good for explaining?

> > > My mental model has some types that are clearly sequences, mappings,
> > > etc., and some that are clearly not, but no exact rule to always
> > > decide what something is.  This has changed; ten years ago, I *did*
> > > think these were recognizable categories, but the language and my
> > > thinking have evolved away from this.
> >
> > In that case, I'll suggest again that you consider heading back the
> > way you came ;-). Some clear and officially sanctioned Concept
> > definitions would be very useful to writers of generic Python
> > code. Note that while the ability to introspect about Concepts is
> > nice, it's not the most important reason to define them**. The
> > reason you want concepts is so that writers of generic code can
> > specify the contract with their clients.
>
> 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.

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

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