[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs
Denver Coneybeare added the comment: Thanks r.david.murray. I appreciate you taking the time to look at this issue! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17435 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs
Denver Coneybeare added the comment: Thanks r.david.murray for your feedback. Although I disagree with your conclusion that this does not affect 2.7. Just try running the sample script that reproduces the issue from my first post and you will see the erroneous behaviour in 2.7. Even though threading.Timer is a function in 2.7 (instead of a class), it still ultimately returns a class whose args and kwargs members can be modified. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17435 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs
New submission from Denver Coneybeare:
The __init__() method of threading.Timer uses *mutable* default values for the
args and kwargs arguments. Since the default argument objects are created
once and re-used for each instance, this means that changing the args list or
kwargs dict of a Timer object that used the argument defaults will specify
those arguments to all future Timer objects that use the defaults too.
def __init__(self, interval, function, args=[], kwargs={}):
A fully backwards-compatible way to fix this is to instead use None as the
default value for args and kwargs and just create a new list and/or dict inside
__init__() if they are None. That way each new instance of Timer will get its
very own args list and kwargs dict object.
def __init__(self, interval, function, args=None, kwargs=None):
...
self.args = args if args is not None else []
self.kwargs = kwargs if kwargs is not None else {}
Here is a sample script that reproduces the issue:
import threading
event = threading.Event()
def func(*args, **kwargs):
print(args={!r} kwargs={!r}.format(args, kwargs))
event.set()
timer1 = threading.Timer(1, func)
timer1.args.append(blah)
timer1.kwargs[foo] = bar
timer2 = threading.Timer(1, func)
timer2.start()
event.wait()
Here is the example output when run before the fix:
c:\dev\cpythonPCbuild\python_d.exe ThreadingTimerInitDefaultArgsIssueDemo.py
args=('blah',) kwargs={'foo': 'bar'}
[44758 refs, 17198 blocks]
And after the fix:
c:\dev\cpythonPCbuild\python_d.exe ThreadingTimerInitDefaultArgsIssueDemo.py
args=() kwargs={}
[47189 refs, 18460 blocks]
As you can see, in the version without the fix, the elements added to timer1's
args and kwargs were also given to timer2, which is almost certainly not what a
user would expect.
A proposed patch, ThreadingTimerInitDefaultArgsIssueDemo.01.patch, is attached.
This fixes the issue, updates the docs, and adds a unit test.
--
components: Library (Lib)
files: ThreadingTimerInitDefaultArgsIssueDemo.01.patch
keywords: patch
messages: 184278
nosy: denversc
priority: normal
severity: normal
status: open
title: threading.Timer.__init__() should use immutable argument defaults for
args and kwargs
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file:
http://bugs.python.org/file29422/ThreadingTimerInitDefaultArgsIssueDemo.01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17435
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11551] test_dummy_thread.py test coverage improvement
Denver Coneybeare denver.coneybe...@gmail.com added the comment: I've looked at the review (thanks for the review) and can submit an updated patch. I don't have the Python source code pulled down to my PC anymore so it might take a week or two before I'm able to update the patch and test it out. I imagine that's not too much of a problem though :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3905] subprocess failing in GUI applications on Windows
Denver Coneybeare denver.coneybe...@gmail.com added the comment: Ahh okay. I've reproduced it in trunk at changeset 053bc5ca199b. As suggested, I ran: PCBuild\pythonw.exe lib\idlelib\idle.py Python 3.3a0 (default, Apr 2 2011, 21:55:40) [MSC v.1500 32 bit (Intel)] on win32 Type copyright, credits or license() for more information. import subprocess subprocess.Popen([python, -c, print(32)], stdin=None, stdout=subprocess.PIPE, stderr=subprocess.PIPE) Traceback (most recent call last): File pyshell#1, line 1, in module subprocess.Popen([python, -c, print(32)], stdin=None, stdout=subprocess.PIPE, stderr=subprocess.PIPE) File C:\dev\cpython\cpython\lib\subprocess.py, line 732, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File C:\dev\cpython\cpython\lib\subprocess.py, line 903, in _get_handles p2cread = self._make_inheritable(p2cread) File C:\dev\cpython\cpython\lib\subprocess.py, line 946, in _make_inheritable _subprocess.DUPLICATE_SAME_ACCESS) WindowsError: [Error 6] The handle is invalid So, the issue is definitely not fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3905] subprocess failing in GUI applications on Windows
Denver Coneybeare denver.coneybe...@gmail.com added the comment: I just re-tested this in cpython trunk at changeset and the issue does not appear to be reproducible. I first launched IDLE by running python lib\idlelib\idle.py. Then I entered the following: Python 3.3a0 (default, Apr 2 2011, 21:55:40) [MSC v.1500 32 bit (Intel)] on win32 Type copyright, credits or license() for more information. import sys sys.getwindowsversion() sys.getwindowsversion(major=5, minor=1, build=2600, platform=2, service_pack='Service Pack 3') import subprocess PIPE = subprocess.PIPE p = subprocess.Popen([python, -c, print(32)], stdin=None, stdout=PIPE, stderr=PIPE) p subprocess.Popen object at 0x00F85610 p.returncode Popen() did not raise any exceptions. I also tried in Python 2.7 and the Popen called succeeded there as well. So my inability to reproduce the issue does not necessarily mean that the issue is fixed, but rather that it is likely dependent on the version of Windows on which Python is running. That being said, the linked issue issue1124861 logs what appears to be the same issue and it was fixed in Python 2.6. So maybe I'm just not old enough to have encountered this issue :) Anyways, this issue probably can be closed as either a duplicate or fixed incidentally. -- nosy: +denversc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647489] zero-length match confuses re.finditer()
Denver Coneybeare denver.coneybe...@gmail.com added the comment:
I just re-tested this issue in trunk at changeset 053bc5ca199b and the issue is
still exactly reproducible as originally reported. That is, the match to the
empty string skips a character of the match:
import re
[m.groups() for m in re.finditer(r'(^z*)|(\w+)', 'abc')]
[('', None), (None, 'bc')]
--
nosy: +denversc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1647489
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11745] idlelib/PyShell.py: incorrect module name reported in error message: Tkinter should be tkinter
New submission from Denver Coneybeare denver.coneybe...@gmail.com: Just a very minor bug. The error message in idlelib/PyShell.py that is printed when importing tkinter fails says that it failed to import Tkinter, but the actual module name is tkinter (with a lowercase t). try: from tkinter import * except ImportError: print(** IDLE can't import Tkinter. \ Your Python may not be configured for Tk. **, file=sys.__stderr__) A patch is attached. -- components: IDLE messages: 132828 nosy: denversc priority: normal severity: normal status: open title: idlelib/PyShell.py: incorrect module name reported in error message: Tkinter should be tkinter versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11745] idlelib/PyShell.py: incorrect module name reported in error message: Tkinter should be tkinter
Changes by Denver Coneybeare denver.coneybe...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file21512/patch_idle_tkinter_import_v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11745] idlelib/PyShell.py: incorrect module name reported in error message: Tkinter should be tkinter
Changes by Denver Coneybeare denver.coneybe...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673007] urllib2 requests history + HEAD support
Denver Coneybeare denver.coneybe...@gmail.com added the comment: I decided to take a look at this old, forgotten issue and propose an updated patch. I like the submitter's idea that urllib.Request.__init__() should take a method parameter to override the return value of get_method(). I've created and attached a patch (issue1673007_urllib_Request_method_v1.patch) which implements this functionality, adds unit tests, and updates the documentation. -- nosy: +denversc Added file: http://bugs.python.org/file21432/issue1673007_urllib_Request_method_v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1673007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8150] urllib needs ability to set METHOD for HTTP requests
Denver Coneybeare denver.coneybe...@gmail.com added the comment: Can this issue be closed as a duplicate of #1673007? This specific request for a method parameter to the Request constructor is dealt with there. -- nosy: +denversc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8150 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9348] Calling argparse's add_argument with the wrong number of metavars causes delayed error message
Denver Coneybeare denver.coneybe...@gmail.com added the comment: Awesome, thanks for committing the patch. Glad I could help. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9348 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9348] Calling argparse's add_argument with the wrong number of metavars causes delayed error message
Denver Coneybeare denver.coneybe...@gmail.com added the comment: For kicks, I just took a look at this old, forgotten issue. I agree with the submitter that add_argument() should fail if nargs and metavar do not match, instead of having format_help() raise the exception later on. I've attached a patch (issue9348_patch_v01.txt) with a proposed fix and associated test cases. The drawback of my approach is that if a custom HelpFormatter is used which has different semantics for metavar it could cause add_argument() to incorrectly reject the metavar value. I'm not sure how common that is though. -- nosy: +denversc Added file: http://bugs.python.org/file21294/issue9348_patch_v01.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9348 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11491] dbm.open(..., flag=n) raises dbm.error if file exists and is rejected by whichdb
New submission from Denver Coneybeare denver.coneybe...@gmail.com: dbm.open() with flag=n raises dbm.error if the given file exists but whichdb doesn't recognize it. In the documentation for dbm.open() the n flag is documented to Always create a new, empty database, open for reading and writing. To me, this implies that if the file exists it will unconditionally be overwritten with a newly-created database, irrespective of its contents. The code below illustrates a scenario (and indeed the scenario that I ran into) where dbm.open(..., flag=n) will throw dbm.error when it should just blow away the existing file and create a new, empty database: import dbm open(test.db, w).close() # create empty file dbm.open(test.db, flag=n) The cause of the exception is that within dbm.open() there is a call to whichdb to determine the file type. The fix would be to skip this whichdb check if the n flag is specified. I don't think that this change will cause backward compatibility issues, since I find it hard to believe that existing applications would rely on this exception being raised in this scenario. However, to *guarantee* no compatibility break an alternate fix could leave the current behavior of the n flag and introduce a new flag, perhaps o for overwrite, with this unconditional overwrite behavior. A proposed patch is attached: dbm_open_n_flag_error_invalid_file_fix_v1.patch -- components: Library (Lib) files: dbm_open_n_flag_error_invalid_file_fix_v1.patch keywords: patch messages: 130791 nosy: denversc priority: normal severity: normal status: open title: dbm.open(..., flag=n) raises dbm.error if file exists and is rejected by whichdb type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file21108/dbm_open_n_flag_error_invalid_file_fix_v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11491] dbm.open(..., flag=n) raises dbm.error if file exists and is rejected by whichdb
Changes by Denver Coneybeare denver.coneybe...@gmail.com: -- nosy: +brian.curtin versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11491] dbm.open(..., flag=n) raises dbm.error if file exists and is rejected by whichdb
Denver Coneybeare denver.coneybe...@gmail.com added the comment: Looks good to me. I thought the same thing about the file not being closed on error, but all of the other tests in the file also suffer from that problem, so I just followed the convention set out by the other tests. Maybe if you eventually commit this change, you could improve this behavior in the other tests as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
New submission from Denver Coneybeare denver.coneybe...@gmail.com: As part of the CPython sprints at PyCon 2011 I am improving the unit test coverage for the fileinput module. Primarily, this will be adding unit tests for the global functions, which right now are almost completely untested. I will be adding incremental patches and will update once my work is complete, when the final patch can be committed. -- components: Tests files: fileinput_unittests_v1.patch keywords: patch messages: 130895 nosy: brian.curtin, denversc, michael.foord priority: normal severity: normal status: open title: fileinput module unit test coverage improvements type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file21138/fileinput_unittests_v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21139/fileinput_unittests_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21141/fileinput_unittests_v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21145/fileinput_unittests_v5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21147/fileinput_unittests_v6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21149/fileinput_unittests_v7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Removed file: http://bugs.python.org/file21138/fileinput_unittests_v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21150/fileinput_unittests_v8.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21151/fileinput_unittests_v9.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21153/fileinput_unittests_v10.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21154/fileinput_unittests_v11.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21163/fileinput_unittests_v12.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21193/fileinput_unittests_v12.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21195/fileinput_unittests_v13.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11509] fileinput module unit test coverage improvements
Denver Coneybeare denver.coneybe...@gmail.com added the comment: fileinput_unittests_v13.patch is the final patch. Test coverage increased from 65% to 93% with this patch. The only code left untested is fileinput._test(), which by its name suggests that testing is not required. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11551] test_dummy_thread.py test coverage improvement
New submission from Denver Coneybeare denver.coneybe...@gmail.com: The attached patch increases the test coverage of the module _dummy_thread from 78% to 100%. -- components: Tests files: test_dummy_thread_test_coverage_improvement.patch keywords: patch messages: 130957 nosy: brian.curtin, denversc priority: normal severity: normal status: open title: test_dummy_thread.py test coverage improvement type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file21204/test_dummy_thread_test_coverage_improvement.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11551] test_dummy_thread.py test coverage improvement
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file21206/test_dummy_thread_test_coverage_improvement_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11551] test_dummy_thread.py test coverage improvement
Changes by Denver Coneybeare denver.coneybe...@gmail.com: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9587] unittest.assertRaises() return the raised exception
Denver Coneybeare denver.coneybe...@gmail.com added the comment: Michael: Do you disagree with assertRaises() returning the exception object on principle? Or is this just the consensus that you got from the mailing list, including Guido's comment. My particular use case is that I want to check certain attributes being set on the raised exception and I feel that the context manager approach is overkill for my tests since it's just one method call in the context manager. I don't understand why it is considered odd for assertRaises() to return the result for further inspection... I need to get it some way and assertRaises() has a reference to it. Thanks for considering this request further. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9587] unittest.assertRaises() return the raised exception
New submission from Denver Coneybeare denver.coneybe...@gmail.com: It would be great if unittest.assertRaises() returned the raised exception when it passes. This allows the caller to easily perform further checks on the exception, such as its attribute values. Currently assertRaises() returns None (when it doesn't return a context manager) so changing the return value should not break backwards compatibility. I see that this was already discussed in issue6275 but I'd like to resurrect the discussion since this is a common scenario in my unit tests, and I assume others. Revisions r76238 and r78110 added the ability to get the exception from the context manager (good) but sometimes using the context manager approach adds unnecessary bloat to already long-winded unit tests. I've attached a possible patch for the py3k branch (unittest.assertRaises.returnex.v1.patch). Thank you for (re)considering this topic :) Also, thank you Michael Foord for your recent improvements to unittest... the new features are very much appreciated! -- components: Library (Lib) files: unittest.assertRaises.returnex.v1.patch keywords: patch messages: 113781 nosy: denversc, krisvale, michael.foord priority: normal severity: normal status: open title: unittest.assertRaises() return the raised exception type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file18501/unittest.assertRaises.returnex.v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9553] test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80
Denver Coneybeare denver.coneybe...@gmail.com added the comment: Thanks for the input, r.david.murray. I've updated my patch and attached it to take into consideration your comments: test_argparse.py.COLUMNS.update2.patch. The updated patch uses EnviormentVarGuard as suggested, except that it slightly tweaks EnviormentVarGuard so the context manager protocol methods don't have to be invoked directly. It was also pointed out that adding setUp and tearDown to TestCase isn't enough, since subclasses and mixins define those without calling the superclass versions, which is true. However, the tests that override setUp() happen to be those that don't depend on the COLUMNS environment variable. -- Added file: http://bugs.python.org/file18481/test_argparse.py.COLUMNS.update2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9553] test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80
Denver Coneybeare denver.coneybe...@gmail.com added the comment: That is a very good point, bethard, that setting os.environ[COLUMNS] in my suggested patch (test_argparse.py.COLUMNS.patch) is global and should be test-local. I've attached an updated patch (test_argparse.py.COLUMNS.update1.patch) which uses setUp() and tearDown() to prepare and restore the COLUMNS environment variable. The one difference from my previous patch is that instead of setting the COLUMNS environment variable to 80 I just unset it. I also considered EnvironmentVarGuard, as suggested by r.david.murray, but I'm not sure it's designed for global setting of environment variables. EnvironmentVarGuard appears to have been designed to be used as a context manager for an individual test, but the COLUMNS environment variable needs to be adjusted for *every* test. -- Added file: http://bugs.python.org/file18473/test_argparse.py.COLUMNS.update1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9553] test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80
New submission from Denver Coneybeare denver.coneybe...@gmail.com: If the COLUMNS environment variable is set to a value other than 80 then test_argparse.py yields 80 failures. The value of the COLUMNS environment variable affects line wrapping of the help output and the test cases assume line wraps at 80 columns. So setting COLUMNS=160, for example, then running the tests will reproduce the failures. The fix is to invoke: os.environ[COLUMNS] = 80. A proposed patch for py3k/Lib/test/test_argparse.py is attached (test_argparse.py.COLUMNS.patch) -- components: Tests files: test_argparse.py.COLUMNS.patch keywords: patch messages: 113504 nosy: benjamin.peterson, bethard, denversc, eric.smith priority: normal severity: normal status: open title: test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80 versions: Python 3.3 Added file: http://bugs.python.org/file18462/test_argparse.py.COLUMNS.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9554] test_argparse.py: use new unittest features
New submission from Denver Coneybeare denver.coneybe...@gmail.com: Some of the unit testing code in test_argparse.py could be modified to take advantage of the new unittest features in Python 2.7 and 3.x. My suggested changes are attached in the patch file test_argparse.py.unittest2.patch One big one is that assertEquals() now prints a diff when multi-line strings compare unequal, so the manual diffing logic from the unit tests can be removed. Also, assertIsNone() is slightly better than assertEquals(None, x). Finally, there is a tiny fix where parse_args() was expected to throw ArgumentParserError but the test would not fail if it threw no exceptions. -- components: Tests files: test_argparse.py.unittest2.patch keywords: patch messages: 113505 nosy: benjamin.peterson, bethard, denversc, eric.smith priority: normal severity: normal status: open title: test_argparse.py: use new unittest features type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file18463/test_argparse.py.unittest2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9554 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9553] test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80
Changes by Denver Coneybeare denver.coneybe...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9554] test_argparse.py: use new unittest features
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Removed file: http://bugs.python.org/file18463/test_argparse.py.unittest2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9554 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9554] test_argparse.py: use new unittest features
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file18464/test_argparse.py.unittest2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9554 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9553] test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Removed file: http://bugs.python.org/file18462/test_argparse.py.COLUMNS.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9553] test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80
Changes by Denver Coneybeare denver.coneybe...@gmail.com: Added file: http://bugs.python.org/file18465/test_argparse.py.COLUMNS.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9537] argparse: use OrderedDict to store subparsers
New submission from Denver Coneybeare denver.coneybe...@gmail.com: Currently, when a subparser is added to an argparse.ArgumentParser the list of subparsers are stored in the built-in dict type. When these subparsers are listed when -h is given on the command line they are showed in the order returned from the dictionary's keys() method, which is undefined order. Instead of showing them in undefined order, it would be preferred to show them at least in the order in which they were added. This can be done trivially be replacing the dict with a collections.OrderedDict. A patch is attached. -- components: Library (Lib) files: argparse.patch keywords: patch messages: 113124 nosy: benjamin.peterson, denversc priority: normal severity: normal status: open title: argparse: use OrderedDict to store subparsers type: behavior versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file18418/argparse.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
