[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 <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 <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\cpython>PCbuild\python_d.exe ThreadingTimerInitDefaultArgsIssueDemo.py args=('blah',) kwargs={'foo': 'bar'} [44758 refs, 17198 blocks] And after the fix: c:\dev\cpython>PCbuild\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 <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 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 <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 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 "", line 1, in 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 <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 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 >>> 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 <http://bugs.python.org/issue3905> ___ ___ 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 : -- type: -> behavior ___ Python tracker <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 : -- keywords: +patch Added file: http://bugs.python.org/file21512/patch_idle_tkinter_import_v1.patch ___ Python tracker <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
New submission from Denver Coneybeare : 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 <http://bugs.python.org/issue11745> ___ ___ 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 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 <http://bugs.python.org/issue1647489> ___ ___ 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 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 <http://bugs.python.org/issue8150> ___ ___ 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 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 <http://bugs.python.org/issue1673007> ___ ___ 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 added the comment: Awesome, thanks for committing the patch. Glad I could help. -- ___ Python tracker <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 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 <http://bugs.python.org/issue9348> ___ ___ 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 : -- nosy: +brett.cannon ___ Python tracker <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 : Added file: http://bugs.python.org/file21206/test_dummy_thread_test_coverage_improvement_v2.patch ___ Python tracker <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
New submission from Denver Coneybeare : 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 <http://bugs.python.org/issue11551> ___ ___ 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 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 <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 : Added file: http://bugs.python.org/file21195/fileinput_unittests_v13.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21193/fileinput_unittests_v12.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21163/fileinput_unittests_v12.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21154/fileinput_unittests_v11.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21153/fileinput_unittests_v10.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21151/fileinput_unittests_v9.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21150/fileinput_unittests_v8.patch ___ Python tracker <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 : Removed file: http://bugs.python.org/file21138/fileinput_unittests_v1.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21149/fileinput_unittests_v7.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21147/fileinput_unittests_v6.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21145/fileinput_unittests_v5.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21141/fileinput_unittests_v3.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file21139/fileinput_unittests_v2.patch ___ Python tracker <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
New submission from Denver Coneybeare : 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 <http://bugs.python.org/issue11509> ___ ___ 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 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 <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 : -- nosy: +brian.curtin versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <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
New submission from Denver Coneybeare : 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 <http://bugs.python.org/issue11491> ___ ___ 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 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 <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 : 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 <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 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 <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 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 <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 : Added file: http://bugs.python.org/file18465/test_argparse.py.COLUMNS.patch ___ Python tracker <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 : Removed file: http://bugs.python.org/file18462/test_argparse.py.COLUMNS.patch ___ Python tracker <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 : Added file: http://bugs.python.org/file18464/test_argparse.py.unittest2.patch ___ Python tracker <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 : Removed file: http://bugs.python.org/file18463/test_argparse.py.unittest2.patch ___ Python tracker <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 : -- type: -> behavior ___ Python tracker <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 : 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 <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
New submission from Denver Coneybeare : 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 <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 : 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 <http://bugs.python.org/issue9537> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com