欢迎各位兄弟 发布技术文章
这里的技术是共享的
沙发. 还有个很常用的功能 @web.authenticated
好文。。。
Python 3.4里的asyncio更好玩。coroutine使用generator而不是thread。
请问get_line_number 在哪里定义的呢？
代码没贴全，Sorry，已补上。
—– 要修正这一问，我们还得用Python的反映来解决，下面是相关的代码：
反映应该是反射
文章很棒！
谢谢，已修正。
kamushin :沙发. 还有个很常用的功能 @web.authenticated
Tornado党握爪
好文，强烈推荐
可以用来实现AOP
所以，Python的functool包中提供了一个叫wrap的decorator来消除这样的副作用。下面是我们新版本的hello.py。wrap -> wraps
每篇都是精品，钦佩之余，更多的是激励自己加倍努力！
篇篇都是硬货！不过“注册回调函数”这个例子有些问题，“你调用main_page_func()或是next_page_func()就调到了黑洞了，啥也不会发生。你只有通过app.call_method才行。”，这句话是不对的，@app.register(‘/’) 注册了函数后直接把原函数返回了，所以main_page_func这个函数没有任何变化，可以跟原来一样调用。
谢谢指正，是我眼花了。来自
典型的反框架模式，或者叫非侵入式框架，摒弃了强制性换取灵活性。可以人肉AOP。缺点是复用部分不够彻底，还有感觉这种功能以continuation实现的方式不如放到meta programming层次来的通用。
解释下“class式的 Decorator”节中aFunction()多次调用仅输出一次“inside myDecorator.__init__()”背后的动作是不是更有助于理解修饰器呢？
Tydus :kamushin :沙发. 还有个很常用的功能 @web.authenticatedTornado党握爪
Tydus :
还有 @gen.coroutine 呢喵～话说那个 @memo 在 Python 3.2+ 可以用 @functools.lru_cache 取代了 :-)
在带参数及多个Decrorator模块下：wrapper函数中的 fn(*args, **kwds) 改成fn() 会不会更好点，因为fn调用没有参数
@Tydus tornado党 +1 ,@web.authenticated 好用
正在学习python，收藏了。
我也是这么理解的@frank
C#中没有Annotation，对应的技术应该是Attribute。
感谢楼主分享，学习了
我以前一直深信好的架构能够减少维护成本，不过后来我开始有疑问了。其实不管是开发的人还是维护的人，学习成本是一样的。如果维护的人不能理解设计者的本意，再好的代码也会变成bull shit。所以学习的成本是一样的。
@eleveni386 @login_required 也好用。
= =我昨天面试刚好给人问了什么是Python的Decorator，然后我就回答这其实就是Decorator Pattern的实现。。我看了stackoverflow的回答（http://stackoverflow.com/questions/8328824/whats-the-difference-between-python-decorators-and-decora...），上面说Python的Decorator是在定义的时候去修改行为，Decorator模式是在运行期修改行为，所以Python的就高阶一点。但我觉得从本质上来看，两者都是通过Decorator包装原有的，来修改行为，思想是一样的。。真心求教，期待回答，谢谢！
好文章啊！不过有一点还不懂，就是使用类方式实现装饰器的时候怎么消除副作用啊，foo.__name__直接就没有了，用@wraps也不行？？？
zz :好文章啊！不过有一点还不懂，就是使用类方式实现装饰器的时候怎么消除副作用啊，foo.__name__直接就没有了，用@wraps也不行？？？
def __init__(self, fn):self.fn = fnself.__name__ = fn.__name__用这个倒是可以，请教楼主还有更好的方法么？
return “Hello, {}”.format(name)“Hello, {0}”.format(name)
这样挺酷的。不过有个疑问是，函数本身为何要关注自己如何被decorate，由调用者来决定不是更好，而且不同的调用者可能会有不同的decorate需求。
自习分析了一下，html.py的调用执行流程，发现这个带参数的多个decorator的执行流程和优先级顺序，让人有点费解
def
makeHtmlTag(tag,
*
args,
kwds):
print
"Enter the makeHtmlTag "
,tag,args,kwds
real_decorator(fn):
"Enter the real_dec"
css_class
=
" class='{0}'"
.
format
(kwds[
"css_class"
]) \
if
in
kwds
else
""
"\tcss_class:"
+
"\tfn.__name__:"
fn.__name__
wrapped(
"Enter the warapped"
,args,kwds
"\twarp_fn.__name__:"
"\tcurrnt css_calss:"
"leave the warapped"
return
"
" + fn(*args, **kwds) + "
"leave the real_dec"
wrapped
" ........... "
"leave the makeHtmlTag "
real_decorator
@makeHtmlTag
(tag
"b"
, css_class
"bold_css"
)
"i"
"italic_css"
hello():
"hello world"
hello()
——————————————————————————————输出结果如下：
Enter the makeHtmlTag b () {
'css_class'
:
'bold_css'
}
...........
leave the makeHtmlTag b () {
Enter the makeHtmlTag i () {
'italic_css'
leave the makeHtmlTag i () {
Enter the real_dec
css_class: class=
fn.__name__:hello
leave the real_dec
fn.__name__:wrapped
Enter the warapped () {}
warp_fn.__name__:wrapped
currnt css_calss: class=
leave the warapped () {}
warp_fn.__name__:hello
<b><i>hello world<
/i
><
/b
>
@Tydus
`@gen.coroutine`更常用吧，否则tornado用着没意思了。。。
addbook :@Tydus@gen.coroutine更常用吧，否则tornado用着没意思了。。。博主可以使用markdown编辑器，可能更方便。。
飞罗 :在带参数及多个Decrorator模块下：wrapper函数中的 fn(*args, **kwds) 改成fn() 会不会更好点，因为fn调用没有参数
同问，能不能同时适用于fn() 与 fn(*args, **kwargs)
赞！！篇篇都是干货！
很棒
解决了困扰我很长时间的疑问，目前为止看过关于decorator解释得最清楚的文章。
上面这段代码，wrapped函数应该没必要传参吧？改成下面这样结果是一样的：
wrapped():
" + fn() + "
kamushin
沙发. 还有个很常用的功能 @web.authenticated
好文。。。
Python 3.4里的asyncio更好玩。coroutine使用generator而不是thread。
请问get_line_number 在哪里定义的呢？
代码没贴全，Sorry，已补上。
—– 要修正这一问，我们还得用Python的反映来解决，下面是相关的代码：
反映应该是反射
文章很棒！
谢谢，已修正。
Tornado党握爪
好文，强烈推荐
可以用来实现AOP
所以，Python的functool包中提供了一个叫wrap的decorator来消除这样的副作用。下面是我们新版本的hello.py。
wrap -> wraps
每篇都是精品，钦佩之余，更多的是激励自己加倍努力！
篇篇都是硬货！
不过“注册回调函数”这个例子有些问题，“你调用main_page_func()或是next_page_func()就调到了黑洞了，啥也不会发生。你只有通过app.call_method才行。”，这句话是不对的，@app.register(‘/’) 注册了函数后直接把原函数返回了，所以main_page_func这个函数没有任何变化，可以跟原来一样调用。
谢谢指正，是我眼花了。
来自
典型的反框架模式，或者叫非侵入式框架，摒弃了强制性换取灵活性。可以人肉AOP。缺点是复用部分不够彻底，还有感觉这种功能以continuation实现的方式不如放到meta programming层次来的通用。
解释下“class式的 Decorator”节中aFunction()多次调用仅输出一次“inside myDecorator.__init__()”背后的动作是不是更有助于理解修饰器呢？
还有 @gen.coroutine 呢喵～
话说那个 @memo 在 Python 3.2+ 可以用 @functools.lru_cache 取代了 :-)
在带参数及多个Decrorator模块下：
wrapper函数中的 fn(*args, **kwds) 改成fn() 会不会更好点，因为fn调用没有参数
@Tydus
tornado党 +1 ,@web.authenticated 好用
正在学习python，收藏了。
我也是这么理解的@frank
C#中没有Annotation，对应的技术应该是Attribute。
感谢楼主分享，学习了
我以前一直深信好的架构能够减少维护成本，不过后来我开始有疑问了。其实不管是开发的人还是维护的人，学习成本是一样的。如果维护的人不能理解设计者的本意，再好的代码也会变成bull shit。所以学习的成本是一样的。
@eleveni386
@login_required 也好用。
= =我昨天面试刚好给人问了什么是Python的Decorator，然后我就回答这其实就是Decorator Pattern的实现。。
我看了stackoverflow的回答（http://stackoverflow.com/questions/8328824/whats-the-difference-between-python-decorators-and-decora...），上面说Python的Decorator是在定义的时候去修改行为，Decorator模式是在运行期修改行为，所以Python的就高阶一点。
但我觉得从本质上来看，两者都是通过Decorator包装原有的，来修改行为，思想是一样的。。
真心求教，期待回答，谢谢！
好文章啊！
不过有一点还不懂，就是使用类方式实现装饰器的时候怎么消除副作用啊，foo.__name__直接就没有了，用@wraps也不行？？？
def __init__(self, fn):
self.fn = fn
self.__name__ = fn.__name__
用这个倒是可以，请教楼主还有更好的方法么？
return “Hello, {}”.format(name)
“Hello, {0}”.format(name)
这样挺酷的。不过有个疑问是，函数本身为何要关注自己如何被decorate，由调用者来决定不是更好，而且不同的调用者可能会有不同的decorate需求。
自习分析了一下，html.py的调用执行流程，发现这个带参数的多个decorator的执行流程和优先级顺序，让人有点费解
defmakeHtmlTag(tag,*args,**kwds):print"Enter the makeHtmlTag ",tag,args,kwdsdefreal_decorator(fn):print"Enter the real_dec"css_class=" class='{0}'".format(kwds["css_class"]) \if"css_class"inkwdselse""print"\tcss_class:"+css_classprint"\tfn.__name__:"+fn.__name__defwrapped(*args,**kwds):print"Enter the warapped",args,kwdsprint"\twarp_fn.__name__:"+fn.__name__print"\tcurrnt css_calss:"+css_classprint"leave the warapped",args,kwdsreturn"" + fn(*args, **kwds) + ""print"leave the real_dec"returnwrappedprint" ........... "print"leave the makeHtmlTag ",tag,args,kwdsreturnreal_decorator@makeHtmlTag(tag="b", css_class="bold_css")@makeHtmlTag(tag="i", css_class="italic_css")defhello():return"hello world"printhello()——————————————————————————————
输出结果如下：
Enter the makeHtmlTag b () {'css_class':'bold_css'}...........leave the makeHtmlTag b () {'css_class':'bold_css'}Enter the makeHtmlTag i () {'css_class':'italic_css'}...........leave the makeHtmlTag i () {'css_class':'italic_css'}Enter the real_deccss_class: class='italic_css'fn.__name__:helloleave the real_decEnter the real_deccss_class: class='bold_css'fn.__name__:wrappedleave the real_decEnter the warapped () {}warp_fn.__name__:wrappedcurrnt css_calss: class='bold_css'leave the warapped () {}Enter the warapped () {}warp_fn.__name__:hellocurrnt css_calss: class='italic_css'leave the warapped () {}<b><i>hello world</i></b>@Tydus
`@gen.coroutine`
更常用吧，否则tornado用着没意思了。。。
同问，能不能同时适用于fn() 与 fn(*args, **kwargs)
赞！！篇篇都是干货！
很棒
解决了困扰我很长时间的疑问，目前为止看过关于decorator解释得最清楚的文章。
defmakeHtmlTag(tag,*args,**kwds):defreal_decorator(fn):css_class=" class='{0}'".format(kwds["css_class"]) \if"css_class"inkwdselse""defwrapped(*args,**kwds):return"" + fn(*args, **kwds) + ""returnwrappedreturnreal_decorator@makeHtmlTag(tag="b", css_class="bold_css")@makeHtmlTag(tag="i", css_class="italic_css")defhello():return"hello world"printhello()上面这段代码，wrapped函数应该没必要传参吧？改成下面这样结果是一样的：
defmakeHtmlTag(tag,*args,**kwds):defreal_decorator(fn):css_class=" class='{0}'".format(kwds["css_class"]) \if"css_class"inkwdselse""defwrapped():return"" + fn() + ""returnwrappedreturnreal_decorator@makeHtmlTag(tag="b", css_class="bold_css")@makeHtmlTag(tag="i", css_class="italic_css")defhello():return"hello world"printhello()来自 http://coolshell.cn/articles/11265.html