对pep 318感到困惑 [英] Confused about pep 318

问题描述

大家好，


首先，我现在的心态重新开始318是一种羞怯的混淆。我怀疑pep 318不会显着影响Leo，但是我很惊讶在一个明显有争议的功能被添加

而没有通知，比如说，在comp.lang中。 python.announce。我说羞怯，

，因为每个人都知道应该确保新的提议不要咬你好。尽管如此，我还是认为除了阅读py-dev之外，还有其他方法可以保持对Python的潜在重大变化，并且... b / b
以下对py-dev上的最新帖子有一些评论。我希望通过这些评论来表达我的困惑。

再次审阅所有相同的论点并再次
。对于这个alpha版本，任何数量的争论都不会改变

的承诺。如果你想在2.4之前改变

语法，你真的必须组织公众抗议。 [Martin v.L？wis]


我想推迟一个公众哗然的问题。直到以后，希望

以后。


但是我不知道提出的语法是什么（!!）特别是有

没有直接在页面上提及''@'
http://www.python.org/peps/pep-0318.html


是否有近期工作的摘要？公告？

共识的一些迹象？

总的来说，我预测大多数Python代码将继续幸福

装饰精美。

对。在测试套件之外，很少使用classmethod，
staticmethod和标准库中的属性。 GvR


嗯...我在pep 318中看到没有提到pep会影响

以下参考手册的部分：
http://docs.python.org/ref/delimiters.html


[quote]

Python中不使用以下打印ASCII字符。他们在字符串文字和评论之外发生的
是无条件错误：

@ $？

[end quote]

我认为对这一段的任何修改都是对Python的一个重大改变，尽管它是无辜的外观。事实上，这一段是一个很好的

在沙滩上划线。对于其他工具。


重复一遍，我怀疑添加@不会直接影响任何

直接方式，并且即使它可能存在解决方法没有。但是，

这个提议可能会影响leo

（松散）的noweb标记语言。请参阅 http://www.eecs.harvard.edu/~nr/ noweb /


BTW，很久以前我建议解析器

没有理由在if之后需要冒号回复是：真的，但是允许克隆冒号的b / b $ b $会影响现有的工具。所以我放弃了。我是第一个建议允许在有效的Python程序中使用''''字符

以外的字符串文字和注释可能会对现有工具产生负面影响吗？

叹气。这个讨论在毫无意义的圈子里进行;我们是
*月*过了那一点。你在浪费你的时间（和我的）。 [GvR]


我承认我根本不理解这句话。怎么会发生这么多人对这个提议感到困惑？

如果一切都如此清晰，为什么pep 318本身没有反映清晰度呢？

http://www.python.org/peps/pep-0318.html 谈论

- 背景

- 设计目标

- 建议语法（不提及@！）

- 替代提案
等


打扰一下，但如果现在一切都是一成不变的，那么这是一个非常误导性的文件。
>
对不起。我认为你应该明智地考虑没有达成共识的几个月

问题的证据。 [Jim Fulton]


这也是我现在的意见。


摘要


我希望否认任何知识，或任何对更广泛问题的兴趣，无论是否是一个好主意。我关心的是两个问题后面的

：


1. IMO，在有效的Python程序中允许''@''（在字符串文字之外或

评论）是对语言的一个重大改变，它具有很大的潜力，可以破坏已有的工具。至少，有一些讨论
http：// docs。 python.org/ref/delimiters.html 应该在第318页。


2. pep 318显然不能反映目前的状况，并且

afaik没有公布有关

comp.lang.python.announce的建议更改。这令人不安。如果有人能澄清pep 318的现状，我将非常感激。我宁愿不要告诉他们阅读所有py-dev档案。如果现在一切都清楚了，

我可以找到它吗？


爱德华

------- -------------------------------------------------- -----------

Edward K. Ream电子邮件： ed *** ****@charter.net

狮子座：带轮廓的文盲编辑器

狮子座： http://webpages.charter.net/edreamleo/front.html

----- -------------------------------------------------- -------------

解决方案

？

[end quote]


我认为对这一段的任何修改都是对Python的一个重大改变，尽管它是无辜的外表。事实上，这一段是一个很好的

在沙滩上划线。对于其他工具。


重复一遍，我怀疑添加@不会直接影响任何

直接方式，并且即使它可能存在解决方法没有。但是，

这个提议可能会影响leo

（松散）的noweb标记语言。请参阅 http://www.eecs.harvard.edu/~nr/ noweb /


BTW，很久以前我建议解析器

没有理由在if之后需要冒号回复是：真的，但是允许克隆冒号的b / b $ b $会影响现有的工具。所以我放弃了。我是第一个建议允许在有效的Python程序中使用''''字符

