boost::python, returning new PyObject references

[Guido van Rossum]

> > What's the "Object Protocol"?  Are we still talking about Python here?
> 
> http://www.python.org/doc/current/api/object.html

Fair enough.  I don't write the docs. :-)

> > By asking you to unask the question.  Python doesn't have a
> > classification like this,
> 
> http://www.python.org/doc/current/api/abstract.html seems to indicate
> otherwise.

These protocols are just convenient groupings for sets of operations.

> Also PyMapping_Check et. al, and such functions in python itself
> as callable(), isinstance(), and issubclass(), though admittedly the lack of
> functions like issequence() or ismapping() seems to remove the emphasis on
> this idea.

isinstance() and issubclass() don't prove anything -- they make tests
on the class hierarchy available for those that find such tests
convenient.  (Read their docs -- they take a second argument that's a
class.)

callable() is a test for a *single* operation, "function call".

The others are left out on purpose, except there are some remnants
(e.g. in the operator module) where I couldn't curtail the enthusiasm
of others. :-)

> I guess there's no point in arguing with GVR about the nature of
> Python.  FWIW, though, at least a few of us independently drew the
> same conclusions about the existence and possible importance of
> categories based on the documentation and the facilities provided by
> the language.

Maybe the docs need to be clarified.  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.

> > 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.
> 
> I knew that; since the boundaries are so malleable I was trying to
> capture your mental model. Maybe your mental model is actually "one
> big soup of types with no structure, even informally". In that case,
> we may have to rethink the idea of classification altogether.

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.

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