Prothon, metaclasses, Zope [Was: A 'Python like' language]

Michele Simionato michele.simionato at poste.it
Sun Mar 28 01:43:01 EST 2004


> Hello, my name is Skip and I am metaclass-unaware.  I've been programming in
> Python for about ten years and I have yet to write a metaclass.  At first I
> thought it was just that metaclasses were new to the language, but now as
> more and more people use them and proclaim their widespread benefits, I have
> come to realize that through years of abuse my brain has become addicted to
> classic classes.

I began using Python since version 2.2.1 and without knowing anything
about OOP, so I had the advantage of a fresh start ;) Still, I will readily
admit that I was not immediately sold to metaclasses and actually I was
kind of skeptical about them. The "Putting metaclasses to work" book
made me change my mind. At this point I have becomed so accustomed to
metaclasses that I am disturbed when I cannot use them.

Just a real life example. I started studying Zope few days ago. 
Writing my first class I got caught since I was overriding a predefined Zope
method. I made a dir() and discovered that the context object in Zope
has more than four hundreds (400!) attributes. In such a situation it
is likely to override a predefined name, especially now that I am a
beginner and I have a fair chance of reimplementing (badly) something 
which is already available. So, I thought: "well, this a job for a metaclass" 
and in five minutes I implemented a metaclass raising an error if I was 
inadvertently overriding a predefined name (except names such as __init__ 
and similia, of course). Everything was nice and good until the moment
I tested the metaclass on a Zope class and got a segmentation fault.

Since I don't know anything about Zope internals I can only make a guess 
of what happened and I would be happy if some Zope guru here could
confirm (possibly educated) guess.

In my understanding, Zope tweaked Python classes at C level code, introducing
the concept of Extension classes. Extension classes are instances of a C coded
metaclass which does a lot of magic (for instance there are methods which
are automatically generated each time I create an extensions class);
unfortunately, this metaclass does not follow the protocol of Python 2.2+ 
metaclasses.  This is evidently an historical accident, since Zope Extension 
Classes were invented before Python 2.2 [*]; the net result is that I cannot
mix Python classes with custom metaclasses and Zope Extension classes.
 
I have heard that this is a temporary wart and that Zope 3 will solve
this issue (I'd like to have a confirmation here). However, for the
moment, I had to come out with a non-metaclass solution.

So, I reverted my mind to the pre-metaclass functioning mode (which required
a certain effort) and I wrote a function that takes a class, looks at
its dictionary, and raises an error if the class overrides an attribute
which is already defined in the parent classes. The solution works,
but it is kind of ugly compared to the metaclass solution:

1. The metaclass can raise the error *before* the metaclass is created,
   whereas the function works a posteriori, *after* the overriding is done;
   if find it to be conceptually unsatisfactory, I don't want to create
   a class just to throw it away. The alternative is to use a class factory,
   but then I have just re-invented a metaclass with an ugly call syntax.

2. The metaclass can be inherited, so the check is automatic for all children;
   on the contrary, I have to call the function by hand each time I define
   a new class. This means writing twice the class name, which is error
   prone if I later rename the class and I forget to update the function
   call.

Whereas it is true that in most cases you can find a non-metaclass solution, 
it is also true that in most case the metaclass solution is by far more 
elegant than the alternative. 

BTW, I wonder how Prothon would solve this problem, i.e. selectively 
forbidding the overriding of names, with an easy of use/elegance 
comparable to the Python metaclass solution.

                                 Michele Simionato


[*] I would be curious to know if Guido decided to expose metaclasses in 
Python since he noticed that they were already being used in real applications 
such as Zope (in some hidden form), or if there was some other reason.



More information about the Python-list mailing list