以外的字符串文字和注释可能会对现有工具产生负面影响吗？

叹气。这个讨论在毫无意义的圈子里进行;我们是
*月*过了那一点。你在浪费你的时间（和我的）。 [GvR]


我承认我根本不理解这句话。怎么会发生这么多人对这个提议感到困惑？

如果一切都如此清晰，为什么pep 318本身没有反映清晰度呢？

http://www.python.org/peps/pep-0318.html 谈论

- 背景

- 设计目标

- 建议语法（不提及@！）

- 替代提案
等


打扰一下，但如果现在一切都是一成不变的，那么这是一个非常误导性的文件。
>
对不起。我认为你应该明智地考虑没有达成共识的几个月

问题的证据。 [Jim Fulton]


这也是我现在的意见。


摘要


我希望否认任何知识，或任何对更广泛问题的兴趣，无论是否是一个好主意。我关心的是两个问题后面的

：


1. IMO，在有效的Python程序中允许''@''（在字符串文字之外或

评论）是对语言的一个重大改变，它具有很大的潜力，可以破坏已有的工具。至少，有一些讨论
http：// docs。 python.org/ref/delimiters.html 应该在第318页。


2. pep 318显然不能反映目前的状况，并且

afaik没有公布有关

comp.lang.python.announce的建议更改。这令人不安。如果有人能澄清pep 318的现状，我将非常感激。我宁愿不要告诉他们阅读所有py-dev档案。如果现在一切都清楚了，

我可以找到它吗？


爱德华

------- -------------------------------------------------- -----------

Edward K. Ream电子邮件： ed *** ****@charter.net

狮子座：带轮廓的文盲编辑器

狮子座： http://webpages.charter.net/edreamleo/front.html

----- -------------------------------------------------- -------------

Edward>但是我不知道提出的语法是什么（!!）在

Edward>特别是，没有直接在页面上提到''@'

Edward> http://www.python.org/peps/pep-0318。 html


Anthony Baxter昨天在python-dev上表示，他很快就会参加那个

。与许多其他软件工作一样，代码比文档更快地移动了一点（毕竟，做什么更有趣？）。我认为，与纯粹的功能性应用于PEP的唯一显着区别是

装饰类的语法和问题（我不认为对装饰课程的支持将会产生

）。通过并行示例，这里的新语法如何对应于我在PEP的最新版本中使用的语法：


＃1来自PEP：鉴于此功能：


def onexit（f）：

import atexit

atexit.register（f）

返回f


新语法将是：


@onexit

def func（）：

...

来自PEP的
＃4：鉴于以下功能：


def接受（*类型）：

def check_accepts（f）：

断言len（类型）== f.func_code.co_argcount

def new_f （* args，** kwds）：
$（b，b）in zip（args，types）：

断言isinstance（a，t），\

" arg％r与％s不匹配" ％（a，t）

返回f（* args，** kwds）

返回new_f

返回check_accepts


def return（rtype）：

def check_returns（f）：

def new_f（* args，** kwds）：

result = f（* args，** kwds）

断言isinstance（结果，rtype），\

"返回值％r不匹配％ S" ％（结果，rtype）

返回结果

返回new_f

返回check_returns


新语法将是：


@accepts（int，（int，float））

@returns（（int，float））

def func（arg1，arg2）：

返回arg1 * arg2


我相信以上装饰器的应用顺序如下： br />

func =接受（int，（int，float））（返回（（int，float））（func）


Edward> I承认我根本不理解这句话。爱德华>怎么会发生这么多人对此感到困惑

Edward>提议？如果一切是如此清晰，为什么不清晰

Edward>反映在pep 318本身？


有很多关于python-dev的讨论，但是最近没有（最后一个月大约两个月）。圭多在那里表示他在主题演讲和娱乐中提出了这个话题。

EuroPython现场讨论。

根据讨论，他决定采用@ -decorator语法。

自EuroPython以来，大多数/所有讨论都在私人电子邮件或在

irc。我认为如果这个对话在

PEP中进行了总结会很好，但这必须来自其中一位参与者。


Skip

>与许多其他软件工作一样，代码已经比文档更快地移动了一下

（毕竟，做什么更有趣？）。
.... Guido在那里表示，他在主题演讲中提出了关于EuroPython的话题，并在场上进行了讨论。
根据讨论，他决定选择@ - 装饰器语法。


嗯，这不好。我们在这里谈论一个基本的设计文件。

我觉得我一直被困在黑暗中;我之前的相对沉默是

