[Types-sig] Re: Meta-classes discussion starter

[Evan Simpson]

Thanks for the feedback; It appears that I did a really lousy job of
expressing myself.  Let's see if  I can summarize clearly, while answering
your points.

I did intend my thread to be related to the types/classes discussion.  Many
of the threads in the archive seem to eventually come around to the idea
that if everything is to be an object and have a class (the whole
unification thing), then classes must have classes, and to be really tidy
and orthogonal, these meta-classes should be well-defined as such (Rather
than, say, simply declaring the class of every class to be an empty built-in
object MetaClass whose class is itself, and leaving it at that).

Given the premise that meta-classes should be to classes as classes
currently are to instances, I see two problems.   How do you deal with
method binding? How do you define methods at different levels
(meta-/class/instance) with the same name?  These are particularly a problem
if you want to initialize your classes and instances with __init__.
Meta-classes need a way to spell "__init__ for my classes" and "__init__ for
instances of my classes", and "__init__ for my classes" *has* to be a class
method if it is to exist.

The best solution I could think of was to be able to specify when a method
gets bound by giving the number of steps to hold off binding.  To avoid name
clashes, and to make everything as compatible as possible with current code,
keep methods whose binding is deferred tucked away in a pocket attribute.

My proposed syntax is ugly, but I couldn't think of an elegant way to spell
it.  My "best" alternative was stuttering (eg. "def def def
__init__(self):").  Bleh.

About all you do get out of this scheme is class methods (which I'm
accustomed to using in Delphi), something resembling templates, and a bit of
extra expressive power.  Then again, it doesn't really require much in the
way of changes to Python, and can be implemented without breaking any
current code (I think).

And that's all I had to say :-)

-----Original Message-----
1) I don't think it belongs here, unless you shoe-horn it into the
types / classes discussion (or lack thereof).

2) I read it about 6 times, and only sort-of got an idea of where you
were headed.

3) Whether or not the intent is good, the syntax is, I think,
unmanagable - just way too arcane.

4) The only application of this that was evident was the
implementation of "class methods" (in the more esoteric definition of
same), which is something only a small number of people seem to
miss, (perhaps because only SmallTalkers have any idea what it
means). By contrast, the most popular application of metaclasses
seems to be to install __getattr__ and __setattr__ hooks, and I don't
see how your proposal furthers that. But see (2), above.

5) You also seem to be proposing vast changes in Python's class
model. The current metaclass hook is, of course, a wart on the
current class model; but one that's backwards compatible. If we're
talking about the Python 2 class model, I'm not sure I agree with
your definition of metaclasses. Not sure I disagree, either. See (2).