boost::python, returning new PyObject references

[Guido van Rossum]

> > Maybe the docs need to be clarified.
> 
> Probably. Note also that Paul Dubois seems to have made similar inferences
> from looking at the design of CXX. About 1/4 of the way down the page at
> http://cxx.sourceforge.net/ there is a refinement hierarchy for the CXX
> object wrappers.

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

> > You cannot write a function that decides Sequence-ness of an
> > arbitrary object, you can only write something that recognizes
> > clear hits and clear misses correctly -- but there's a gray area
> > where the proper approach is to test for the existence of a
> > specific operation.  Fortunately, starting in 2.2, you can check
> > whether e.g. __getitem__ exists and that will give you the right
> > answer for classes as well as for built-in types -- although 3rd
> > party extensions may still be incompletely introspectable.
> 
> Only in pure python, right? Extension writers can still look at the
> slots to see what operations may be supported. A malicious author
> who fills in slots with functions that always raise exceptions is
> doing something that doesn't even play well with the native Python
> interpreter code anyway, IIRC (I know, descriptors are an exception
> to this rule, but they're new).

Correct.

> > 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.  You only get in
trouble when you mistakenly try to map them to a class hierarchy.

> It isn't a disaster if you pick the "wrong" definition, e.g. for
> Sequence.  If you decide that a Sequence implements __len__, and
> someone wants to write a generic function which depends on the rest
> of the Sequence requirements but not __len__, she has two choices:
> 
> 1. Ignore this difference and document that their function requires a
> Sequence parameter
> 2. Make up her own Concept definition which precisely describes the
> requirements imposed by her function
> 
> 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.

> In any case, it seems as though Arnaldur and I have a choice. We can:
> 
> 1. Ignore the possibility of Concepts altogether and implement a single
> generalized object interface with all capabilities.
> 
> 2. Acknowledge that Concepts would be useful, but the ones that the Python
> docs seem to imply are not really intentional. They seem to have the right
> names, but we'd need to change them and probably carve them up a bit, and
> that would only cause confusion, so again we throw up our hands.
> 
> 3. Work out a set of concept definitions that make sense, and carefully
> document them so that people are aware that "Sequence" might mean something
> different when we say it than when the Python docs say it. Then implement
> C++ classes to represent those concepts.
> 
> I'm in favor of #3, but open to others.
> Opinions, anyone?

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

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