几乎没有我同意的证据。怎么可能假装人们b / b $ b同意不存在的提案？我现在在派对318上是-10：这个
过程相当于操纵选举。我可能会在将来变得中立

一旦从候选人头上移开引擎盖:-)

我相信与纯功能的唯一显着差异<应用于PEP的文档立场是语法

为什么壮观的东西？喜欢@符号需要吗？大概是
编译器有问题吗？有没有人建议

喜欢：


来自__future__ import annotation作为注释


annotate.accepts（int， （int，float））


而不是：


@accepts（int，（int，float））


显然，如果有足够的工作，Python编译器就能识别出这一点。是的，

这是一个特例，但那又怎么样？这将避免大多数问题与

保留字或关键字。它本着让

模块封装大多数主要功能的精神。


爱德华


P.S.我越想到这个提议，我就越不开心。事实上，这个建议可能会对狮子座的未来造成最不幸的影响，因为两个原因是：

1.虽然Leo处理像@accepts这样的结构，但它通过生成

这样的行来实现：


＃@ verbatim

@accepts（int，（int，float））


所以_Leo_没有问题，但Leo'的用户可能会抱怨更多

cruft已经已被添加到他们的文件中。


2. Leo目前支持以下指令：


@（后跟一个或多个空白字符）

@all，@asis，

@c，@ code，@ color，@ comment，

@delims，@ doc，
@encoding，@ end_raw，

@file，@ first，

@header，

@ignore，
@killcolor，

@language，@ pop，@ lineending，

@nocolor，@ noheader，@ noref，@ nosent，@ nowrap，

@others，

@pagewidth，@ path，

@quiet，

@raw，

@roo t，@ root-code，@ root-doc，

@silent，

@tabwidth，@terse，@ first，

@unit ，

@verbose，

@wrap


更糟糕的是，Leo允许插件定义自己的指令。已经有一个定义@wiki的插件

。此外，@ run，@ test和@suite也是在特殊情况下使用的
。


当另一个Python @x构造与其中一个构件发生冲突时会发生什么

指令或其他一些指令？我开始怀疑Python

是蛇还是大猩猩:-)


是的，Python确实有权使用''@ ''。但我希望GvR能够选择不这样做。我一直认为参考手册中的明确

声明在符号无处不在

（评论和字符串除外）是一个明确的意图信号保留

这些符号用于其他有效目的。我非常不高兴这个

可能不是这样。


P.P.S.我之前对所要求的调查作出了回应，简单地说，

