FEEDBACK WANTED: Type/class unification

[Albert Langer]

Enabling "python only" developers to do "meta-class stuff" easily is
likely to have great consequences. The "exploding heads syndrome" was
equally true for "object oriented stuff" like "classes" and
"inheritance" before they became "normal". I never download alpha
python versions because I'm not a C developer and can't help fix it.
But I couldn't resist checking out 2.2a1 after reading the clear
description and am really looking forward to playing with it in 2.2.
My guess is that lots of others who can't contribute using "arcane"
techniques (including C modules ;-) will now be able to add very
interesting stuff that will actually get re-used rather than
re-written (and that may look "arcane" to C developers).

So let's assume people start generating lots of new types. Pretty soon
they are going to want to classify them. Of the conventions suggested
so far to hint at what meta level one is working, "kind" seems the
most natural. But that would mean self is at model level M0
(instances), kind is at model level M1 and there is no convention for
M3 and M4 in the standard meta-modelling framework:

http://www.dstc.edu.au/Research/Projects/MOF/rtf1.4/

Python 2.2 seems to be a natural fit for what looks likely to become a
dominant approach of "Model Driven Architecture". It should be
feasible to directly generate python programs from profiles of higher
level models and then interactively execute them in a visual UML style
modelling environment, but "animated" as is done routinely for
"debugging".

Check out the Meta Object Framework standards being developed at above
link and the UML (Rose) models for them, and the increasing use of MOF
models and UML "profiles" in other OMG standards. Most java code is
going to be directly generated from modelling tools, thus eliminating
most of its syntax hassles compared with Python. Python can actually
do that much better than java and should have a
reflection/introspection API that can easily be aligned directly with
the MOF standards.

Two missing features I noticed are:

1) A method that gets automatically called exactly once immediately
after a type is created similar to the ExtensionClass _class_init__.

2) Methods allowing parameterized classes to specify an immutable
"key" based on their immutable static attribute values that is
recognized by dictionaries such as _class_hash__ and _class_cmp_.

I suspect such items point to a need for something more than a simple
naming convention.

One that was suggested was:

def method(class self, param1,...):

That extends naturally to:

def method(class class self, param1,...):

The parser would presumably have to count the number of occurrences of
class instead of barfing at the first one as a keyword error and then
somehow bind the method at that level. At the same time it could do
name mangling similar to __class_attribute to avoid name clashes.