装饰者？ [英] decorators ?

问题描述

大家好，

通过python2.4版本引入的新功能。

i被装饰者所困扰 - 有人可以解释我的需要这样的东西叫装饰师？

tia

KM

Hi all,
was going thru the new features introduced into python2.4 version.
i was stuck with ''decorators'' - can someone explain me the need of such a thing called decorators ?
tia
KM

推荐答案

" km" < [e-mail]>在留言中写道

新闻：ma ************************************ ** @ pyth on.org ...

"km" <[e-mail]> wrote in message
news:ma**************************************@pyth on.org...

大家好，
正在通过python2.4版本引入的新功能。
我被困在''装饰' ' - 有人可以解释我需要这样一个叫做装饰器的
的东西吗？ tia
KM

Hi all,
was going thru the new features introduced into python2.4 version.
i was stuck with ''decorators'' - can someone explain me the need of such a thing called decorators ? tia
KM

以下是Python Wiki上的一些示例：
http://www.python.org/moin/PythonDecoratorLibrary


我认为memoize是我的最爱到目前为止。


我不确定示例行为是否清楚。对于给定的一组

参数，Memoize类保留输入arg值的字典和

返回值。在后续调用中，在先前调用的

字典中查找args集 - 如果找到arg列表，则绕过函数

，并缓存返回值立即返回。这可以大大加快对非常耗时的函数的调用速度，或递归的b
。这就是Wiki页面列出factorial（）和fibonacci（）

示例的原因。当然，Memoize假设返回值纯粹是输入参数的一个

函数，并且不受任何外部状态的影响。


当然，一个可以在目标

函数中轻松实现此行为。装饰的美妙之处在于，这个优化完成了* b $ b *完全*在函数本身之外，所以函数在应用程序级别保持相当纯净，并且没有得到混乱的变量

喜欢resultsCache等等。此外，为了最大限度地重复使用

并避免剪切和粘贴的漏洞，将Memoize隔离到

可重复使用的装饰器有助于避免引入错误（vs.硬编码这个

优化到连续的函数中 - 你还记得初始化

字典吗？），并利用任何优化或错误修复。


（我专注于Memoize，但这些评论适用于

这个维基页面上的任何装饰者。）


- Paul

Here are some example on the Python Wiki:
http://www.python.org/moin/PythonDecoratorLibrary

I think memoize is my favorite so far.

I''m not sure if the example behavior is all that clear. For a given set of
arguments, the Memoize class keeps a dictionary of input arg values and
return values. In subsequent calls, sets of args are looked up in the
dictionary of previous calls - if the arg list is found, then the function
is bypassed, and the cached return value is returned immediately. This can
greatly speed up calls to functions that are very time-consuming, or
recursive. This is why the Wiki page lists factorial() and fibonacci()
examples. Of course, Memoize assumes that the return value is purely a
function of the input args, and not subject to any external state.

Of course, one could readily implement this behavior within the target
functions. The beauty of the decorator is that this optimization is done
*completely* outside the function itself, so the function remains fairly
pure at the application level, and does not get cluttered with variables
like "resultsCache" and so on. Also, in the interests of maximizing reuse
and avoiding the bug-proneness of cut-and-paste, isolating Memoize into a
reusable decorator helps avoid introducing bugs (vs. hard-coding this
optimization into successive functions - did you remember to initialize the
dictionary?), and leverages any optimizations or bug-fixes.

(I focused on Memoize, but these comments apply to any of the decorators on
this wiki page.)

-- Paul

更多装饰器示例。


如何使用@absractmethod装饰器创建抽象方法：
http://www.brpreiss.com/books/opus7/html/page117 .html


泛型，财产吸引者和二传手。我不知道这些装饰者应该做什么：
http://www.cis.upenn.edu/~edloper/pydecorators.html -


根据这个，
http：// www .prothon.org / pipermail / pro ... st / 003173.html ，

装饰器的一个用途是在def

f之前放置一个函数docstring （）：这样的行：


