[issue5251] contextlib.nested inconsistent with, well, nested with statements due exceptions raised in __enter__
New submission from James William Pye :
Basically, nested() doesn't seem to be consistent with explicitly nested
with-statements when an exception is thrown in a CM's __enter__.
Consider a pair of nested CMs, the inner __enter__ raises an exception
trapped by the outer. In the situation of explicitly nested
with-statements, the inner's block will not be ran as an exception was
raised prior to the block. The outer traps the exception and code
continues to flow after the outer's block because the exception was
*not* raised.
Currently, if contextlib.nested() is used in such a situation, it blows
up with a RuntimeError("generator didn't yield").
See the attached file for a set of naive variations and their resulting
exceptions or lack thereof in the situation of explicitly nested CMs.
Despite the RuntimeError raised by nested(), I'm not sure it's
*currently* possible for an implementation of nested() to be *totally*
consistent with explicitly nested with-statements. It would seem that an
additional facility(AbortBlock exception?) would be needed to
communicate that the block should not actually be ran, and that no
exception should be raised as it was consumed by an "outer" CM.
If this is considered to be the intended behavior, I would think the
doc-string on contextlib.nested should be updated to document the
inconsistency as it currently states that nested() and nested with
statements are equivalent. Based on the results of the attached file in
Python 3.0, they are clearly not.
Cheers folks; lovin' CMs. And, of course, apologies if this has already
been discussed. :P
--
components: None
files: nested_issue.py
messages: 81957
nosy: jwp
severity: normal
status: open
title: contextlib.nested inconsistent with, well, nested with statements due
exceptions raised in __enter__
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13075/nested_issue.py
___
Python tracker
<http://bugs.python.org/issue5251>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1195571] simple callback system for Py_FatalError
James William Pye added the comment: I had actually forgotten that this was still open. Anything I can do to help speed this along? In case nobody remembers, the purpose of this was to provide a facility to embedded applications that allows for a more graceful shutdown in fatal error situations. My original use-case was for a PostgreSQL PL extension where an abort() is quite undesirable as it would take down the entire cluster(yeah, all the postmaster processes). IIRC, the only thoughts "against" it were rather for trying to remove FatalErrors entirely. hepl? -- nosy: +jwp ___ Python tracker <http://bugs.python.org/issue1195571> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5283] setting __class__ in __del__ is bad. mmkay. negative ref count! kaboom!
New submission from James William Pye : I found this bug by misplacing a line of a code. Yes, I was doing naughty things, but in the case of the class that led to the discovery, it was inadvertent. :P class something_else(object): pass class foo(object): def __del__(self): self.__class__ = something_else for _ in range(1000): foo() That results in a fatal python error due to a negative reference count(on the foo class object) in 3.0. 3.0.1 (release30-maint:69593M, Feb 13 2009, 14:48:10) -> kaboom j...@torch[]:org/pgfoundry/python 134% /src/build/py30/bin/python3.0 ./kaboom.py Fatal Python error: Objects/descrobject.c:10 object at 0x5221b8 has negative ref count -1 zsh: abort /src/build/py30/bin/python3.0 ./kaboom.py 2.6 (r26:66714, Dec 21 2008, 21:17:32) -> kaboom j...@torch[]:org/pgfoundry/python 0% /sw/bin/python2.6 ./kaboom.py Fatal Python error: GC object already tracked zsh: abort /sw/bin/python2.6 ./kaboom.py 2.5.2 (r252:60911, Jun 15 2008, 18:55:39) -> no kaboom (no asserts? eh..) ... 2.5.1 (r251:54863, Apr 15 2008, 22:57:26) -> kaboom (/usr/bin/python2.5) j...@torch[]:org/pgfoundry/python 0% /usr/bin/python2.5 ./kaboom.py Assertion failed: (PyType_Check(base)), function _PyType_Lookup, file Objects/typeobject.c, line 2035. zsh: abort /usr/bin/python2.5 ./kaboom.py -- components: Interpreter Core files: kaboom.py messages: 82272 nosy: jwp severity: normal status: open title: setting __class__ in __del__ is bad. mmkay. negative ref count! kaboom! type: crash versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file13110/kaboom.py ___ Python tracker <http://bugs.python.org/issue5283> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
James William Pye added the comment: Seeing this in 3.1 when I try to compile with mingw32 under wine: "error: Unable to find vcvarsall.bat" --compiler=mingw32 works in 3.0. I assume it's related to this bug? -- nosy: +jwp versions: +Python 3.1 ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5251] contextlib.nested inconsistent with, well, nested with statements due exceptions raised in __enter__
James William Pye added the comment: Just downloaded v2 and tried it out against Python 2.7a0 (trunk:70381M, Mar 14 2009, 23:12:51). output of the "nested_issue.py" script with patch: j...@torch[]:org/python/trunk 0% /src/build/py/bin/python ./nested_issue.py () [try_with_nested] Skipping statement body () SUCCESS! i guess.. () [try_with_nested_class] Skipping statement body () SUCCESS! i guess.. () [try_with_nested_statements] () SUCCESS! i guess.. () [try_with_nested_statements_class] () SUCCESS! i guess.. I'm going to play with it a bit more, but it looks pretty solid already... -- ___ Python tracker <http://bugs.python.org/issue5251> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5251] contextlib.nested inconsistent with, well, nested with statements due exceptions raised in __enter__
James William Pye added the comment: I tested the attached script against v2. It further identifies consistencies between nested with-statements and nested() that should exist(and do in v2). It answers the question: what is the effect of a SkipStatement exception on another, outer CM? with nested(outer(), trap(), fail()): ... That is, validate that outer()'s __exit__ invocation is not given an exception. This is probably an obvious effect of the patch, but I think it merited a test. -- Added file: http://bugs.python.org/file13346/outer_sees_no_exc.py ___ Python tracker <http://bugs.python.org/issue5251> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1195571] simple callback system for Py_FatalError
James William Pye added the comment: Would it be possible to require the embedding application to define the Py_FatalError symbol? Admittedly, it would be nice to not have the callback installation code. =\ -- ___ Python tracker <http://bugs.python.org/issue1195571> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1195571] simple callback system for Py_FatalError
James William Pye added the comment: I guess it seemed so unlikely that (C) extensions should be installing the callback that installation should be restricted pre-Py_Initialize(); the area completely controlled by the embedding app. However, I have no strong attachment to that. -- ___ Python tracker <http://bugs.python.org/issue1195571> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1195571] simple callback system for Py_FatalError
Changes by James William Pye : -- nosy: -jwpye ___ Python tracker <http://bugs.python.org/issue1195571> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
