装饰器语法建议的元素 [英] elements of decorator syntax suggestions

问题描述

我认为我们遇到此类问题的最大原因之一就是装饰器语法的任何协议都是每个提案都会产生一些

的语法决策而不只是一个。对于装饰者，我看到

必须做出以下决定：


1）指标

建议因某种排序而有所不同装饰性指标是

使用。这些包括：

* none（例如，只有列表，如def-list-def建议）

*'''''字符

*一个新的关键字（包括，使用，装饰等）


2）位置

建议书的具体位置也有所不同装饰宣言

应该制作。这些包括：

*之前的def

*在def和函数名之间

*在函数名和参数列表之间

*在参数列表和冒号之间

*冒号后（身体的第一行）


3）列表符号

因为我理解它，已经决定

装饰器的任何实现都必须允许应用装饰器列表。所以可能接受的
提案必须说明如何做到这一点。

我见过的选项：

*每行一个（目前）

*仅限逗号

*当前列表语法（或类似的变体）


4）缩进

关于装饰者是否应该引入

新块的建议也不同。我看到了什么：

*没有区块

*区块


我认为上面的摘要可能会有些内容透视所以

当你争论一种或另一种语法时，你可以分别争论

以获得对你最重要的点数。可能是因为我们大多同意，例如，需要一个关键字，或者块

缩进（虽然我当然不会屏住呼吸）。但是我会分别听取不同部分的论据，因为，

在某种程度上，他们非常正交。

如果你只是问自己，好吧，哎呀，史蒂夫，你觉得怎么样？b $ b想想？，=）这里是我对上述各点的看法：


1）指标

我想要一个新关键字。一个单独的列表（无论它放在哪里）

对我来说看起来不像@那样。我希望

某些提示更清晰。我对这个

关键字是​​什么并不挑剔 - ''decorate''似乎是一个合理的建议，但我会对b $ b满意' 'with''或''使用'' - 但我不只是想要

任意符号。我认为从新Python用户的角度来看这是最重要的，他们必须从其他人的代码中猜出

这种语法的含义。使用关键字使

使用清晰，这使得阅读变得更加容易。


2）位置

我不是喜欢在def和函数名称之间或在函数名称

和参数列表之间因为我认为他们更难以看到该函数的

基本签名。请记住，我们必须支持

列表，所以只是坚持一个单词，如staticmethod或

classmethod，不是一个选项 - 否则，我可以有或许看到

def和函数名称之间的优点。


我不是结肠后的忠实粉丝。 （就像文档字符串一样）因为我很可能将这个作为函数定义的一部分来读取。 （事实上​​，这就是我现在要做的事情，所以这是一个语义上的改变，是我宁愿避免的事情之一。 ）


至于在def之前或betwen argument list and colon去（而且我相信这些是主要的竞争者），我可以去任何一种方式 - 和

我在这里真的不是特别的;我宁愿拥有/ some / decorator

语法而不是永远争论这些。 在def之前似乎用具有长名称或参数列表的函数更好地处理
（Guido的

示例让我确信在参数结束时我会感到困惑并且

装饰器启动），但是在参数列表和冒号之间避免

两行定义单一功能问题。呃...就像我说的那样，我不会支持这个 - 我可能会对这两者感到满意。


3）列表符号

我真的不喜欢这里。如果你需要使用多行，我可以看到只有逗号
可能会很痛苦。但是每行一个

或列表语法或对我来说都没问题。


4）缩进

我更喜欢装饰者没有开始新的块，主要是因为

，例如，一个实例方法在不同的块级别上具有''接受''

装饰器，而不是没有

的实例方法。尽管如此，我仍然可以使用缩进的装饰器。

所以总的来说

- > yay关键字！

- >在def之前或结肠之前，和

- >无论列表符号和缩进浮动你的船


=）


史蒂夫

I think one of the biggest reasons we''re having such problems coming
to any agreement on decorator syntax is that each proposal makes a
number of syntax decisions, not just one. For decorators, I see the
following decisions that must be made:

1) Indicator
Proposals differ on how some sort of indicator of "decoratorhood" is
use. These include:
* none (e.g. just the list, as in the "list-after-def" suggestion)
* the ''@'' character
* a new keyword (with, using, decorate, etc.)

2) Location
Proposals also differ on exactly where the decorator declaration
should be made. These include:
* before def
* between def and function name
* between function name and argument list
* between argument list and colon
* after colon (first line in body)

3) List notation
As I understand it, it''s already decided that any implementation of
decorators must allow for a list of decorators to be applied. So
proposals that might be accepted must explain how this can be done.
The options I''ve seen:
* one per line (as currently)
* commas only
* current list syntax (or some similar variant)

4) Indentation
Proposals also differ on whether or not decorators should introduce a
new block. What I''ve seen:
* no block
* block

I thought the summary above might put some things into perspective so
that when you''re arguing for one syntax or another, you can argue
separately for the points that matter most to you. It might be that
we mostly agree on, say, the need for a keyword, or the block
indentation (though I''m certainly not holding my breath). But I''d
rather hear arguments for the different sections separately because,
to some degree, they''re pretty much orthogonal.
In case you were just asking yourself, "well, gee, Steve, what do you
think?", =) here''s what I think for each of the points above:

1) Indicator
I want a new keyword. A list alone (no matter where it''s placed)
doesn''t look any more like a decorator to me than ''@'' does. I want
some sort of cue that reads more clearly. I''m not picky on what this
keyword is -- ''decorate'' seemed like a reasonable proposal, but I''d
even be happy with ''with'' or ''using'' -- but I don''t just want
arbitrary symbols. I think this is most important from the
perspective of new Python users, who will have to guess the meaning of
such syntax from someone else''s code. Having a keyword that makes the
usage clear makes this reading much easier.

2) Location
I don''t like "between def and function name" or "between function name
and argument list" because I think they make it harder to see the
basic signature of the function. Remember that we have to support
lists, so just sticking a in single word, like staticmethod or
classmethod, isn''t an option -- otherwise, I could have perhaps seen
the merit of "between def and function name".

I''m not a big fan of "after colon" (like a doc-string) because I''m
more likely to read this as part of the function definition. (In
fact, that''s what I''d do now, so this is a semantic change, one of the
things I''d rather avoid.)

As far as "before def" or "betwen argument list and colon" go (and I
believe these are the major contenders), I could go either way -- and
I''m really not particular here; I''d rather have /some/ decorator
syntax than argue over these forever. "before def" seems to deal
better with functions that have long names or argument lists (Guido''s
example convinced me that I''d be confused where arguments ended and
decorators started), but "between argument list and colon" avoids the
two-lines-define-a-single-function problem. Eh... Like I say, I''m
not going to argue this one -- I could be happy with either.

3) List notation
I don''t really have a preference here. I can see that commas only
might be a pain if you need to use multiple lines perhaps. But "one
per line" or "list syntax" would both be fine with me.

4) Indentation
I''d prefer that decorators didn''t start a new block mainly because
that makes, for example, an instance method with an ''accepts''
decorator on a different block level than an instance method without
one. Still, I could live with indented decorators.
So in summary
-> yay keywords!
-> before def or before colon, and
-> whatever list notation and indentation floats your boat

=)

Steve

推荐答案

Steven Bethard写道：

Steven Bethard wrote:

总而言之
- > yay关键字！
- >在def之前或结肠之前，
- >任何列表符号和缩进浮动你的船

So in summary
-> yay keywords!
-> before def or before colon, and
-> whatever list notation and indentation floats your boat

好​​帖子，史蒂文，我同意你对

事项的所有意见，如表达的那样以上。


注意我们大多数人在

辩论中对/馅饼（@）语法的一个补充项目。操作顺序。


@语法与def-list之后的顺序相反。我认为

顺序应该从语法中很明显，而且我认为列表语法确实比@语法提供了好处。

我想我想要一个装饰关键字（或等效的），*之前*

定义以避免遮蔽问题，以及

某种清楚显示订单的强制性清单。


有点像，但不一定完全相同，这个：


来自__future__进口装饰


装饰[

foo，

吧，

bletch（垃圾邮件='''baz''）

] < br $>
def func（）：...


