@decorators [英] @decorators
问题描述
对于它的价值：
据我所知，建议的@decorator语法将是第一个
时间，两个逻辑具有相同缩进的python线将不会彼此独立。以前，当看：
some_python（代码）
and_some_more =东西
没有必要看看第一行是为了知道第二行意味着/做了什么（反之亦然）。似乎在多个逻辑行中存在效果的情况下，
在复合语句中被捕获
：
" "
复合语句包含（组）其他语句;它们影响
或以某种方式控制其他陈述的执行。
""" -Python参考手册
我对装饰器的理解是它们符合这个定义。
我不太清楚的一件事是装饰器是否适用于>
本身就是一个复合语句，或者它们是否只是b $ b只是当前复合语句的扩展
如函数定义（和类）定义？）
但是，在任何一种情况下，似乎都应适用以下内容：
"""
每个子句标题以唯一标识关键字开头，并以冒号结束
。套件......可以是
后续行中的一个或多个缩进语句。
""" -Python参考手册
在装饰者形成他们自己的复合语句的第一种情况下，
这似乎意味着基本布局：
@decorator：
def foo（）：
通过
（是否唯一识别装饰器的关键字碰巧是
拼写''''对我来说并不重要。）
在第二种情况下装饰器只是当前的扩展
复合语句，Python参考的当前措辞
手册似乎意味着对于函数定义，子句
header必须以''开头' '变形点焊。也就是说，装饰者不应该在def之前来到
，当然不是单独的一行。除此之外，
然而，对我来说，
装饰器是在函数名/参数列表之前/之后是不是特别重要，并且
它是如何划界的。
我想我想要的基本点是我发现
重要的是与基本视觉布局的一致性代码承诺
（恕我直言）由python。我相信这个承诺违反了
目前提议的装饰计划。
d
PS：虽然我相信当前实现者的观点是查看
装饰器作为函数定义的扩展，我相信
单独的复合语句视图相当丰富。正如其他人所说，
它可以使相同的装饰更简单：
@ static，synchronized：
def foo（）：
通过
def bar（）：
通过
< blockquote> daishi写道：
为了它的价值：
据我所知，建议的@decorator语法将是第一个
时间具有相同缩进的两条python逻辑行将不会彼此独立。以前，当看到：
some_python（代码）
and_some_more =东西
没有必要查看第一行以了解<第二行意味着/做了（反之亦然）。似乎在复合语句中捕获了多个逻辑行中存在效果的情况：
"""
复合语句包含（其他陈述;他们以某种方式影响
或控制其他陈述的执行。
""" -Python参考手册
我对装饰器的理解是它们符合这个定义。
我不太清楚的一件事是装饰器
是否意图是复合语句他们自己，或者他们是否只是简单地扩展当前的复合语句
如函数定义（和类定义？）
在任何一种情况下，它似乎都是以下内容应适用：
"""
每个子句标题以唯一标识关键字开头，并以冒号结束
。套件......可以是
后续行中的一个或多个缩进语句。
""" -Python参考手册
在装饰者形成自己的复合语句的第一种情况下，这似乎意味着基本的布局：
@decorator：
def foo（）：
传递
（对装饰器来说，唯一标识关键字是否拼写为''''对我来说并不重要。）
在第二种情况下，装饰器只是当前复合语句的扩展，Python参考手册的当前措辞似乎暗示对于函数定义，子句
标题必须以''def''开头。即，装饰者不应该在def之前来，而且肯定不是在单独的一行。除此之外，
然而，对我而言，
装饰器是在函数名称/参数列表之前/之后，以及它是如何分隔的并不是特别重要。
我想我想要提出的基本观点是，我发现重要的是与python承诺的代码的基本视觉布局的一致性（恕我直言）。我相信目前提出的装饰方案违反了这一承诺。
PS：虽然我相信实施者的当前观点是查看<装饰器作为函数定义的扩展，我相信单独的复合语句视图相当丰富。正如其他人所说，
它可以使相同的装饰更简单：
@静态，同步：
def foo（）：
传递
def bar（ ）：
传递
我喜欢这个主意。如何使用列表语法而不是@语法：
[decorator]：
def foo（）：
pass
[静态，同步]：
def foo（）：
通过
def bar （）：
传递
[静态，
同步，
类型（int，int ），
返回（无）
]：
def foo（）：
通过
这会在def
为有效python之前取消对有效列表的参数但以前没有任何效果......
或者你可以添加一个关键字：
声明[静态，同步，类型（int，int），返回（无）]：
def foo（）：
通过
def bar（）：
通过
现在看起来很整洁
David
" daishi" <去**** @ daishi.fastmail.fm>在消息中写道
news：d2 ************************** @ posting.google.c om ...对于它的价值：
据我所知，建议的@decorator语法将是第一个两个python逻辑行的时间使用相同的缩进将不会彼此独立。
示例：
尝试 - 除外 - 最后
if - elif - 否则
而其他 -
John Roth
" daishi" <去**** @ daishi.fastmail.fm>在消息中写道
news：d2 ************************** @ posting.google.c om ...对于它的价值：
据我所知，建议的@decorator语法将是第一个两个python逻辑行的时间同样的缩进将不会彼此独立。以前，在查看：
我认为@decorator语法是微软为破坏Python而发明的，
Tom
For what it''s worth:
As far as I know, the proposed @decorator syntax will be the first
time that two logical lines of python with the same indentation will
not be independent of one another. Previously, when looking at:
some_python(code)
and_some_more = stuff
there was no need to look at the the first line in order to know what
the second line meant/did (and vice versa). It would seem that the
cases when there are effects across multiple logical lines is captured
in compound statements:
"""
Compound statements contain (groups of) other statements; they affect
or control the execution of those other statements in some way.
""" -Python Reference Manual
My understanding of decorators is that they fit this definition.
One thing that I am not entirely clear about is whether decorators
are intended to be a compound statement themselves, or whether they
are meant to simply be extensions of current compound statements
such as function definition (and class definitions?)
In either case, however, it seems that the following should apply:
"""
Each clause header begins with a uniquely identifying keyword and ends
with a colon. A suite ... can be one or more indented statements on
subsequent lines.
""" -Python Reference Manual
In the first case where decorators form their own compound statement,
this would seem to imply the basic layout of:
@decorator:
def foo():
pass
(Whether that uniquely identifying keyword for decorators happens to
be spelled ''@'' is not important to me.)
In the second case where decorators are simply extensions of current
compound statements, the current wording of the Python Reference
Manual would seem to imply that for function definition the clause
header must begin with ''def''. I.e., the decorator should not come
before the def, and certainly not on a separate line. Beyond this,
however, for me it is not particularly important whether the
decorator comes before/after the function name/argument list, and
how it is delimited.
I guess the basic point that I am trying to make is that what I find
important is consistency with the basic visual layout of code promised
(IMHO) by python. I believe that this promise is violated by the
currently proposed decorator scheme.
d
PS: Although I believe the current view of the implementors is to view
decorators as an extension to function definition, I believe that the
separate compound statement view is fairly rich. As others have noted,
it can make identical decorations simpler:
@static,synchronized:
def foo():
pass
def bar():
pass
daishi wrote:For what it''s worth:
As far as I know, the proposed @decorator syntax will be the first
time that two logical lines of python with the same indentation will
not be independent of one another. Previously, when looking at:
some_python(code)
and_some_more = stuff
there was no need to look at the the first line in order to know what
the second line meant/did (and vice versa). It would seem that the
cases when there are effects across multiple logical lines is captured
in compound statements:
"""
Compound statements contain (groups of) other statements; they affect
or control the execution of those other statements in some way.
""" -Python Reference Manual
My understanding of decorators is that they fit this definition.
One thing that I am not entirely clear about is whether decorators
are intended to be a compound statement themselves, or whether they
are meant to simply be extensions of current compound statements
such as function definition (and class definitions?)
In either case, however, it seems that the following should apply:
"""
Each clause header begins with a uniquely identifying keyword and ends
with a colon. A suite ... can be one or more indented statements on
subsequent lines.
""" -Python Reference Manual
In the first case where decorators form their own compound statement,
this would seem to imply the basic layout of:
@decorator:
def foo():
pass
(Whether that uniquely identifying keyword for decorators happens to
be spelled ''@'' is not important to me.)
In the second case where decorators are simply extensions of current
compound statements, the current wording of the Python Reference
Manual would seem to imply that for function definition the clause
header must begin with ''def''. I.e., the decorator should not come
before the def, and certainly not on a separate line. Beyond this,
however, for me it is not particularly important whether the
decorator comes before/after the function name/argument list, and
how it is delimited.
I guess the basic point that I am trying to make is that what I find
important is consistency with the basic visual layout of code promised
(IMHO) by python. I believe that this promise is violated by the
currently proposed decorator scheme.
d
PS: Although I believe the current view of the implementors is to view
decorators as an extension to function definition, I believe that the
separate compound statement view is fairly rich. As others have noted,
it can make identical decorations simpler:
@static,synchronized:
def foo():
pass
def bar():
pass
I like this idea. What about using the list syntax instead of the @ syntax:
[decorator]:
def foo():
pass
[static, synchronized]:
def foo():
pass
def bar():
pass
[static,
synchronized,
types(int, int),
returns(None)
]:
def foo():
pass
This would then take away the argument against a valid list before a def
being valid python but not previously having any effect...
Or for good measure you could add a keyword:
declare [static, synchronized, types(int, int), returns(None)]:
def foo():
pass
def bar():
pass
Now that looks pretty neat
David
"daishi" <go****@daishi.fastmail.fm> wrote in message
news:d2**************************@posting.google.c om...For what it''s worth:
As far as I know, the proposed @decorator syntax will be the first
time that two logical lines of python with the same indentation will
not be independent of one another.
Examples:
try - except - finally
if - elif - else
while - else
John Roth
"daishi" <go****@daishi.fastmail.fm> wrote in message
news:d2**************************@posting.google.c om...For what it''s worth:
As far as I know, the proposed @decorator syntax will be the first
time that two logical lines of python with the same indentation will
not be independent of one another. Previously, when looking at:
I think the @decorator syntax was invented by Microsoft to sabotage Python,
Tom
这篇关于@decorators的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
