问题标签 [contextmanager]

我最近在 Python 的 with 语句中遇到了一个奇怪的行为。我有一个代码，它使用 Python 的上下文管理器来回滚__exit__方法中的配置更改。经理return False在 finally 块中有一个值__exit__。我已经在以下代码中隔离了这种情况 - 唯一的区别是 return 语句的缩进：

在上面的代码中，回滚失败并出现异常。我的问题是，为什么Manager1行为与Manager2. 异常不会在 with-statement in 之外抛出，Manager1以及为什么它会在 exit in 中抛出Manager2。

根据以下文件__exit__：

如果提供了一个异常，并且该方法希望抑制该异常（即，防止它被传播），它应该返回一个真值。否则，异常将在退出该方法时正常处理。

在我看来，在这两种情况下，出口都没有返回 True，因此在这两种情况下都不应该抑制异常。但是在 Manager1 中它是。谁能解释一下？

我使用 Python 2.7.6。

考虑以下代码：

示例输出：

发生错误：（'Foo'，'Bar'）

发生错误：（'Foo'，'Bar'）

发生错误：（'Foo'，'Bar'）

我有几个嵌套with语句，并且想要处理代码中某处引发异常的情况。我想要实现的是停止执行（上例中没有“不应该发生”的输出），但错误信息只打印一次。因此，我需要以某种方式知道是否已经处理了相同的错误。

您知道如何实现这一目标吗？

在 Python 中应该如何处理在另一个上下文管理器中创建的上下文管理器？

示例：假设您有A充当​​上下文管理器的类，以及B还充当上下文管理器的类。但是类B实例必须实例化并使用类的实例A。我已经完成了 PEP 343，这是我想到的解决方案：

这是正确的方法吗？还是我错过了一些陷阱？

我正在从事的一个项目有几个上下文管理器。它即将发货，我遇到了一些我开始恐慌的事情。

我的印象是您不应该重新引发作为参数传递给上下文管理器类的 __exit__ 方法的异常。但是，我正在执行一些测试，似乎上下文管理器正在抑制其中抛出的异常。当我将 __exit__ 方法更改为如下所示时：

错误似乎正确通过。

我的问题是：如果 type_、value 和 trace 不是 None，那么在 __exit__ 方法中处理异常的正确方法是什么？提出（重新提出？）这样的异常是不是很糟糕？这是我应该做的吗？

我遇到的错误可能是由其他原因引起的。通常我会彻底测试这一切，但目前我的时间似乎非常有限。我希望有人可以解释这个功能的正确实现和

最终：我可以安全地将 raise type_, value, trace 留在我的上下文管理器 __exit__ 方法中吗？

我最近写了一个返回一系列打开文件的方法；换句话说，是这样的：

从语法上讲，如果我执行以下操作，我不希望必须关闭生成的对象：

因此，我决定包装_iterdir一个上下文管理器：

这似乎工作正常。

我感兴趣的是这样做是否是好的做法。按照这种模式我会遇到任何问题（也许如果抛出异常）？

我想用来itertools.izip()迭代多个文件的行。我创建了一个上下文管理器类型，以确保所有文件在与with. 这似乎有效：

两个问题：

1. 我是否正确实施了这一点？
2. 我可以对此进行测试以确保文件被关闭还是我只是相信它？

我使用打印语句来表示何时__exit__被调用 - 这是一个足够的测试吗？

Suppose you are using a multiprocessing.Pool object, and you are using the initializer setting of the constructor to pass an initializer function that then creates a resource in the global namespace. Assume resource has a context manager. How would you handle the life-cycle of the context managed resource provided it has to live through the life of the process, but be properly cleaned up at the end?

So far, I have something somewhat like this:

From here on, the pool processes can use the resource. So far so good. But handling clean up is a bit trickier, since the multiprocessing.Pool class does not provide a destructor or deinitializer argument.

One of my ideas is to use the atexit module, and register the clean up in the initializer. Something like this:

Is this a good approach? Is there an easier way of doing this?

EDIT: atexit does not seem to work. At least not in the way I am using it above, so as of right now I still do not have a solution for this problem.

Python 的with exp() as obj:语法对任何具有“强制”进入和退出方法的对象都很有吸引力——考虑到人们尝试扩展obj.__del__但结果不佳的情况以及所有这些情况，它似乎指向使用__enter__and__exit__方法。

我首先想到的是带有进入和退出方法的状态机；无论如何处理都是基本的，但使状态机的实际实现非常简单。

然而，似乎人们通常将语法视为子句和/或语句with XXX as YYY的替代品，而我不断发现的一件事是 Python 社区喜欢知道在实现某个功能时会发生什么。所以如果用错误的咒语来解决正确的问题，它仍然是错误的答案。try/finallyyield

Python 是否with...as出于特定原因故意为生成器保留语法，或者是否可以根据需要应用此语法？如果有目的，那目的是什么？（我在 PEP 8 中几乎没有提到with/as，如果那是正确的地方看的话）

有没有一种方法可以在上下文管理器的方法中捕获异常，__enter__而无需将整个with块包装在 a中try？

我知道我可以在__enter__()自身内部捕获异常，但是我可以从包含该with语句的函数中访问该错误吗？

从表面上看，在上下文管理器中捕获异常__enter__()的问题似乎是一回事，但这个问题实际上是关于确保__exit__调用它，而不是与语句所包含__enter__的块不同地处理代码。with

...显然动机应该更清楚。该with声明正在为一个完全自动化的过程设置一些日志记录。如果程序在日志设置之前失败，那么我不能依靠日志来通知我，所以我必须做一些特别的事情。而且我宁愿在不必添加更多缩进的情况下实现效果，如下所示：

使用两个try块的另一个缺点是处理异常__enter__的代码在块的后续主体中处理异常的代码之后with。

我正在使用 PySide (Qt) Gui，它应该在单击按钮时退出循环。PySide 的按钮单击会发出一个信号，该信号会调用连接的函数。然而，当信号调用函数时，它使用它自己的系统进行错误处理。

我真的不想修复那个信号错误处理。

有没有办法在不引发错误的情况下打破“with”语句。

我在信号中看到的 PySide/Qt 错误处理的修复看起来不太好。它覆盖了 QApplication，这意味着使用此类的其他人必须使用新的 QApplication。

PySide/Qt 信号错误处理是否有一种简单的方法，或者是否有另一种方法可以打破“with”语句。