Another way to spell __metaclass__ ?

[Bengt Richter]

On Fri, 13 Dec 2002 15:46:13 +0000, Gonçalo Rodrigues <op73418 at mail.telepac.pt> wrote:

>On 13 Dec 2002 06:08:42 GMT, bokr at oz.net (Bengt Richter) wrote:
>
>>
>>I must confess there is something that bothers me about __metaclass__ as
>>an impementation of metaclass functionality. It strikes me more as a
>>class transmogrification hook with a debug/trace flavor than a clear expression
>>of the relationship between two classes, one of which produces the other
>>as an instance.
>>
>>I.e., to me, the hallmark of a metaclass is that it produces another class when
>>instantiated (normally with variations based on conditions or parameters, or why
>>do it).
>
>At the risk of having completely missed the point, your gripe with
>__metaclass__ is of a purely syntactic nature. A metaclass *is* a class
Not quite just syntactic (and sorry if it sounded like a "gripe" ;-)

>whose instances are classes themselves, except currently there is simply
>no way to attach to a class statement information specifying the
>metaclass other than the __metaclass__ thingy.
>
Well, <devil's advocate> why do you need such an "attachment?" </da>
(E.g., my example was meant to show a way of associating the "attached"
elements without using __metaclass__).

I was exploring the idea of not having an "attachment" arrow from
a class to its metaclass, but instead expressing it as an arrow that points
in the other direction, or creates the arrow of association dynamically by
ordering of function arguments.

ISTM a metaclass is not the same concept as a base class, (though they can interact).
Inheritance of e.g. class Base by another is specified in the inheritor source, e.g.,
class Inheritor(Base), and the inheritor modifies and/or extends the base, and the
modifying entity specifies (via base list) the prototype that it is modifying.

In the case of a metaclass, it it doing the modifying, but it does not specify the
prototype info that it is modifying. Instead, the prototype class info specifies its
modifier by unique name (i.e., using __metaclass__ = unique name).

Either way, there is a composition of elements, but it's expressed differently.

To me, a class source definition is a spec for creating a class entity which
can retrieve and/or create elements and compose them into a composite entity
when called upon to do so (i.e., class instantiation).

Note that the class source specifies directly or indirectly all the things that
it's going to be composing together. And the action of composing is triggered
by calling the defined class object as a function.

Now contrast a metaclass. ISTM, if a metaclass is a class, the same abstract
description should apply. But what does __metaclass__ do? A class containing
a __metaclass__ line is still effectively an argument to a composition function,
yet somehow the argument specifies the function (and thereby excludes itself
from being and argument to another compatible composition function).

I.e., instead of having a (meta)class source definition which specifies elements
to be composed, one of those elements is specifying the (meta)class! That's like a base
class specifying a deriving class, ISTM. I.e., the arrow is points weirdly, IMO.
And the action of composing is not triggered by an explicit call of the (meta)class
object as a function, but instead that call happens at a certain phase of the
execution of the definition of one of the composition elements (i.e., when the
execution of the defintion of the class containing __metaclass__ finishes).

>The same problem happens for example when you want to declare a static
I hope I have been able to express something that is not "the same problem" ;-)

>method, you have to use something like
>
>def mystaticmethod(*args, **kwargs):
>    <whatever>
>
>mystaticmethod = staticmethod(mystaticmethod)
Somehow this doesn't bother me at all compared to __metaclass__ ;-)

>
>It would be much better if some kind of pseudo keyword would be
>introduced, e.g.
>
>def static mystaticmethod(*args, **kwargs):
>    <whatever>
>
>[most interesting stuff snipped]
>
>Unfortunately, as far as I remember, such syntactic sweetening is not
>scheduled to happen in the next 2.3.

ISTM there is more involved than syntactic sweetening ;-)

Regards,
Bengt Richter