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

[Mark Hahn]

> BTW, I wonder how Prothon would solve this problem

Me too.  I'll have to take a stab at it.

Mark Hahn (Prothon author daring to raise his head in the Python forum).

"Michele Simionato" <michele.simionato at poste.it> wrote in message
news:95aa1afa.0403272243.78d60724 at posting.google.com...
> > 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.