问题描述
当我们围绕共识召集火灾时，道歉，
但是我一直担心语法和语义之间的冲突，以及
我'终于达到了迷你顿悟：
PEP318的问题在于它太强大了，并试图做得太多了。这是一个攻击三个问题的大锤：
1）元数据，Java和C＃
2）class&静态方法defs
3）函数的任意定义后转换。
（其中2是一个特殊的常用用例，是3的一部分） 。
我们有更强大的语义（实现3），尝试用非常不同的语义解决
问题（例如，1）。
好的，这就是我所知道的。这是一个可能或可能不起作用的proprosal，
因为我对元类编程的了解只是粗略的：
1）仅制作PEP318 * *实施问题（1）。也就是说，为
定义和检索函数/方法/类元数据创建sematics
2）创建一个使用元数据类/静态的新默认元类
方法定义，用于执行必要的class / staticmethod
转换。也许只能通过
" from __future__ import foo"使用此元类作为默认值。
3）保留任意变换以通过自定义实现
元类 - 这些元类可以访问自定义元数据
来触发方法def转换。
Arien
Apologies for feeding the fire, when we are rallying around a consensus,
but I''ve been concerned about the clash between syntax and semantics, and
I''ve finally reached a mini-epiphany:
The problem with PEP318 is that it is too powerful, and tries to do too
much. It is a sledgehammer for attacking three problems:
1) Metadata, a la Java and C#
2) class & static method defs
3) Arbitrary post-definitional transformations of functions.
(where 2 is a special frequent use case that''s part of 3).
We have ueber-powerful semantics (implementing 3), trying to solve
problems with very different semantics (e.g., 1).
OK, that''s what I know. Here''s a proprosal, that may or may not work,
because my knowledge of metaclass programming is only sketchy:
1) Make PEP318 *only* implement problem (1). That is, create sematics for
defining and retrieving function/method/class metadata
2) Create a new default metaclass that uses metadata for class/static
method definitions to perform the necessary class/staticmethod
transformations. Perhaps use this metaclass as default in 2.4 only via a
"from __future__ import foo".
3) Leave any arbitrary transformations to be implemented via custom
metaclasses -- these metaclasses will have access to the custom metadata
to trigger method def transformations.
Arien
推荐答案
[snip]
我相信你的迷你顿悟已被其他几个人接触过
在这个论坛上进行了详细的讨论，肯定不是完全相同的话，但肯定是以非常相似的形式。
如果你已经检查了档案并看过那些讨论，但是仍然感觉你有一些非常原创的东西可供贡献，我建议
将你的论点与之前的论点进行对比演示
它是如何不同的，值得进一步讨论。
如果你不这样做，我希望很多人会觉得你只是在重复
游戏中非常晚，并且大部分都会忽略你的帖子。
-Peter
[snip]
I believe your mini-epiphany has been reached by several other people
in this forum and discussed at length, certainly not in exactly the
same words but surely in a very similar form.
If you''ve checked the archives and seen those discussions, but still
feel you have something really original to contribute, I suggest
contrasting your argument with those previous ones to demonstrate
how it is different and worth further discussion at this point.
If you don''t, I expect many people will feel you are just rehashing
something very late in the game and will mostly ignore your post.
-Peter
不幸的是，你可以在普通函数上使用装饰器而不仅仅是成员函数上的
。它排除了任何基于元类的实现。
Unfortunately for you, you can use decorators on normal functions and not
only on member functions. It rules out any metaclass based implementation.
[snip]
我相信你的迷你顿悟已经被其他几个人在这个论坛中达成并讨论过了最后，肯定不是完全相同的单词，但肯定是一个非常相似的形式。
[snip]
I believe your mini-epiphany has been reached by several other people
in this forum and discussed at length, certainly not in exactly the
same words but surely in a very similar form.
我没有听到过太多关于它的决议。我已经看过的讨论
主要围绕语法，部分围绕这是丑陋的但是
Guido说它去了。
我没有听说过它真的不难看，这就是为什么部分原因。
Arien
Arien
I haven''t heard too much resolution about it. The discussion I''ve seen
has been oriented mostly around syntax, partly around "this is ugly but
Guido says it goes".
I haven''t heard the "it''s really not ugly, and here''s why" part of this.
Arien
Arien
这篇关于PEP318：激进的观念的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！