At 10:50 2003-01-19 -0800, Armin Rigo wrote:
[...]
Yes, I think that we should try to unify the idea of function object vs code object in Python with other similar ideas used internally in CPython. For example, built-in function objects have a pointer to a PyMethodDef structure --- we find again the distinction between the "callable front-end" object and the "implementation-description" structure.
Ideally, we should have only one all-purpose "function" object type, which holds things like argument names and default values, and any number of "implementation" object types, of which Python code objects would be one example, and PyMethodDef-like objects another. This would let us add other ways to implement functions, like Psyco-emitted machine code objects.
Sometimes I wonder whether I should raise the question in python-dev. It seems to me that it helps in various places, e.g. in the help() mecanism which currently cannot guess the argument list for built-in functions. Well, I cannot see how to make it 100% compatible with existing code...
ISTM there is a general concept of dynamic representation management (Python can give DRM a new meaning ;-) coming out of the mist. In C, type vs representation is almost 1:1 (i.e., type names identify memory layouts with bits and words etc), but with Python and psyco there are multiple ways of physically representing the same abstract entity. I'd like to push for separating the concepts of type and representation better in discussion. What I'm getting at is separating "representation-type" from "abstraction-type". E.g., a Python object pointer in C may implicitly encode an abstract tuple of (type, id, value) or class PyPtr: __slots__ = ['oType', 'oId', 'oValue'] and we can discuss separately how to pack the info of the abstraction into a 32-bit word with huffman tricks and addressing of type-implying allocation arenas etc., or whatever. But maybe there's another level. I'm wondering whether the most primitive object representation should have a slot for an indication of what kind of representation is being used. E.g., class Primo: __slots__ = [ 'abtraction_type', # might say integer, but not int vs long vs bignum 'entity_id', # identifies abstract instance being represented 'representation_type', # implies a representation_interpreter, maybe CPU 'representation_data' # suitable for representation_interpreter to find it ] In other words, multiple Primo instances with the same entity_id could be specifying multiple abstractly equivalent but concretely different representations of the same object, e.g., a particular integer being represented in various ways, maybe even as machine code to move a particular represention from one place to another. Entity_id might be encoded as a chain of pointers through sibling Primo instances representing the same abstract instance entity. I think there can also be representation_types that are partial representations, something like a database view, or a C++ pointer cast to refer to data members of a base class part of an instance representation. This brings up relationships of multiple representations when they diverge from 1:1 representations of the full abstract info. Any full and valid representation is abstractly equivalent to another, but if one representation is updated, siblings must be invalidated or re-validated (some "view" might not be affected, another representation might be easy and worthwhile to update, like a small part of a complex object, but others might be cheaper to mark for disposal or lazy update). ISTM Python involves multiple concrete representations of types while also trying to unify the abstract aspects, and Psyco only adds to the need for a clear way to speak of Dynamic Representation Management (not Digital Rights Management ;-) issues. I hope I have triggered some useful thoughts, even though so far I only know of Psyco indirectly from these discussions (will try to correct that sometime soon ;-) Regards, Bengt Richter