@decorators

" 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 firsttime that two logical lines of python with the same indentation willnot 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 whatthe second line meant/did (and vice versa). It would seem that thecases when there are effects across multiple logical lines is capturedin compound statements: """Compound statements contain (groups of) other statements; they affector 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 decoratorsare intended to be a compound statement themselves, or whether theyare meant to simply be extensions of current compound statementssuch 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 endswith a colon. A suite ... can be one or more indented statements onsubsequent 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 tobe spelled ''@'' is not important to me.) In the second case where decorators are simply extensions of currentcompound statements, the current wording of the Python ReferenceManual would seem to imply that for function definition the clauseheader must begin with ''def''. I.e., the decorator should not comebefore the def, and certainly not on a separate line. Beyond this,however, for me it is not particularly important whether thedecorator comes before/after the function name/argument list, andhow it is delimited. I guess the basic point that I am trying to make is that what I findimportant is consistency with the basic visual layout of code promised(IMHO) by python. I believe that this promise is violated by thecurrently proposed decorator scheme. d PS: Although I believe the current view of the implementors is to viewdecorators as an extension to function definition, I believe that theseparate compound statement view is fairly rich. As others have noted,it can make identical decorations simpler: @static,synchronized:def foo():passdef 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(): passI like this idea. What about using the list syntax instead of the @ syntax: [decorator]:def foo():pass [static, synchronized]:def foo():passdef 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 defbeing 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():passdef bar():pass Now that looks pretty neat David"daishi" <go****@daishi.fastmail.fm> wrote in messagenews: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 - finallyif - elif - elsewhile - else John Roth"daishi" <go****@daishi.fastmail.fm> wrote in messagenews: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的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！