From: "Christian Tismer" <tismer@tismer.com>
Christian Tismer wrote: ...
A small addition:
I'm not really understanding what you're proposing here.
I am trying to extend the new-style classes that includes ctypes, somehow.
You could look at ctypes as implementing 'typed slots' with C-compatible layout. ...
This is maybe also something that ctypes already does. The B *class* above knows all about this C structure
struct B { char x; int y; long long z; };
Ok, what I was thinking of was to use ctypes or something similar to describe structs, and then to build all objects on top of this. This means that details like type pointer and reference counts go into this definiton as well, together with their behavior, and we are able to try different approaches as well.
Probably this idea is trivial, and you though this way all the time.
maybe I'm stating the obvious, I think all of this is useful and necessary to get a running/working Python in Python and for targetting C-like/machine-code-level backends. OTOH I think a higher level of abstraction is necessary to targert more general backends. E.g. at such level what is relevant - about an integer object is its value and that's its type is integer - semantics of non-control-flow and binding byte codes are important e.g. : def binary_add(o1,o2): ... but the fact that there's a bytecode eval loop is much less so. (From my experience) a relevant issue is how to abstract over the PyTypeObject struct and the interpreter internal inheritance and lookup mechanisms (which do not correspond so directly to the language level semantics). regards.