纯粹的情感视角 [英] Purely emotional perspective
问题描述
我只使用了几年的python，但是我每个人都喜欢它。每次发布新版本时，它都包含
改进，增强了可读性和简单性（例如
列表推导，字符串中的子串，......）。而且每次这样的改进
让我更加高兴，因为这正是我在第一名的时候爱上了蟒蛇的原因。
现在来装饰者，引入一个非字母符号（而不是说，一个
新关键字），最糟糕的是为了可读性，他们来*之前*
函数宣称他们应该装饰。
我明白以这种方式做事有一定的技术优势，
但这是我第一次（在我短暂的历史中）与python）已经注意到
可读性因任何原因而被牺牲。这让我悲伤。我觉得
我最喜欢的有机食品决定开始使用防腐剂和
填充物来省钱。
Jeffrey
I have only been using python for a few years, but I have loved it every
step of the way. Each time a new version was released, it contained
improvements that enhanced the readability and feel of simplicity (such as
list comprehensions, substring in string, ...). And each such improvement
delighted me even more, because this is exactly why I loved python in the
first place.
Now come decorators, introducing a non-alphabetic symbol (instead of say, a
new keyword), and worst of all for readability, they come *before* the
function declaration that they supposedly decorate.
I understand that doing things this way has certain technical advantages,
but this is the first time I (in my short history with python) have noticed
readability being sacrificed for any reason. It makes me sad. I feel like
my favorite organic food product decided to start using preservatives and
fillers to save money.
Jeffrey
推荐答案
Jeffrey Froman写道：
[...]
Jeffrey Froman wrote:
[...]
现在来了装饰者，引入一个非字母符号（而不是说，一个新的关键字），最糟糕的是为了可读性，他们来* *他们认为装饰的
函数声明。
我知道以这种方式做事有一定的技术优势，但这是我第一次（在我的python短篇小说中）注意到可读性因任何原因而被牺牲。
Now come decorators, introducing a non-alphabetic symbol (instead of say, a
new keyword), and worst of all for readability, they come *before* the
function declaration that they supposedly decorate.
I understand that doing things this way has certain technical advantages,
but this is the first time I (in my short history with python) have noticed
readability being sacrificed for any reason.
我认为那些推动语法与装饰器*之前*函数
def相信*那种方法*提供了更高的可读性。这个
不是一个关于装饰器是否应该可读的论据，
但是关于什么构成了可读性。显然这很大程度上是一个意见问题。
我认为现在将它们放在def之前可能会是
被那些人看作更具可读性，很大程度上是因为他们根本不习惯装饰者，所以让他们脱颖而出
前面看起来最好。
这就像汽车上的第三个中央刹车灯 -
一旦每辆车都有它们，它们就不再那么突出了
很多，但是现在删除它们已经太晚了。
过了一段时间，当每个人都习惯装饰时，它就不会是b / b $ b非常重要，让他们像这样出路，他们也可以这样，也许更可读（当时），
被移到后面def。
不幸的是，无论我们开始做什么都会坚持下去，所以他们
总是会出现在前面，即使它具有优势
的位置将会消失/>
我说展望未来并意识到经过一段时间的改变后，我们都会有能力发现装饰者，
特别是如果它们仍然是@或|前缀，如果他们在def之后来了
，就像在def-list之后或者在这里：或者是
def func（一些，参数，那， might = span，
multiple = lines）：
| staticmethod
| foobarbaz（x = 5）
| doc（'''''''''''''''''''''''''''''''''''$ $ $ $ $可能会认为这些行在函数体中执行了
，每次都通过。好吧，那些
的人显然没有注意到装饰器的语法，或者读取了关于装饰者的
，所以它们是否重要并不重要
认为，因为他们在这一点上显然不了解
的功能。
了解装饰者的人会知道，与其他一些Python的其他瑕疵一样，它们是在*
函数定义后执行的，而不是在执行时执行。
-Peter
I think those pushing the syntax with decorators *before* the function
def believe that *that approach* provides greater readability. This
isn''t an argument about whether or not decorators should be readable,
but about what constitutes readability. Obviously this is largely a
matter of opinion.
I think putting them before the def right now is probably going to
be seen by those folks as more readable, largely because they are
not used to having decorators at all, so having them stand out right
up front seems best.
This is like the third, center brake light on cars though --
once every car had them, they stopped standing out quite so
much, but it''s too late to remove them now.
After a while, when everyone is used to decorators, it won''t
be important to have them way out front like that, and they
could just as well, and perhaps more readably (at that time),
be moved to after the def.
Unfortunately, whatever we start with will stick, so they
will always be out front even though the advantages of that
position will have evaporated.
I say look to the future and realize that after a period of
adaptation, we''ll all be just as capable of spotting decorators,
especially if they are still @ or | prefixed, if they come
after the def, as in list-after-def or as in this:
def func(some, arguments, that, might=span,
multiple=lines):
| staticmethod
| foobarbaz(x=5)
| doc(''''''A sample function'''''')
# and the body goes here
Yes, I know, people might think those lines are executed
in the body of the function, every time through. Well, those
people obviously didn''t notice the decorator syntax, or read
about decorators, so it''s not important whether or not they
think that, because they clearly won''t understand anything about
the function at this point.
Those who know about decorators will know, as with some of the
other warts of Python, that they are executed *after* the
function is defined, not on execution.
-Peter
Am Montag，2004年8月9日18:03 schrieb Peter Hansen：
Am Montag, 9. August 2004 18:03 schrieb Peter Hansen:
过了一会儿，大家对于装饰者来说，让它们像这样出路并不是很重要，而且它们也可以，也许更可读（当时），
在def之后被移动。
After a while, when everyone is used to decorators, it won''t
be important to have them way out front like that, and they
could just as well, and perhaps more readably (at that time),
be moved to after the def.
我不认为这是真的...装饰者不仅仅是元数据。这是附加到函数的
，它们改变了函数的行为。因此，他们
创建一个不同于声明的函数。
考虑：
def somedecorator（f）：
def fdec（* args，** kwargs）：
返回f（somearg，* args，** kwargs）
返回staticmethod（fdec）
定义：
class x（object）：
def y（some，arg）：
@ somedecorator
< blah>
Versus：
class x（对象）：
@ somedecorator
def y（some，arg）：
< blah>
现在，假设你用某种形式的编辑器折叠了x的主体。在
第一个例子中，@ somedecorator消失了，因为它是函数体的一部分，
在第二个例子中，它保持在（我不想要一个编辑器可以折叠出一个函数的装饰语句，这对于编辑显示前几行很难有点理解。在功能折叠时在功能体内装饰
功能。
捕获的是什么：somedecorator不仅改变功能类型 ;，作为
你会考虑staticmethod或classmethod做，但也改变
函数签名，因为该函数的第一个参数由
$修复b $ b decorator（我实际上有这个用例）。
现在，乍一看你看到的功能非常重要
取一个参数（因为它由somedecorator装饰），这只是
在第二个例子（至少对我的口味来说），如果你知道某个decocorator做了什么，那么很明显。
函数的docstring实际上只是元数据（按我的意思），因此
应保留在函数定义中。
装饰器何时以及如何对该方法执行某些操作对我的口味不重要
（它们是在执行函数定义后执行的），但
明显看到装饰器正在应用于该函数很多
对于第二种语法更容易。
我不会尝试对用于
属性装饰器的角色进行某种形式的辩论，但我'我是@，因为它比...... b $ b更突出。
无论如何，我的2美分......
Heiko。
I don''t think this is true... Decorators are not simply "meta-data" that is
attached to a function, they change the functions behaviour. As such, they
create a different function than the one which is declared.
Consider:
def somedecorator(f):
def fdec(*args,**kwargs):
return f("somearg",*args,**kwargs)
return staticmethod(fdec)
With definitions:
class x(object):
def y(some,arg):
@ somedecorator
<blah>
Versus:
class x(object):
@ somedecorator
def y(some,arg):
<blah>
Now, say you folded out the body of x with some form of decent editor. In the
first example, @somedecorator disappears, as it is part of the function body,
in the second example, it stays in (and I wouldn''t want an editor to fold out
the decorating statements for a function, and it would be kind''a hard to have
a sensible way for the editor to display the first few lines decorating the
function inside the function body while the function is folded out).
What the catch is: somedecorator does not only change the function "type", as
you would consider staticmethod or classmethod do, but also changes the
function signature, as the first argument to the function is fixed by the
decorator (I actually have use cases for this).
Now, it is very important that at first glance you see that the function only
takes one parameter (as it is decorated by somedecorator), and this only
stands out clearly in the second example (at least for my taste), if you know
what somedecorator does, obviously.
The docstring of a function actually is only meta-data (in my taste), and thus
should remain inside the function definition.
When and how decorators do something to the method is unimportant to my taste
(they are executed after the function definition has been executed), but
visibly seeing that the decorator is being applied to the function is much
easier for the second syntax.
I won''t try to throw in some form of debate about the character used to
attribute decorators, but I''m for @, because it stands out much more than |
does.
Anyway, my 2 cents...
Heiko.
Heiko Wundram写道：
Heiko Wundram wrote:
Am Montag，2004年8月9日18:03 schrieb Peter汉森：
Am Montag, 9. August 2004 18:03 schrieb Peter Hansen:
过了一段时间，当每个人都习惯于装饰者时，让他们像这样走出前路并不重要，他们也可以这样做，也许更可读（当时），
被转移到def之后。
我不认为这是真的......装饰者不仅仅是元数据。
附加到一个函数，它们改变了函数的行为。因此，它们创建的函数不同于声明的函数。
考虑：
class x（object）：
def y（some，arg） ：
@ somedecorator
< blah>
Versus：
class x（对象）：
@ somedecorator
def y（some，arg）：
< blah>
现在，假设你用某种形式的编辑器折叠了x的主体。在第一个例子中，@ somedecorator消失了，因为它是函数体的一部分，
After a while, when everyone is used to decorators, it won''t
be important to have them way out front like that, and they
could just as well, and perhaps more readably (at that time),
be moved to after the def.
I don''t think this is true... Decorators are not simply "meta-data" that is
attached to a function, they change the functions behaviour. As such, they
create a different function than the one which is declared.
Consider:
class x(object):
def y(some,arg):
@ somedecorator
<blah>
Versus:
class x(object):
@ somedecorator
def y(some,arg):
<blah>
Now, say you folded out the body of x with some form of decent editor. In the
first example, @somedecorator disappears, as it is part of the function body,
实际上，第一个例子也可能就是这个：
def y（some，arg）
@ somedecorator
：
< blah> ;
但我可以听到反对的论点，就像我喜欢它一样。
在第二个例子中，它留在（我不会'我不想要一个编辑器来折叠一个函数的装饰语句，并且很难让编辑器显示前几行装饰的合理方式。折叠功能时功能体内部的功能）。
我想*如果我习惯使用折叠式编辑器，我会*喜欢将装饰器折叠起来。但是我很确定这不会很难
避免折叠紧跟在下面的@线条，或者就此而言：
就在它之前。这里真正的问题（不是让我困扰）
是很多编辑可能与以下内容相关联：
紧跟在参数列表之后的东西，所以他们可能会重做
来处理预冒号装饰器。
函数的文档字符串实际上只是元数据（按照我的口味），并且因此
应该保留在函数定义中。
这个论点对我没用。为什么任何元数据都在内部？b $ b函数体？应该有一个地方可以定义所有
元数据，并且它应该始终如一地用于所有内容，包括
docstrings。 （馅饼语法学家正朝着这个方向前进，它似乎是
。）
装饰者何时以及如何对该方法做些什么对我来说并不重要
（他们在执行函数定义之后执行），但是明显看到装饰器正在应用于函数对于第二种语法来说更容易。
Actually, the first example could just as well have been this:
def y(some, arg)
@ somedecorator
:
<blah>
But I can just hear the arguments against that, much as I like it.
in the second example, it stays in (and I wouldn''t want an editor to fold out
the decorating statements for a function, and it would be kind''a hard to have
a sensible way for the editor to display the first few lines decorating the
function inside the function body while the function is folded out).
I *would* like decorators to be folded, I think, if I were in the habit
of using folding editors. But I''m fairly sure it wouldn''t be hard to
avoid folding @ lines that immediately follow the :, or for that matter
that come just before it. The real issue here (not that it bothers me)
is that a lot of editors are probably tied to the idea that the : comes
right after the argument list or something, so they probably would have
to be redone to handle pre-colon decorators.
The docstring of a function actually is only meta-data (in my taste), and thus
should remain inside the function definition.
This argument makes no sense to me. Why should any meta-data be inside
the function body? There should probably be one place where all
meta-data is defined, and it should be used consistently for everything,
docstrings included. (The pie-syntaxians are heading that way, it
seems.)
When and how decorators do something to the method is unimportant to my taste
(they are executed after the function definition has been executed), but
visibly seeing that the decorator is being applied to the function is much
easier for the second syntax.
说实话，我觉得我更喜欢目前的方法，
功能在*定义之后明确地，明确地装饰*
并且不需要新的语法。
Python显然是一个巨大的进化浪潮和保守的观点
现在肯定没有赢得胜利。通常的
参数（提交补丁！）并不是真的有用的时候那些想要b / b
避免很多变化试试吧...我去过*不是*提交补丁对于
对Python进行了大量更改，但不知怎的，它从未被接受过。 ;-)
-Peter
To tell the truth, I think I prefer the current approach, where the
function is clearly, explicitly decorated *after* it has been defined,
and no new syntax is required.
Python is clearly on a huge evolutionary surge and conservative views
on the matter are definitely not winning out right now. And the usual
argument (submit a patch!) doesn''t really work when those who want to
avoid many changes try it... I''ve been *not* submitting a patch on
lots of changes to Python, but somehow it''s never been accepted. ;-)
-Peter
这篇关于纯粹的情感视角的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