我没有318的问题，前提是''''标志没有成为

的一部分句法。我没有收到任何人的回复。某人

无法将我之前的陈述解释为批准。


EKR

-------- -------------------------------------------------- ----------

Edward K. Ream电子邮件： ed **** ***@charter.net

Leo：包含轮廓的文盲编辑器

Leo： http://webpages.charter.net/edreamleo/front.html

------ -------------------------------------------------- ------------

Hello all,

First of all, my present state of mind re pep 318 is one of sheepish
confusion. I suspect pep 318 will not affect Leo significantly, but I am
most surprised that an apparently controversial feature is being added
without a notice, say, in comp.lang.python.announce. I say sheepish,
because everyone knows that one should make sure new proposals don''t bite
you. Still, I would have thought that there were other ways of keeping
abreast of potentially major changes to Python besides reading py-dev...

The following are some comments to recent posts on py-dev. I hope to convey
by these remarks my sense of bewilderment.

There is little point in going over all the same arguments again and again. For this alpha release, no amount of arguing will change what has
been committed. You really have to organize a public outcry if you want the
syntax changed before 2.4. [Martin v. L?wis]

I''d like to defer the question of a "public outcry" until later, hopefully
much later.

But I have no idea what the proposed syntax is(!!) In particular, there is
no mention of ''@'' directly on the page
http://www.python.org/peps/pep-0318.html

Is there a summary of recent work? An announcement? Some indication of
consensus?

In general, I predict most Python code will continue to be blissfully

unadorned with decorators.
Right. Outside the test suite, there are very few uses of classmethod, staticmethod and property in the standard library. GvR

Hmm... I see nowhere in pep 318 any mention that the pep will affect the
following section of the Reference manual:
http://docs.python.org/ref/delimiters.html

[quote]
The following printing ASCII characters are not used in Python. Their
occurrence outside string literals and comments is an unconditional error:
@ $ ?
[end quote]

I would regard any change to this paragraph as a major change to Python, in
spite of its innocent appearance. Indeed, this paragraph is an excellent
"line in the sand" for other tools.

To repeat, I suspect adding @ would not affect Leo significantly in any
direct way, and a workaround would probably exist even if it did. However,
this proposal probably would affect the noweb markup language on which Leo
is (loosely) based. See http://www.eecs.harvard.edu/~nr/noweb/

BTW, a long while back I suggested that there was no reason for the parser
to need colons after "if" statements, etc. The response was: true, but
allowing colons to be elided would impact existing tools. So I gave up. Am
I the first to suggest that allowing ''@'' characters in valid Python programs
outside string literals and comments might negatively impact existing tools?
Sigh. This discussion is going around in pointless circles; we''re *months* past that point. You''re wasting your time (and mine). [GvR]

I confess that I don''t understand this remark at all. How has it happened
that so many people are confused about this proposal? And if everything is
so clear, why isn''t the clarity reflected in pep 318 itself?

http://www.python.org/peps/pep-0318.html talks about

- Background
- Design goals
- Proposed syntax (no mention of @!)
- Alternative proposals
etc.

Excuse me, but if everything is now set in stone, then this is an
extraordinarily misleading document.
Sorry. I think you''d be wise to consider the months without consensus as

evidence of a problem. [Jim Fulton]

This is my present opinion as well.

Summary

I wish to disavow any knowledge, or any interest in, the wider issues of
whether pep 318 is a good idea or not. My concern is exclusively with the
following two issues:

1. IMO, allowing ''@'' in valid Python programs (outside string literals or
comments) is a major change to the language that has significant potential
to disrupt already existing tools. At the very least, some discussion of
http://docs.python.org/ref/delimiters.html should be in pep 318.

2. pep 318 apparently does not reflect the present state of affairs, and
afaik there has been no announcement of proposed changes on
comp.lang.python.announce. This is disturbing. If anyone could clarify the
present status of pep 318 I would be most grateful. I would prefer not to
be told to read all the py-dev archives. If everything is now clear, where
can I find out about it?

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

解决方案

?
[end quote]

I would regard any change to this paragraph as a major change to Python, in
spite of its innocent appearance. Indeed, this paragraph is an excellent
"line in the sand" for other tools.

To repeat, I suspect adding @ would not affect Leo significantly in any
direct way, and a workaround would probably exist even if it did. However,
this proposal probably would affect the noweb markup language on which Leo
is (loosely) based. See http://www.eecs.harvard.edu/~nr/noweb/

BTW, a long while back I suggested that there was no reason for the parser
to need colons after "if" statements, etc. The response was: true, but
allowing colons to be elided would impact existing tools. So I gave up. Am
I the first to suggest that allowing ''@'' characters in valid Python programs
outside string literals and comments might negatively impact existing tools?
Sigh. This discussion is going around in pointless circles; we''re *months* past that point. You''re wasting your time (and mine). [GvR]

I confess that I don''t understand this remark at all. How has it happened
that so many people are confused about this proposal? And if everything is
so clear, why isn''t the clarity reflected in pep 318 itself?

http://www.python.org/peps/pep-0318.html talks about

- Background
- Design goals
- Proposed syntax (no mention of @!)
- Alternative proposals
etc.

Excuse me, but if everything is now set in stone, then this is an
extraordinarily misleading document.
Sorry. I think you''d be wise to consider the months without consensus as

evidence of a problem. [Jim Fulton]

This is my present opinion as well.

Summary

I wish to disavow any knowledge, or any interest in, the wider issues of
whether pep 318 is a good idea or not. My concern is exclusively with the
following two issues:

1. IMO, allowing ''@'' in valid Python programs (outside string literals or
comments) is a major change to the language that has significant potential
to disrupt already existing tools. At the very least, some discussion of
http://docs.python.org/ref/delimiters.html should be in pep 318.

2. pep 318 apparently does not reflect the present state of affairs, and
afaik there has been no announcement of proposed changes on
comp.lang.python.announce. This is disturbing. If anyone could clarify the
present status of pep 318 I would be most grateful. I would prefer not to
be told to read all the py-dev archives. If everything is now clear, where
can I find out about it?

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

Edward> But I have no idea what the proposed syntax is(!!) In
Edward> particular, there is no mention of ''@'' directly on the page
Edward> http://www.python.org/peps/pep-0318.html

Anthony Baxter said yesterday on python-dev he was going to attend to that
shortly. As in many other software efforts, the code has moved along a bit
faster than the documentation (after all, what''s more fun to do?). I
believe the only significant differences from a pure functional
documentation standpoint to apply to the PEP are the syntax and the issue of
decorated classes (I don''t think support for decorated classes will make
it). By way of parallel examples here''s how the new syntax corresponds to
the syntax I used in the last revision of the PEP:

#1 from the PEP: Given this function:

def onexit(f):
import atexit
atexit.register(f)
return f

the new syntax will be:

@onexit
def func():
...

#4 from the PEP: Given these functions:

def accepts(*types):
def check_accepts(f):
assert len(types) == f.func_code.co_argcount
def new_f(*args, **kwds):
for (a, t) in zip(args, types):
assert isinstance(a, t), \
"arg %r does not match %s" % (a,t)
return f(*args, **kwds)
return new_f
return check_accepts

def returns(rtype):
def check_returns(f):
def new_f(*args, **kwds):
result = f(*args, **kwds)
assert isinstance(result, rtype), \
"return value %r does not match %s" % (result,rtype)
return result
return new_f
return check_returns

the new syntax will be:

@accepts(int, (int,float))
@returns((int,float))
def func(arg1, arg2):
return arg1 * arg2

I believe the order of application of the above decorators would be like so:

func = accepts(int, (int, float))(returns((int, float))(func)

Edward> I confess that I don''t understand this remark at all. How has
Edward> it happened that so many people are confused about this
Edward> proposal? And if everything is so clear, why isn''t the clarity
Edward> reflected in pep 318 itself?

There was a lot of discussion on python-dev, but none very recently (last
month or so). Guido indicated there that he brought up the topic at
EuroPython in his keynote talk and entertained discussion from the floor.
Based upon that discussion he decided to go with the @-decorator syntax.
Since EuroPython most/all the discussion went on in private email or on
irc. I think it would be nice if this conversation was summarized in the
PEP, but that will have to come from one of the participants.

Skip

> As in many other software efforts, the code has moved along a bit

faster than the documentation (after all, what''s more fun to do?). .... Guido indicated there that he brought up the topic at
EuroPython in his keynote talk and entertained discussion from the floor.
Based upon that discussion he decided to go with the @-decorator syntax.
Well, this isn''t good. We are talking about a basic design document here.
I feel like I have been kept in the dark; my previous relative silence is
hardly evidence of my agreement. How is it possible to pretend that people
agree with a proposal that DOES NOT EXIST? I am -10 on pep 318 now: this
process amounts to a rigged election. I might become neutral in the future
once the hood is removed from over the candidate''s head :-)
I believe the only significant differences from a pure functional
documentation standpoint to apply to the PEP are the syntax

Why is something "spectacular" like the ''@'' sign is needed? Presumably
there is some problem with the compiler? Has anyone suggested something
like:

from __future__ import annotation as annotate

annotate.accepts(int, (int,float))

instead of:

@accepts(int, (int,float))

Clearly, with enough work the Python compiler could recognize this. Yes,
it''s a special case, but so what? This would avoid most problems with
reserved words or keywords. And it would be in the spirit of letting
modules encapsulate most major features.

Edward

P.S. The more I think of this proposal, the more unhappy I become. In fact,
this proposal may have a most unfortunate effect on Leo''s future, for two
reasons:

1. Although Leo handles constructs like @accepts, it does so by generating
lines like this:

#@verbatim
@accepts(int, (int,float))

So _Leo_ has no problem, but Leo''s users will likely complain that more
cruft has been added to their files.

2. Leo presently supports the following directives:

@ (followed by one or more whitespace characters)
@all, @asis,
@c, @code, @color, @comment,
@delims, @doc,
@encoding, @end_raw,
@file, @first,
@header,
@ignore,
@killcolor,
@language, @last, @lineending,
@nocolor, @noheader, @noref, @nosent, @nowrap,
@others,
@pagewidth, @path,
@quiet,
@raw,
@root, @root-code, @root-doc,
@silent,
@tabwidth, @terse, @thin,
@unit,
@verbose,
@wrap

Worse, Leo allows plugins to define their own directives. There is already
a plugin that defines @wiki. Furthermore, @run, @test and @suite are also
used in special contexts.

What happens when another Python @x construct conflicts with one of these
directives or some other directive? I''m starting to wonder whether Python
is a snake or a gorilla :-)

Yes, Python does have the right to use ''@''. But I would hope that GvR would
choose not to do so. I was always under the impression that the clear
statement in the Reference Manual that at signs are invalid everywhere
(except in comments and strings) was a clear signal of an intention to keep
those symbols for other valid purposes. I am extremely unhappy that this
may not be so.

P.P.S. I did respond earlier to the requested survey, saying in brief that
I had no problems with 318 provided that ''@'' signs did not become a part of
the syntax. I have received no reply from anyone. There is no way somebody
could construe my previous statements as approval.

EKR
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

这篇关于对pep 318感到困惑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！