投票 - 在此投票给“list-after-def” (是装饰器语法) [英] Poll - Vote here for "list-after-def" (was Decorator syntax)

查看:53
本文介绍了投票 - 在此投票给“list-after-def” (是装饰器语法)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Paul McGuire写道:

请重新考虑def f()[classmethod]:构造。它不是使用特殊的标点字符,而是使用上下文和位置,与熟悉的旧[]一起使用,以注入具有特殊
特征的函数的声明。如果这导致def行的运行时间长于一行,那么可能允许无法匹配的相同规则(带来多条
行而不需要'\连续标记可能是用于无与伦比的
" [" s,如:

def f()[staticmethod,
synchronized,
按字母顺序排列,
超大,
返回(''d'')]:




说得好!


在这里阅读帖子和在python-dev中,我已经计算了以下投票给了它(我很确定有很多

更多,但很难保持关于主题的帖子




投票选择list-after-def语法,如上所示:


Peter Hansen< pe *** @ engcorp.com>

AdSR< ar ********** @ yahoo.com>

Paul McGuire< pt *** @ austin.rr._bogus_.com> m

Phillip J. Eby pje来自Telecommunity.com

C. Barnes< co ************ @ yahoo.com>

Aahz aahz at pythoncraft.com

Skip Montanaro跳过pobox.com

Bill Janssen janssen在parc.com

Istvan Albert ia ***** @mailblocks.com


我觉得这一直是,现在仍然是

最喜欢的。


女士们和男士们,启动你的引擎并团结起来

这种语法(如果你更喜欢它的话)那么就有了

证明它应该被视为一个严肃的候选人。


Istvan。

解决方案

Istvan Albert写道:

Paul McGuire写道:

请重新考虑def f()[classmethod]:构造。




我同意。


@构造是残暴的,*非常* unpythonic。在实现@构造时,我会选择没有

的变化。 list-after-def是

多,多,*多*更好。

Greg Krohn

(我对此感觉比我更强烈做了(做)关于PEP 308.)


解决方案,如果你不喜欢语法,不投票。它是建议Guido接受的

参数,支持你的首选选项。


2004年8月5日星期四22 :39:19 -0400,Istvan Albert

< ia ***** @ mailblocks.com>写道:


女士们和男士们,启动你的引擎并团结起来
这种语法(如果你更喜欢它当然)那么
就是证明它应该被认为是一个严肃的候选人。




+1


我比@语法更喜欢它。


Paul McGuire wrote:

Please reconsider the "def f() [classmethod]:" construct. Instead of
invoking a special punctuation character, it uses context and placement,
with familiar old []''s, to infuse the declaration of a function with special
characteristics. If this causes def lines to run longer than one line,
perhaps the same rule that allows an unmatched "(" to carry over multiple
lines without requiring "\" continuation markers could be used for unmatched
"["s, as in:

def f() [ staticmethod,
synchronized,
alphabetized,
supersized,
returns(''d'') ]:



Well said!

Reading the posts here and in the python-dev I''ve counted
the following votes for it (I''m sure that there were a lot
more but it is awfully hard to keep up with the posts
on the topic).

Voting for the "list-after-def" syntax as shown above:

Peter Hansen <pe***@engcorp.com>
AdSR <ar**********@yahoo.com>
Paul McGuire <pt***@austin.rr._bogus_.com>m
Phillip J. Eby pje at telecommunity.com
C. Barnes <co************@yahoo.com>
Aahz aahz at pythoncraft.com
Skip Montanaro skip at pobox.com
Bill Janssen janssen at parc.com
Istvan Albert ia*****@mailblocks.com

I have the feeling that this always was and still is
the favorite.

Ladies and Gents, start your engines and rally around
this syntax (if you prefer it of course) so that there
is evidence that it should be taken as a serious candidate.

Istvan.

解决方案

Istvan Albert wrote:

Paul McGuire wrote:

Please reconsider the "def f() [classmethod]:" construct.



I concur.

The @ construct is atrocious and *very* unpythonic. I would choose no
changes at all over implementing the @ construct. list-after-def is
much, much, *much* better.
Greg Krohn
(I feel more strongly about this than I did (do) about PEP 308.)


The solution, if you don''t like the syntax, is not voting. It''s to propose an
argument that Guido will accept, in favour of your preferred option.


On Thu, 05 Aug 2004 22:39:19 -0400, Istvan Albert
<ia*****@mailblocks.com> wrote:


Ladies and Gents, start your engines and rally around
this syntax (if you prefer it of course) so that there
is evidence that it should be taken as a serious candidate.



+1

I greatly prefer it over the @ syntax.


这篇关于投票 - 在此投票给“list-after-def” (是装饰器语法)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