唯一的问题是它仍有缺点@其中

装饰似乎没有绑定对函数def非常好

，特别是如果允许空行等等。


我不清楚我认为最好的......但是然后我不介意

当前的方法很多，你只需要在整个功能块之后粘贴

的东西，那么谁在乎我的

意见？ ;-)


-Peter

Good post, Steven, and I agree with all your own opinions on the
matter as expressed above.

Note one addition item that most of us are glossing over in the
debate for/against the pie (@) syntax. Order of operation.

@ syntax has reversed order from the list-after-def. I think
the order should be readily apparent from the syntax, and I
think the list syntax does provide that benefit over the @ syntax.

I think I''d like a "decorate" keyword (or equivalent), *before*
the definition to avoid the problems with obscuration, and a
mandatory list of some kind that clearly shows the order.

Something like, but not necessarily exactly the same as, this:

from __future__ import decoration

decorate [
foo,
bar,
bletch(spam=''baz'')
]
def func(): ...

The only problem is that it still has the defect of @ wherein
the decorate doesn''t seem to "bind" to the function def very
well, especially if blank lines are allowed etc.

I''m unclear on what I think it best... but then I don''t mind
the current approach much at all, where you just stick the
stuff after the entire function block, so who cares about my
opinion? ;-)

-Peter