@doc（"""" blabla do something something。"""）

def blabla（ ）：


这里有一个优化装饰器：
http://aspn.activestate.com/ASPN/Coo.../Recipe/277940


我认为装饰器的本质是它可以在Python中使用
你在其他语言中使用方法限定符。这个

声明用Java


public synchronized static void doStuff（）


你会用Python编写


@public

@synchronized

@staticmethod

def doStuff（）：


我没见过@synchronized装饰器的例子，但我认为

是可能的。希望有可能创建一个@private

装饰器，当从类外部访问私有方法

时会抛出某种异常。如果这是可能的，那么它将是一个很好的拥有一个@public装饰器，它什么都不做。至于

据我所知，在Python 2.4，@ staticmethod和@classmethod的标准

库中只包含两个装饰器。这是一个很不幸的事情，因为还有更多明显的。原本可以包含

。开发人员可能正计划在即将发布的

版本中对其进行更正。

这就是我所知道的装饰器。或者更确切地说，我知道从互联网上阅读的东西。

。如果我错了，请不要激怒我。 :)


-

mvh Bj？rn

Some more decorator examples.

How to create abstract methods using an @absractmethod decorator:
http://www.brpreiss.com/books/opus7/html/page117.html

Generics, property getters and setters. I don''t know what these
decorators are supposed to do:
http://www.cis.upenn.edu/~edloper/pydecorators.html -

And according to this,
http://www.prothon.org/pipermail/pro...st/003173.html,
one use of decorators is to put a functions docstring before the def
f(): line like this:

@doc("""blabla does something.""")
def blabla():

Here is one decorator for optimizing:
http://aspn.activestate.com/ASPN/Coo.../Recipe/277940

I think the essence of decorators is that it makes it possible to do
in Python what you in other languages do with method qualifiers. This
declaration in Java

public synchronized static void doStuff()

would you write in Python as

@public
@synchronized
@staticmethod
def doStuff():

I haven''t seen an example of a @synchronized decorator, but I assume
it is possible. Hopefully, it is possible to create a @private
decorator which throws some kind of exception when a private method is
accessed from outside the class. If that is possible, then it would
also be nice to have a @public decorator which doesn''t do anything. As
far as I know, only two decorators are included in the standard
library in Python 2.4, @staticmethod and @classmethod. That is a
little unfortunate, because many more "obvious ones" could have been
included. The devs are probably planning to correct that in the coming
versions.
That is all I know about decorators. Or rather THINK I know from
reading stuff on the internet. Please don''t flame me if I''m wrong. :)

--
mvh Bj?rn

BJ？Lindqvist< bj *****@gmail.com>写道：

BJ?rn Lindqvist <bj*****@gmail.com> writes:

我认为装饰器的本质在于它可以在Python中完成你用其他语言用方法限定符做的事情。

I think the essence of decorators is that it makes it possible to do
in Python what you in other languages do with method qualifiers.

我发现添加一点语法糖给人的感觉很有吸引力

认为一系列全新的以前无法想象的

可能性已在我们面前展开。


@X

def Y ...

...

只是语法糖（或语法氨，对于某些人来说）

def Y ...

...

Y = X（Y）


你可以用装饰器做任何事情，你可以做之前（使用

例外重新绑定__name__函数）。 />

然而，那些语法糖真的_does_产生了很大的差异

到人们准备采取的可能性的长度

基本功能提供给他们。

I find it fascinating that the addition of a bit of syntax sugar gives
the perception that a whole range of new and previously unthinkable
possibilities have opened themselves before us.

@X
def Y...
...
is merely syntax sugar (or syntax ammonia, for some) for
def Y...
...
Y = X(Y)

Anything you can do with decorators, you could do before (with the
exception of rebinding the __name__ of functions).

And yet, that bit of syntax sugar really _does_ make a big difference
to the lengths that people are prepared to take the possibilities that
the underlying feature affords them.

这篇关于装饰者？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！