@decorator语法是糖，但究竟是什么？ [英] @decorator syntax is sugar, but for what exactly?
问题描述
ISTM
@limited_expression_producing_function
@another
def func（）：传递
是用于创建隐藏的函数列表的语法糖。 （使用''|'代替'''''
并没有太大的改变（除了那些工具依赖于''@''的人; - ）。 br />
即，（没有来源或时间去钻研）上面
的表观语义大致类似于
__funclist__ = []
__funclist __。append（limited_expression_producing_f unction）
__funclist __。追加（另一个）
def func（）：传递
而__funclist__：func = __funclist __。pop（）（func）
del __funclist__
这是一个特例吗？更一般的想法？例如，在任何下一个名字绑定后，它是否适用于
，一般而言，不仅仅是由def绑定的名称？
因此（未经测试）
def censor（cls）：
cls .__ repr__ = lambda self：''< CENSORED>''
返回cls
...
@censor
class C（对象）：传递
可能有预期的效果（在元类效应之后，如果有的话，大概是BTW）
（请注意，审查员可以改为包裹选定的方法或添加类变量数据等，
虽然IIRC __metaclass__可以创建一些以后只读的东西。
这仍然是由前缀上下文非常狭窄地定义的。这个上下文还是
特殊情况下默认的更普遍吗？ IOW默认选择
命名空间是词法封闭的。那么，例如，能够在模块顶部的一个地方指定
装饰并装饰（以相同的方式，使用
相同的功能列表）所有指定（按名称）类列表的方法？
即，当什么名称绑定在什么名称空间中时，更一般地控制该怎么做
可以设想。这开始感觉像事件驱动的处理。 @ deco1 @ deco2
可以用于特殊情况的糖（不要用字面意思，只是说明语义;-)
when（event = ''next_binding''，namespace =''immediate''，symbols =''any''，funclist =（deco1，deco2））
def foo（）：传递
一般的东西，也可能包括其他和可能重复的事件，如完成
的arg列表，用于调用特定函数或方法或任何重新绑定特定
指定命名空间中的
符号（不仅仅是直接命名空间），例如，用于调试或分析等等。
因为我将它复制到python-dev，我''将再次询问@decorator是否有任何特殊的
线程安全陷阱应该加以警告，以防万一。
请将此作为探测预期的语义，而不是任何特定
功能的提议;-)
问候，
Bengt R ichter
ISTM that
@limited_expression_producing_function
@another
def func(): pass
is syntactic sugar for creating a hidden list of functions. (Using ''|'' in place of ''@''
doesn''t change the picture much (except for people whose tools depend on ''@'' ;-)).
I.e., (not having the source or time to delve) the apparent semantics of the above
is something roughly like
__funclist__ = []
__funclist__.append(limited_expression_producing_f unction)
__funclist__.append(another)
def func():pass
while __funclist__: func = __funclist__.pop()(func)
del __funclist__
Is this a special case of a more general idea? E.g., could it apply to
right after ANY next name is bound, in general, not just a name bound by def?
thus (untested)
def censor(cls):
cls.__repr__ = lambda self: ''<CENSORED>''
return cls
...
@censor
class C(object): pass
could have the expected effect (after metaclass effects, if any, presumably, BTW)
(note that censor could instead e.g. wrap selected methods or add class variable data etc.,
though IIRC __metaclass__ can create some things that are read-only later)
This is still very narrowly defined by prefix context. Is this context also
a special case default of something more general? IOW the default choice for
namespace is the lexically enclosing one. What about, e.g., being able to specify
decoration in one place at the top of a module and decorate (in the same way, using
the same function list) all methods of a specified (by name) list of classes?
I.e., a more general control over what to do when what names are bound in what namespace
could be envisaged. This begins to feel like event-driven processing. Could @deco1 @deco2
be sugar for the special case (don''t take this literally, just illustrating semantics ;-)
when(event=''next_binding'', namespace=''immediate'', symbols=''any'', funclist=(deco1,deco2))
def foo(): pass
of something general that could also include other and possibly repeated events like on completion
of an arg list for a particular function or method being called or any rebinding of particular
symbols in a specified namespace (not just the immediate one), e.g., for debugging or profiling etc.
Since I am copying this to python-dev, I''ll re-ask whether @decorator has any peculiar
thread safety pitfalls that should be warned against, just in case.
Please take this as a probe into the intended semantics, not as a proposal for any particular
functionality ;-)
Regards,
Bengt Richter
推荐答案
2004年8月7日星期六23:50:47 +0000，Bengt Richter写道：
代码：
On Sat, Aug 07, 2004 at 23:50:47 +0000, Bengt Richter wrote:
The code:
@limited_expression_producing_function
@another
def func（）：传递
@limited_expression_producing_function
@another
def func(): pass
相当于：
def func（）：传递
func = limited_expression_producing_function（另一个（func））
-
mithrandi，i Ainil en-Balandor，faer Ambar
----- BEGIN PGP SIGNATURE -----
版本：GnuPG v1.2.5（GNU / Linux）
iD8DBQFBFW0opNuXDQIV94oRAljjAJ0aJsggvp2vEVeCgBCapi TgbSb + gQCfTWTF
OUghKvwWu / GZ7JMTBf9ppzI =
= BwLb
-----结束PGP SIGNATURE -----
is equivalent to:
def func(): pass
func = limited_expression_producing_function(another(func ))
--
mithrandi, i Ainil en-Balandor, a faer Ambar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFBFW0opNuXDQIV94oRAljjAJ0aJsggvp2vEVeCgBCapi TgbSb+gQCfTWTF
OUghKvwWu/GZ7JMTBf9ppzI=
=BwLb
-----END PGP SIGNATURE-----
我读过一些Python博客，而不是一个正在以一种好的方式采用装饰器语法
。
1.5.2简单的Python将很久没有了。 <无线电通信/>
I have read a few Python blogs and not a one is taking the decorator syntax
in a good way.
The Python of 1.5.2 simplicity will be long gone.
Robert写道：
Robert wrote:
我读了一些Python博客，而不是一个正在采用装饰器语法
好办法。前一段时间介绍了
classmethod和staticmethod，以提供获得此类效果的机制。当时没有明确的
语法来使用感觉正确。与此同时，尽管使用笨重的方式，人们仍然使用这些
功能，效果很好。在这个
点可能会有一个小骚乱（或至少是一个大呜呜声）
如果这两个被移除。
当我第一次来到Python时，我很高兴看到Idle给了我
函数线索，不仅是系统代码，还有代码_I_写道。
因为撰写可能永远不会被阅读的评论需要纪律，所以最终看到立即奖励做一点
文档工作是令人愉快的 - 我可以帮助自己在我自己的实用程序函数上。
然而，文档字符串对于其他文件的使用越来越多，而不是文档。在这一点上，我看到越来越多的docstring使用
作为cybercrud。 - 唯一简单的函数注释是docstring所以
所有雄心勃勃的程序注释方案都使用它。因为想要能够注释函数和方法，有很好的理由
，但是为了这样做，很少有很好的理由来污染文档字符串。
装饰师是出路。我不知道语法，当我第一次看到它时看起来很糟糕
，但和其他一些人一样，我欢迎装饰者使用_almost_any_syntax_
。不是，因为我想使用装饰器。我只是想要其他人为了非文档目的而停止使用文档字符串。在
其实我甚至不喜欢使用方法
名称来确定测试方法的单元测试约定 - 我更喜欢你所用的语言/>
调用一个东西并不会影响它的工作原理。
1.5.2简单的Python早就不见了。
I have read a few Python blogs and not a one is taking the decorator syntax
in a good way. classmethod and staticmethod were introduced some time ago, to provide
a mechanism for getting to such effects. At the time there was no clear
syntax to use that "felt right." In the meantime people have used these
features to good effect despite the clunky way you used them. At this
point there would probably be a small riot (or at least a large whine)
if these two were removed.
When I first came to Python, I was delighted to see that Idle gave me
function clues not only for the system code, but for the code _I_ wrote.
Since it takes discipline to write comments that may never be read, it
was delightful to finally see an immediate reward for doing a little
documentation work -- I could help myself on my own utility functions.
However, there are more and more uses of the docstring for things other
than documentation. At this point, I see more and more docstring uses
as "cybercrud" -- The only easy function annotation is the docstring so
all ambitious program annotation schemes use it. There are good reasons
for wanting to be able to annotate functions and methods, but precious
few good reasons for polluting the document strings in order to do so.
Decorators are a way out. I don''t know about the syntax, it looked bad
when I first saw it, but like some others, I welcome _almost_any_syntax_
for decorators. Not, so much, because I want to use decorators. I just
want others to stop using docstrings for non-documentation purposes. In
fact, I don''t even really like the unittest convention of using method
names to identify test methods -- I prefer a language where the what you
call a thing does not affect how it works.
The Python of 1.5.2 simplicity will be long gone.
嗯，即便如此，还有很多值得喜欢的东西，但我不想放弃我们现在拥有的东西 - 你现在可以用更实用的方式做事，
$ b带嵌套作用域的$ b。你真的想回到三次打击
并且你在寻找符号吗？这种语言已经发生了很好的变化，并且（非常令人惊讶地）变得更加一致的模式（语言设计中的b
主要政变）。推动
变化的美学表明这可能是声明者的正确语法。
我知道我不会做几乎和Guido和帮派一样好制作
语言决定。
我当然打算把这段阿尔法时期作为一个时间用装饰器来实验
并看看如果语法在我身上增长;我建议别人
做同样的事情。给它最好的机会;你可能成为粉丝。几个
的py-dev人声称他们已经从厌恶变为
支持。
-
-Scott David Daniels
Sc *********** @ Acm.Org
这篇关于@decorator语法是糖，但究竟是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