这是一个很棒的清单！谢谢你这样做。我已经做了几个笔记

内联特定点。


2004年8月6日10:19:21 -0700，Steven Bethard< ; ST ************ @ gmail.com>写道：

This is an excellent list! Thanks for doing it. I''ve made a couple of notes
inline about the particular points.

On 6 Aug 2004 10:19:21 -0700, Steven Bethard <st************@gmail.com> wrote:

我认为我们遇到任何有关装饰器语法协议的问题的最大原因之一就是每个提案都做了很多语法决定，不只是一个。对于装饰者，我看到必须做出以下决定：

1）指标
建议在某种装饰性指标上有所不同。是
使用。这些包括：
* none（例如只是列表，如def-list-def建议）
*'''''字符
*一个新的关键字（带有，使用，装饰等）


这似乎是巨大的。当前（截至几个小时前）

讨论python-dev正在讨论其他替代方案

of @，这有望使IPython或Leo更容易现在应付

（但请注意，将来，@的某些其他用途可能会找到
，所以现在任何依赖它的人都可能会想到

关于那个）。目前的一个建议是使用|而不是。

2）位置
提案也应该在装饰品声明的确切位置上有所不同。这些包括：
*在def
之前

如果某人产生了一个非常强烈的论据而支持

另一种形式，这几乎肯定会发生可以选择。

*在def和函数名之间


打破太多工具，以及习惯于看到的愚蠢人类

def functionname。

*在函数名和参数列表之间


我不确定这是否曾受到任何人的欢迎;）<参数列表和冒号之间的
*


Guido'的排除了这一点（见前面的帖子，我把链接发到了他的帖子

概述了原因。
*冒号后（身体的第一行）


这里的一个问题是与docstrings的互动？


3）列表符号
据我了解，已经决定
装饰器的任何实现都必须允许应用装饰器列表。所以可能接受的建议必须解释如何做到这一点。
我见过的选项：
*每行一个（目前）


关于如何订购每行一件，有一些混乱。我发现

非常明显，但我已经玩了一个星期了，所以它可能只是因为我现在知道答案了。简单 -


@decA

@decB

@decC

def func（）：


相当于


func = decA（decB（decC（func）））

*只逗号


我怀疑解析中的含糊不清。

*当前列表语法（或类似的变体）
4）缩进
关于装饰者是否应该引入新区块的建议也有所不同。我看到了什么：
*没有阻止
*阻止


Guido指出这将导致默认缩进级别

表示装饰方法为3个制表位。我也不喜欢它在视觉上 -

我尝试使用它重新格式化test_decorators，它看起来......很奇怪。

我认为上面的摘要可能会放些东西因此，当你争论一种或另一种语法时，你可以单独争论
以获得对你最重要的点。可能是因为我们大多同意，例如，需要一个关键字，或者块
缩进（虽然我当然不会屏住呼吸）。但是我会分别听取不同部分的论据，因为，在某种程度上，它们几乎是正交的。

I think one of the biggest reasons we''re having such problems coming
to any agreement on decorator syntax is that each proposal makes a
number of syntax decisions, not just one. For decorators, I see the
following decisions that must be made:

1) Indicator
Proposals differ on how some sort of indicator of "decoratorhood" is
use. These include:
* none (e.g. just the list, as in the "list-after-def" suggestion)
* the ''@'' character
* a new keyword (with, using, decorate, etc.)
This is the biggy, it seems. Current (as of a couple of hours ago)
discussions on python-dev are discussing other alternatives instead
of @, that will hopefully make it easier for IPython or Leo to cope
for now (but note that in the future, some other use for @ might be
found, so anyone relying on it at the moment might want to think
about that). One current suggestion is to use the | character, instead.
2) Location
Proposals also differ on exactly where the decorator declaration
should be made. These include:
* before def
Short of someone producing a _very_ strong argument in favour of
another form, this is almost certainly going to be the choice.
* between def and function name
Breaks too many tools, as well as stupid humans who are used to seeing
def functionname.
* between function name and argument list
I''m not sure that this was ever popular, with anyone ;)
* between argument list and colon
Guido''s ruled this out (see previous posts, I put a link to his post
outlining why.
* after colon (first line in body)
A problem here is interaction with docstrings?

3) List notation
As I understand it, it''s already decided that any implementation of
decorators must allow for a list of decorators to be applied. So
proposals that might be accepted must explain how this can be done.
The options I''ve seen:
* one per line (as currently)
There''s some confusion as to how the one-per-line thing is ordered. I find
it quite obvious, but I''ve been playing with this for a week now, so it might
just be that I know the answer now. Simply -

@decA
@decB
@decC
def func():

is equivalent to

func = decA(decB(decC(func)))
* commas only
Too much ambiguity in the parsing, I suspect.
* current list syntax (or some similar variant) 4) Indentation
Proposals also differ on whether or not decorators should introduce a
new block. What I''ve seen:
* no block
* block
Guido pointed out that this would lead to the default indentation level
for a decorated method being 3 tab stops. I also don''t like it visually -
I tried reformatting test_decorators using it, and it looked... strange.
I thought the summary above might put some things into perspective so
that when you''re arguing for one syntax or another, you can argue
separately for the points that matter most to you. It might be that
we mostly agree on, say, the need for a keyword, or the block
indentation (though I''m certainly not holding my breath). But I''d
rather hear arguments for the different sections separately because,
to some degree, they''re pretty much orthogonal.

一个很棒的清单！如果你不介意，我可能会为PEP窃取这种格式。

它允许在更小的空间内覆盖更多的替代品

（从那以后许多提案都是对现有提案的微小变化，并且

共享相同的问题。）

An excellent list! If you don''t mind, I might steal this format for the PEP.
It allows for a lot more alternatives to be covered off in a smaller space
(since many proposals are minor variations on an existing proposal, and
share the same problems).

Anthony Baxter< a ***** ******@gmail.com>写道：

Anthony Baxter <an***********@gmail.com> wrote:

一个很棒的清单！如果你不介意的话，我可能会为PEP窃取这种格式。
它允许在更小的空间内覆盖更多的替代品
（因为许​​多提案是对现有的很小的变化建议，并分享相同的问题。）

An excellent list! If you don''t mind, I might steal this format for the PEP.
It allows for a lot more alternatives to be covered off in a smaller space
(since many proposals are minor variations on an existing proposal, and
share the same problems).

请随意 - 很高兴它有用。 =）非常感谢所有

你的作品已经！


史蒂夫


-

如果你只是动词，你可以将任何字面化。

- Bucky Katt，模糊

Please feel free to -- glad it was helpful. =) Thanks so much for all
your work already!

Steve

--
You can wordify anything if you just verb it.
- Bucky Katt, Get Fuzzy

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