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

Joe Mason joe at notcharles.ca
Sun Mar 28 01:53:25 EST 2004


In article <95aa1afa.0403272243.78d60724 at posting.google.com>, Michele Simionato wrote:
> 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.

In this case, you shouldn't worry about that, since presumably you're
just using it during development so it'll never be called anyway in the
release version.

> 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.

You could just put the function call in your base class's __init__
method.  (Or, in fact, put the code from that call directly there, if
you only care when you inherit from the one Zope class.)

> 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.

__init__ method, I believe.  But I just realized something - how does
Prothon (or prototyped languages in general) handle multiple
inheritance or mixins?

> [*] 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.

http://www.python.org/2.2/descrintro.html#metaclasses has some
references you might find interesting.

Joe



More information about the Python-list mailing list