[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
Daniel Wagner-Hall added the comment: Is anything blocking this patch's submission? -- ___ Python tracker <http://bugs.python.org/issue15836> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15864] Package cache doesn't cache packages with overlapping sys.path entries
Daniel Wagner-Hall added the comment: That is indeed the behaviour I'm talking about. In particular I came across this where two libraries imported an exception type using different sys.path traversals, which both led to the same file, and a try-catch didn't catch the exception because it had a different type (even though it had been defined by the same file). This was a pretty horrible bug to track down. That said, messing with sys.path is pretty ugly, so I can see why this would be intentional, but it still feels like the the types of the same class, defined by the same file, should be equal. -- ___ Python tracker <http://bugs.python.org/issue15864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15864] Package cache doesn't cache packages with overlapping sys.path entries
New submission from Daniel Wagner-Hall: Importing the same module twice should only execute its code once, and should only lead to one copy of the classes defined in the module's file. If a subdirectory of $PWD is on $PYTHONPATH, and a package is imported both relative to $PWD and relative to that subdirectory, its code is loaded twice, and its classes are defined twice independently. Downloading the attached file, and running: mkdir folder cd folder tar xf file.tgz PYTHONPATH=$(pwd)/package python main.py should print import once, but does print import twice. -- files: packageissue.tgz messages: 169842 nosy: daniel.wagner-hall priority: normal severity: normal status: open title: Package cache doesn't cache packages with overlapping sys.path entries type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27119/packageissue.tgz ___ Python tracker <http://bugs.python.org/issue15864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
Daniel Wagner-Hall added the comment: Cool, my contributor agreement has been received, please merge if happy! -- ___ Python tracker <http://bugs.python.org/issue15836> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
Daniel Wagner-Hall added the comment: Added patch for 2.7. I'll sign the contributor form just as soon as I can get to a printer. Thanks for taking me through my first contribution. -- versions: +Python 2.7 Added file: http://bugs.python.org/file27081/issue15836-2.7.patch ___ Python tracker <http://bugs.python.org/issue15836> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
Daniel Wagner-Hall added the comment: I seem to be getting exceptions why trying to upload a new patch to rietveld, either by the web interface (in several browsers), or by upload.py - attaching new patchset here Also, if I wanted to backport to 2.7 including an isinstance(e, types.ClassType) check, how would I go about doing so? Thanks for the quick review! -- Added file: http://bugs.python.org/file27080/assertRaises.patch ___ Python tracker <http://bugs.python.org/issue15836> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
New submission from Daniel Wagner-Hall: The following code in a unittest test is a no-op: self.assertRaises(lambda: 1) I would expect this to fail the test, because I naively assumed omitting the exception class would act as: self.assertRaises(BaseException, lambda: 1) verifying that *any* Exception is raised. I believe the correct behaviour is to raise a TypeError if excClass is not a BaseException-derived type, similar to if a non-type is passed as the first arg to issubclass. Attached is a patch to do so. It also removes a no-op self.assertRaises from libimport's tests (because it started failing when I ran the tests with the patch). That assertion is redundant, because the two lines above perform the assertion being attempted. -- components: Tests files: assertRaises.patch keywords: patch messages: 169596 nosy: illicitonion priority: normal severity: normal status: open title: unittest assertRaises should verify excClass is actually a BaseException class type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27079/assertRaises.patch ___ Python tracker <http://bugs.python.org/issue15836> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13139] multiprocessing.map skips finally blocks
Daniel Wagner-Hall added the comment: Explanation of behaviour at http://stackoverflow.com/questions/7700929/python-multiprocessing-map-if-one-thread-raises-an-exception-why-arent-other tl;dr SIGTERM kills subprocesses and finally blocks aren't called. I still consider this a bug, though -- ___ Python tracker <http://bugs.python.org/issue13139> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13139] multiprocessing.map skips finally blocks
New submission from Daniel Wagner-Hall :
import random
from multiprocessing import Pool
from time import sleep
def Process(x):
try:
print x
sleep(random.random())
raise Exception('Exception: ' + x)
finally:
print 'Finally: ' + x
Pool(3).map(Process, ['1','2','3'])
Expect all three Finally blocks to be called (or at least, one Finally per x
printed by line 8)
Actually, only one (occasionally two) are printed.
Same behaviour exhibited on dual-core Mac running OSX 10.6 with Python 2.7, and
single core Ubuntu running Python 2.6.
--
components: None
messages: 145201
nosy: illicitonion
priority: normal
severity: normal
status: open
title: multiprocessing.map skips finally blocks
type: behavior
versions: Python 2.6, Python 2.7
___
Python tracker
<http://bugs.python.org/issue13139>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
