评论：PEP 343：匿名块Redux和Generator增强功能 [英] For review: PEP 343: Anonymous Block Redux and Generator Enhancements

问题描述

经过多轮关于python-dev的讨论后，我正在邀请公众对PEP 343进行公开评论。不是在这里发布整个PEP文本，

我邀请所有人在线阅读

（ http://www.python.org/peps/pep-0343.html ）然后在我为此目的创建的

Wiki页面上发表评论

（ http://wiki.python.org/moin / WithStatement）。


我认为这是一个很好的;我希望人们同意。它的接受将

淘汰其他4个PEP！ （这表明它满足了需求并且

建议的解决方案功能强大。）


-

--Guido van Rossum（主页： http://www.python.org/~guido/ ）

After many rounds of discussion on python-dev, I''m inviting public
comments for PEP 343. Rather than posting the entire PEP text here,
I''m inviting everyone to read it on line
(http://www.python.org/peps/pep-0343.html) and then post comments on a
Wiki page I''ve created for this purpose
(http://wiki.python.org/moin/WithStatement).

I think this is a good one; I hope people agree. Its acceptance will
obsolete about 4 other PEPs! (A sign that it fulfills a need and that
the proposed solution is powerful.)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)

推荐答案

Guido van Rossum写道：

Guido van Rossum wrote:

经过多轮关于python-dev的讨论，我'正在邀请公众对PEP的评论343.而不是在这里发布整个PEP文本，
我邀请所有人在线阅读
（ http://www.python.org/peps/pep-0343.html ）然后在我为此目的创建的Wiki页面上发表评论
（ http://wiki.python.org/moin/WithStatement) 。

我认为这是一个很好的;我希望人们同意。它的接受将会淘汰其他4个PEP！ （这表明它满足了需求并且提议的解决方案非常强大。）

After many rounds of discussion on python-dev, I''m inviting public
comments for PEP 343. Rather than posting the entire PEP text here,
I''m inviting everyone to read it on line
(http://www.python.org/peps/pep-0343.html) and then post comments on a
Wiki page I''ve created for this purpose
(http://wiki.python.org/moin/WithStatement).

I think this is a good one; I hope people agree. Its acceptance will
obsolete about 4 other PEPs! (A sign that it fulfills a need and that
the proposed solution is powerful.)

我非常喜欢PEP;我想大多数C ++程序员都缺少Python中的
功能。 （我跟着关于python-dev的讨论，

我很高兴并且惊讶于结果/妥协有多好）。


怎么样？使''：''可选（并隐含地结束当前

块）以避免过度缩进？


def foo（）：<带锁定的
（someMutex）

带开头（readFilename）作为输入

带开头（writeFilename）作为输出

...


相当于：


def foo（）：
带锁定的
（someMutex）

以开头（readFilename）作为输入

以开头（writeFilename）作为输出

...


问候，


Nicolas

I like the PEP very much; I guess most C++ programmers are missing that
capability in Python. (I was following the discussion on python-dev,
and I''m pleased and surprised how good the result/compromise is).

What about making the '':'' optional (and end implicitly at end of current
block) to avoid over-indentation?

def foo():
with locking(someMutex)
with opening(readFilename) as input
with opening(writeFilename) as output
...

would be equivalent to:

def foo():
with locking(someMutex)
with opening(readFilename) as input
with opening(writeFilename) as output
...

Regards,

Nicolas

Nicolas Fleury写道：

Nicolas Fleury wrote:

如何制作' '：''可选（并隐式结束当前
块）以避免过度缩进？

def foo（）：
带锁定（someMutex）
以open（readFilename）作为输入
以open（writeFilename）作为输出


将等同于：

def foo（） ：
带锁（someMilex）
带开口（readFilename）作为输入
带开口（writeFilename）作为输出
...

What about making the '':'' optional (and end implicitly at end of current
block) to avoid over-indentation?

def foo():
with locking(someMutex)
with opening(readFilename) as input
with opening(writeFilename) as output
...

would be equivalent to:

def foo():
with locking(someMutex)
with opening(readFilename) as input
with opening(writeFilename) as output
...

Python中没有任何内容在当前块的末尾结束。

它们只以范围退出结束。删除顺序

未定义，您也可以更改它。


您的方法不允许以下
<带锁定的
（互斥锁）：

increment_counter（）


x = counter（）

$ b带锁定的$ b（互斥锁）：

decrement_counter（）

除了制作一个新的块，因为


如果1：

锁定（互斥锁）


x = counter（）


如果1：

锁定（互斥锁）

如果块的数量有问题，那就不好了。

很难做到


与multi（锁定（someMutex），

开盘（readFilename），

开盘（writeFilename））为_，输入，输出：

......


未经测试的草图实现

class multi（object）：

def __init __（self，* args） ：

self.args = args

def __enter __（self）：

results = []

for i ，枚举中的arg（self.ar gs）：

试试：

results.append（arg .__输入__（））

除了：

＃通过已经__entered__ args支持

exc = sys.exc_info（）

范围内的j（i-1，-1，-1）：

试试：

self.args [j] .__退出__（* exc）

除了：

＃需要新的异常，匹配PEP行为

exc = sys.exc_info（）

提高exc [0]，exc [1]，exc [2]

返回结果


def __exit __（self，type，value，traceback）：

for self.args [:: - 1]中的arg：

试试：

arg .__退出__（类型，值，追溯）

除了：

类型，值， traceback = sys.exc_info（）


Andrew
da *** @ dalkescientific.com

Nothing in Python ends at the end of the current block.
They only end with the scope exits. The order of deletion
is not defined, and you would change that as well.

Your approach wouldn''t allow the following

with locking(mutex):
increment_counter()

x = counter()

with locking(mutex):
decrement_counter()
except by making a new block, as

if 1:
locking(mutex)

x = counter()

if 1:
locking(mutex)
If the number of blocks is a problem it wouldn''t be that
hard to do

with multi( locking(someMutex),
opening(readFilename),
opening(writeFilename) ) as _, input, output:
...

Untested sketch of an implementation
class multi(object):
def __init__(self, *args):
self.args = args
def __enter__(self):
results = []
for i, arg in enumerate(self.args):
try:
results.append(arg.__enter__())
except:
# back up through the already __entered__ args
exc = sys.exc_info()
for j in range(i-1, -1, -1):
try:
self.args[j].__exit__(*exc)
except:
# Need to get the new exception, to match the PEP behavior
exc = sys.exc_info()
raise exc[0], exc[1], exc[2]
return results

def __exit__(self, type, value, traceback):
for arg in self.args[::-1]:
try:
arg.__exit__(type, value, traceback)
except:
type, value, traceback = sys.exc_info()

Andrew
da***@dalkescientific.com

Andrew Dalke写道：

Andrew Dalke wrote:

def foo（）：
带锁（someMutex）
带开口（readFilen ame）作为输入
以open（writeFilename）作为输出
...

Python中没有任何内容在当前块的末尾结束。
它们只以结尾范围退出。删除顺序
没有定义，你也可以改变它。

def foo():
with locking(someMutex)
with opening(readFilename) as input
with opening(writeFilename) as output
...

Nothing in Python ends at the end of the current block.
They only end with the scope exits. The order of deletion
is not defined, and you would change that as well.

删除顺序没有变化，它''只是定义了对__exit__的调用的

顺序，它们完全相同。据我所知，PEP343与删除顺序无关，这仍然是依赖于实现的
。它不是像C ++ RAII那样的构造函数/析构函数，而是__enter __ / __ exit__。


但是，它通过创建一个先例创造了一个先例声明影响当前缩进块的结尾

。但这就是这个PEP的全部内容

关于...

你的方法不允许以下


不，我说''：''*可选*。我完全同意支持''：''

有用。

如果块的数量有问题，那就不难了

用multi（锁定（someMutex），
打开（readFilename），
打开（writeFilename））为_，输入，输出：
......

There''s no change in order of deletion, it''s just about defining the
order of calls to __exit__, and they are exactly the same. As far as I
know, PEP343 has nothing to do with order of deletion, which is still
implementation-dependant. It''s not a constructor/destructor thing like
in C++ RAII, but __enter__/__exit__.

But yes, it creates a precedent by creating a statement affecting the
end of the current indentation block. But that''s what this PEP is all
about...
Your approach wouldn''t allow the following
No, I said making the '':'' *optional*. I totally agree supporting '':'' is
useful.
If the number of blocks is a problem it wouldn''t be that
hard to do

with multi( locking(someMutex),
opening(readFilename),
opening(writeFilename) ) as _, input, output:
...

True。但它看起来一样好吗？特别是_部分？


问候，

Nicolas

True. But does it look as good? Particularly the _ part?

Regards,
Nicolas

这篇关于评论：PEP 343：匿名块Redux和Generator增强功能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！