[C++-SIG] Python calling C++ issues

[skaller]

Geoffrey Furnish wrote:
> 
> I for one am losing track of the argument here.  Everything you say
> below about the mechanism that Python uses for finding and invoking
> functions of modules, is well known, and if you didn't read it
> anywhere first, can be directly observed from the Python C source.
> The part of your post which relates to a factual rendition of how
> things works in CPython today, is not in contention.

	Good.

> Your claim that this can all be handled with a single base class
> is--until you demonstrate it by posting ocde which works as you
> posit--at best understood to be an hypothesis. 

	Fine. It seems like a good hypothesis. I have built
some of the code. I know it can work, since I know the Python
object model reasonably well, and I know C++ backwards,
forwards, and inside out. :-)

> Several of us on this list, including myself, Paul, Barry, 
> and doubtless others, have worked
> out schemes largely similar to what you describe.

	What problems were encountered?

> I invite you to develop and post code which works as you claim can be
> done.  We would all love to see a tangible incarnation of the design
> ideas you espouse.  In other words, show us the beef.

	I have another more pressing project. What I can tell you
is that I did indeed begin construction of a standard C++ wrapper,
but I didn't bother to complete it because I found a better way to 
achieve my goals. What I'm saying is that there is a few days work
involved, and I won't gain anything out of it, because I'm not that
interested in extending CPython using C++ any more.

	I'm still on this mailing list because I am interested
in what others are doing and I'm willing to provide what assistance
I can. I can give a sketch of the required architecture.
I would be very interested in talking about some of the 
detail problems, such as the one I mentioned about subtables.

	But I have no comprehension of how it is not
completely obvious what path must be taken. You made a comment
something like: 'So now we can call the virtual len, what about
the non-virtual methods'.

	And my point is: that is an implementation detail
of the specific getattr hook a particular subclass of the abstract
base provides, and those details aren't relevant to writing
the C/C++ wrapper.

	It is quite true, that there are multiple ways to do this.
[That is, lookup attributes]

	But it can be done USING POLYMORPHISM. 
So it can be separated out, utterly and totally. 
Exactly as there is more than one way to determine the 'len'
of an object. It depends on the derived type, and the derived
type provides the answer by overriding the virtual len.

In other words, to the point where such
specific functions are dynamically loadable.
[This is the true test of correct abstraction: when you can dynamically
load a class, known ONLY by it's abstract base. Ignorance of 
any other structure is enforced by the very fact of dynamic loading:
it just isn't possible to call a method not in the abstract base,
even if you get the run-time type of the object, you don't know the 
static type.]

	Consider the 'len' function. Clearly, we need a
C++ class like:

	class Cpp_PyObject {
		virtual int len() const =0;
		..
	};

	How is this called? Well, the python
type struct has a pointer in it of type

	Cpp_PyObject *

and there is a single C wrapper function:

	int len (PyObject *object) {
		return ((C_Cpp_PyObject *) object)->len()
	}

which is in the 'len' slot in the CPython virtual table.
in this example, the C struct C_Cpp_Pyobject contains
a pointer to a Cpp_PyObject.