Prothon，元类，Zope [是：像'Python一样的'语言] [英] Prothon, metaclasses, Zope [Was: A 'Python like' language]
问题描述
>您好，我的名字是Skip，我是metaclass-unaware。我已经在
> Hello, my name is Skip and I am metaclass-unaware. I''ve been programming in
Python编程了大约十年，我还没有写一个元类。起初我认为只是元类是语言的新手，但现在随着越来越多的人使用它们并宣布它们的广泛利益，我已经意识到，通过多年虐待我的大脑已经沉迷于经典课程。
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.
我从2.2.1开始使用Python而且不知道任何事情
关于OOP，所以我有一个新的开始的优势;）仍然，我会很快
承认我没有立即卖给元类，实际上我是
对他们持怀疑态度。 使元课工作书
让我改变主意。在这一点上，我已经习惯了，当我不能使用它们时，我会感到不安。
只是一个真实的例子。我几天前就开始研究Zope了。
写第一堂课我被抓了，因为我超越了预定义的Zope
方法。我做了一个dir（）并发现Zope
中的上下文对象有超过四百（400！）个属性。在这种情况下，它可能会覆盖预定义的名称，特别是现在我是一个初学者，而且我很有可能重新实现（非常）某些事情。 />
已经可用。所以，我想：嗯，这是一个元类的工作
，在五分钟内，我实现了一个元类，如果我是因为无意中覆盖预定义而导致错误名称（例如__init__
和similia等名称除外）。一切都很好，直到那一刻
我在Zope类上测试了元类并且出现了分段错误。
因为我什么都不知道关于Zope内部我只能猜测
发生了什么事情我会很高兴如果这里有一些Zope大师可以确认（可能是受过教育的）猜测。
根据我的理解，Zope在C级代码中调整了Python类，并引入了扩展类概念的
。扩展类是C编码的实例
元类，它具有很多魔力（例如，每次创建扩展类时都会自动生成
的方法）;
遗憾的是，这个元类不遵循Python 2.2 +
元类的协议。这显然是一个历史性的事故，因为Zope扩展
类是在Python 2.2 [*]之前发明的;最终的结果是我不能把bc和自定义元类和Zope扩展类的Python类混合在一起。
我听说这是一个临时的疣和Zope 3将解决
这个问题（我想在这里得到确认）。然而，对于
的时刻，我不得不推出一个非元类解决方案。
所以，我把我的想法转移到了前元类功能上模式（需要一定的努力才能获得
a）并且我编写了一个函数，它接受一个类，查看它的字典，并且如果该类重写了一个属性，则会引发错误。 />
已在父类中定义。解决方案有效，
但与元类解决方案相比它有点难看：
1.元类可以在*元类之前引发错误*创建，
而函数是后验的，*在覆盖完成之后;
如果发现它在概念上不令人满意，我不想创建
a类只是扔掉它。另一种方法是使用一个类工厂，
然后我刚刚重新发明了一个带有丑陋的调用语法的元类。
2.元类可以继承，所以所有孩子都自动检查;
相反，每次我定义
a新课时我都要手动调用该功能。这意味着写两次类名，这是错误的，如果我稍后重命名该类，我忘了更新函数
调用。
然而，在大多数情况下，您可以找到非元类解决方案，
在大多数情况下，元类解决方案也是如此。
比替代品更优雅。
BTW，我想知道Prothon如何解决这个问题，即选择性地
禁止覆盖名称，简单易行使用/优雅
与Python元类解决方案相当。
Michele Simionato
[*]我会很想知道Guido是否决定在
Python中公开元类，因为他注意到它们已经被用于实际应用程序
，如Zope（以某种隐藏形式），或者是否还有其他原因。
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.
推荐答案
文章< 95 **************** ********** @张贴。 google.com>，Michele Simionato写道：
In article <95**************************@posting.google.com >, Michele Simionato wrote:
1.元类可以在*创建元类之前引发错误*，而函数在后面执行*后覆盖*已经完成;
如果发现它在概念上不能令人满意，我不想创建一个只是扔掉它的课程。另一种方法是使用类工厂，但后来我重新发明了一个带有丑陋调用语法的元类。
在这种情况下，你不应该担心，因为大概你只是在开发过程中使用它，所以它永远不会无论如何都要在
发布版本中调用。
2.元类可以继承，所以对所有孩子都是自动检查;
相反，我每次我定义一个新类时，都必须手动调用该函数。这意味着写两次类名，如果我稍后重命名该类而忘记更新函数
调用，则容易出错。
您可以将函数调用放在基类的__init__
方法中。 （或者，实际上，直接把那个调用的代码放在那里，如果
你只关心你从一个Zope类继承。）
BTW，我想知道如何Prothon将解决这个问题，即选择性地禁止名称的覆盖，易于使用/优雅，与Python元类解决方案相当。
__init__方法，我相信。但我刚刚意识到了一些事情 -
Prothon（或一般的原型语言）处理多个
继承或mixins？
[*] I我很想知道Guido是否决定在Python中公开元类，因为他注意到它们已经被用于实际应用程序中，例如Zope（以某种隐藏形式），或者是否有其他原因。
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 有一些您可能感兴趣的
参考文件。
Joe
http://www.python.org/2.2/descrintro.html#metaclasses has some
references you might find interesting.
Joe
Joe Mason< jo*@notcharles.ca>在消息新闻中写道：< sl **************** @ gate.notcharles.ca> ...
Joe Mason <jo*@notcharles.ca> wrote in message news:<sl****************@gate.notcharles.ca>...
你可以放函数调用基类的__init__
方法。 （或者，事实上，直接把那个调用的代码放在那里，如果你只关心从一个Zope类继承那个。）
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.)
呃？当我派生一个新的
类时，不会调用基类__init__方法。我想在课堂级别进行检查，*之前*
实例化。
Michele Simionato
Uh? The base class __init__ method is not called when I derive a new
class. I want to make the make the check at class level, *before*
instantiating.
Michele Simionato
在文章< 95 ************************** @ posting.google.com>中，Michele Simionato写道：
In article <95**************************@posting.google.com >, Michele Simionato wrote:
Joe Mason< jo*@notcharles.ca>在消息新闻中写道：< sl **************** @ gate.notcharles.ca> ...
Joe Mason <jo*@notcharles.ca> wrote in message news:<sl****************@gate.notcharles.ca>...
你可以放函数调用基类的__init__
方法。 （或者，事实上，直接把那个调用的代码放在那里，如果你只关心从一个Zope类继承那个。）
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.)
呃？当我派生一个新的类时，不会调用基类__init__方法。我想在类级别进行检查，*之前*
实例化。
Uh? The base class __init__ method is not called when I derive a new
class. I want to make the make the check at class level, *before*
instantiating.
如果你调用继承的__init__方法，你应该这样做是因为它可能会起到重要的作用，所以需要这么做。
为什么在实例化课程之前你是否关心它，或者
实例化该类，然后在__init__期间抛出错误？对于成功的案例，它不会对速度或内存产生任何影响，
这就是你所关心的性能。
Joe
It is if you call the inherited __init__ method, which you should be
doing because it probably does important stuff.
Why do you care whether it checks before instantiating the class, or
instantiates the class and then throws an error during __init__? It''s
not going to make any speed or memory difference to the successful case,
which is all you care about for performance.
Joe
这篇关于Prothon，元类，Zope [是：像'Python一样的'语言]的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
