[issue17911] traceback: add a new thin class storing a traceback without storing local variables
Robert Collins added the comment: w.r.t. a new linecache interface, it looks like we need two attributes from f_globals: __name__ and __loader__, so that we can eventually call __loader__.get_source(__name__). One small change (to let me focus on traceback) would be to add another kw argument to the existing calls that take module_globals, called e.g. get_source, which would be a simple callable (source = get_source()). For the deferred linecache situation, we'd then create partial(f_globals.__loader__.get_source, f_globals.__name__) and keep that around until we need the source. We could even abstract that out into a function in linecache to keep the knowledge in one place. Another way to tackle this would be to add a new function to linecache that lazily seeds the cache: it would stash the get_source method and the name against the filename, and when getline[s] is called actually invoke it. I think the second way is a bit nicer myself. What do folk think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Robert Kuska added the comment:
This commit (probably) breaks aarch64 python build.
See https://bugzilla.redhat.com/show_bug.cgi?id=1174037
Build was done with libffi 3.1.6, I have also tried with latest upstream libffi
version with same result.
(gdb) b ReturnRect
Function ReturnRect not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (ReturnRect) pending.
(gdb) run test_win32.py
Starting program: /usr/bin/python test_win32.py
Missing separate debuginfos, use: debuginfo-install
glibc-2.20.90-12.fc22.aarch64
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
Breakpoint 1, ReturnRect (i=0, ar=..., br=0x59b750, cp=..., dr=...,
er=0x59b750, fp=...,
gr=error reading variable: Cannot access memory at address
0x)
at /usr/src/debug/Python-2.7.9/Modules/_ctypes/_ctypes_test.c:552
552 if (ar.left + br-left + dr.left + er-left + gr.left != left * 5)
(gdb) p fp
$1 = {x = 4396722194992, y = 5879632}
(gdb) p cp
$2 = {x = 15, y = 25}
(gdb)
--
nosy: +rkuska
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20160
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12681] unittest expectedFailure could take a message argument like skip does
Changes by Robert Collins robe...@robertcollins.net: -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12681 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23110] Document if argument to Py_SetPath requires static storage.
New submission from Robert Snoeberger: The documentation for the Py_SetPath API does not indicate if the argument should point to a wide character array in static storage. However, the documentation for Py_GetPath says, The returned string points into static storage; the caller should not modify its value. This leads me to believe that static storage is required for Py_SetPath. The documentation for similar API functions, Py_SetPythonHome and Py_SetProgramName, indicates, The argument should point to a zero-terminated wide character string in static storage whose contents will not change -- assignee: docs@python components: Documentation messages: 233081 nosy: docs@python, snoeberger priority: normal severity: normal status: open title: Document if argument to Py_SetPath requires static storage. type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23110 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17911] traceback: add a new thin class storing a traceback without storing local variables
Robert Collins added the comment: I'll put something together. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22638] ssl module: the SSLv3 protocol is vulnerable (POODLE attack)
Robert Kuska added the comment: FYI fedora (rawhide) has SSLv3 disabled in SSLv23 method of openssl package. http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?id=80b5477597e9f0d9fababd854adfb4988b37efd5 This looks like the same approach as in attached issue22638.diff. -- nosy: +rkuska ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22638 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22936] traceback module has no way to show locals
New submission from Robert Collins: From https://github.com/testing-cabal/testtools/issues/111 - any code that is data dependent can be hard to diagnose from a backtrace alone. Many unittest and server environments address this by doing custom tracebacks that include locals. To address this in unittest, we need to add a similar capacity to traceback, and then use it from unittest (as we can't just depend on a module from PyPI in the stdlib). -- components: Library (Lib) messages: 231628 nosy: rbcollins priority: normal severity: normal status: open title: traceback module has no way to show locals versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22936 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22936] traceback module has no way to show locals
Changes by Robert Collins robe...@robertcollins.net: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22936 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22937] unittest errors can't show locals
New submission from Robert Collins: From https://github.com/testing-cabal/testtools/issues/111 - any code that is data dependent can be hard to diagnose from a backtrace alone. Many unittest and server environments address this by doing custom tracebacks that include locals. To address this in unittest, we need to add a similar capacity to traceback, and then use it from unittest (as we can't just depend on a module from PyPI in the stdlib). This issue is for the unittest part of it. For the traceback dependency see http://bugs.python.org/issue22936 . -- components: Library (Lib) messages: 231629 nosy: rbcollins priority: normal severity: normal status: open title: unittest errors can't show locals type: enhancement versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22937 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22936] traceback module has no way to show locals
Robert Collins added the comment: See http://bugs.python.org/issue22936 for the unittest aspect of this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22936 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22886] TestProgram leaves defaultTestLoader.errors dirty
New submission from Robert Collins: TestProgram leaves defaultTestLoader.errors dirty. This primarily affects tests but it would be good hygiene to clear it at the end of TestProgram. -- components: Library (Lib) messages: 231261 nosy: rbcollins priority: normal severity: normal status: open title: TestProgram leaves defaultTestLoader.errors dirty type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22886 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22431] Change format of test runner output
Robert Collins added the comment: Yes, making customising the output easier is a good thing. One way is to use e.g. subunit.run (which can work with all unittest versions since 2.6) and write a custom filter. Or a custom TestResult and TextTestRunner can work too :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22431 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22858] unittest.__init__:main shadows unittest.main
New submission from Robert Collins: This is just an ugly/hygiene thing. Since we've never advertised the submodules as the API, we should be able to fix this by moving main.py to e.g. __main__.py. -- messages: 231101 nosy: rbcollins priority: normal severity: normal status: open title: unittest.__init__:main shadows unittest.main ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22858 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22858] unittest.__init__:main shadows unittest.main
Changes by Robert Collins robe...@robertcollins.net: -- components: +Library (Lib) type: - behavior versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22858 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22859] unittest.TestProgram.usageExit no longer invoked
New submission from Robert Collins: Before the argparse migration usageExit was invoked and could be extended via subclasses, but it no longer is. We could delete it (and document it being no longer accessible) or put some glue in to reinstate it. I think deleting it is fine, as long as we make the argparse parser objects part of the API (so that folk have a reliable place to poke at to change help). -- messages: 231102 nosy: rbcollins priority: normal severity: normal status: open title: unittest.TestProgram.usageExit no longer invoked ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22859 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22859] unittest.TestProgram.usageExit no longer invoked
Changes by Robert Collins robe...@robertcollins.net: -- components: +Library (Lib) type: - behavior versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22859 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22860] unittest TestProgram hard to extend
New submission from Robert Collins: Some users of TestProgram would like to add options (e.g. testtools.run adds --list and --load-list) but there isn't a clean point to add them without bulk copying the implementation around. We likely need some extra extension points as well - one reasonable test would be to make sure that testtools.run's TestProgram can be made much smaller by whatever patch fixes this bug. -- components: Library (Lib) messages: 231103 nosy: rbcollins priority: normal severity: normal status: open title: unittest TestProgram hard to extend type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22860 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21724] resetwarnings doesn't reset warnings registry
Changes by Robert Muil robertm...@gmail.com: -- nosy: +robertmuil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21724 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22452] addTypeEqualityFunc is not used in assertListEqual
Robert Collins added the comment: https://code.google.com/p/unittest-ext/issues/detail?id=11 I think that the hamcrest inspired matchers stuff may help make this a reality too. OTOH if we had a clean patch now for the existing asserts that would be fine too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22452 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22812] Documentation of unittest -p usage wrong on windows.
New submission from Robert Collins: From https://code.google.com/p/unittest-ext/issues/detail?id=13 The following is incorrect on Windows: python -m unittest discover -p '*.py' It should be without the single quotes around the .py: python -m unittest discover -p *.py This needs to be documented. -- assignee: docs@python components: Documentation messages: 230777 nosy: docs@python, rbcollins priority: normal severity: normal status: open title: Documentation of unittest -p usage wrong on windows. versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22812 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22813] No facility for test randomisation
New submission from Robert Collins: Unittest doesn't support a test randomisation feature. Such a feature should support: - passing in a seed (to allow reproducing the order for debugging) - preserving the suite hierarchy, to preserve class and module setUp performance optimisations - and randomising globally with cloned suite hierarchies, for more comprehensive randomisation - allowing some scopes to opt out of randomisation (where tests really have dependencies on execution order and thats what the test author wants) From https://code.google.com/p/unittest-ext/issues/detail?id=6 -- components: Library (Lib) messages: 230778 nosy: rbcollins priority: normal severity: normal status: open title: No facility for test randomisation versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22813 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22814] TestProgram loading fails when a script is used
New submission from Robert Collins: If someone has a TestProgram script - e.g. the unit2 script in unittest2, loading a module in cwd will fail, because the PYTHONPATH doesn't include '.'. We might want to consider adding cwd to the PYTHONPATH in TestProgram. From https://code.google.com/p/unittest-ext/issues/detail?id=18 -- components: Library (Lib) messages: 230782 nosy: rbcollins priority: normal severity: normal status: open title: TestProgram loading fails when a script is used type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22815] unexpected successes are not output
New submission from Robert Collins: Unexpected successes cause failures, but we don't output details about them at the end of the run. From https://code.google.com/p/unittest-ext/issues/detail?id=22 A complicating factor is that we don't have a backtrace to show - but we may have captured stdout/stderr or in future various test attachments to show. -- components: Library (Lib) messages: 230783 nosy: rbcollins priority: normal severity: normal status: open title: unexpected successes are not output type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22815 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22452] addTypeEqualityFunc is not used in assertListEqual
Robert Collins added the comment: See also https://code.google.com/p/unittest-ext/issues/detail?id=27 Sorry, wrong wording of the bug. I tested this on IronPython 2.6.1 and 2.7.b1. I see the same result as you and I consider the following wrong or at least misleading: - [1, Decimal(1), Decimal(2.00)] ? ^ --- + [2, Decimal(1.00), Decimal(2)] ? ^+++ I mean the +++ and --- under Decimal numbers. On the other hand I understand that these are differences in string representation of those lists... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22452 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10611] sys.exit() in a test causes a test run to die
Robert Collins added the comment: Hmm, so testtools went in a different direction here - the same unification stuff, but see https://github.com/testing-cabal/testtools/commit/18bc5741cf277f7a0d601568be6dccacc7b0783c tl;dr - I think unittest should not prevent this causing the process to exit (but it should still fail the test and fail the test run as a whole), analgous to how KeyboardInterrupt is handled. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10611 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] document (lack of) interaction between @expectedException on a test_method and setUp
Changes by Robert Collins robe...@robertcollins.net: -- title: Error in setUp not reported as expectedFailure (unittest) - document (lack of) interaction between @expectedException on a test_method and setUp ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22431] Change format of test runner output
Robert Collins added the comment: I don't consider the console output of unittest to be a stable interface. Michael - do you? Things that want to process unittest should be using the API. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22431 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22812] Documentation of unittest -p usage wrong on windows.
Robert Collins added the comment: I agree. IIRC the windows shell passes the argument as '*.py' rather than as *.py, so when we glob it we get no files, as no python files end with an apostrophe. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22812 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Robert Collins added the comment: Hi, I'm glad you're interested in this. I very much want to see a matcher/hamcrest approach rather than a library of assertions per se - because match-or-except makes layering things harder. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11664] Add patch method to unittest.TestCase
Robert Collins added the comment: +1 on a plain function or context manager. w.r.t. addCleanUp taking a context manager, that could be interesting - perhaps we'd want a thing where you pass it the context manager, it __enter__'s the manager and then calls addCleanUp for you. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22813] No facility for test randomisation
Robert Collins added the comment: b) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22813 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7559] TestLoader.loadTestsFromName swallows import errors
Robert Collins added the comment: Its backported in unittest2 0.8.0 which is available on pypi for 2.6+ and 3.2+. The changes are large enough that I'd hesitate to backport them in cPython itself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7559 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22811] _top_level_dir state leaks on defaultTestLoader
New submission from Robert Collins:
TestProgram uses defaultTestLoader to load tests. Calling discover() on a
TestLoader sets _top_level_dir. Calling discover with no top_level_dir
implictly sets _top_level_dir but only the first time: the second time it is
called with a different start_dir the prior one is used.
This leads to errors like:
==
ERROR: test_run_list_failed_import (testtools.tests.test_run.TestRun)
testtools.tests.test_run.TestRun.test_run_list_failed_import
--
_StringException: Traceback (most recent call last):
File /home/robertc/personal/testtools/testtools/tests/test_run.py, line
175, in test_run_list_failed_import
run.main, ['prog', 'discover', '-l', broken.package.base, '*.py'], out)
File /home/robertc/personal/testtools/testtools/testcase.py, line 420, in
assertRaises
self.assertThat(our_callable, matcher)
File /home/robertc/personal/testtools/testtools/testcase.py, line 431, in
assertThat
mismatch_error = self._matchHelper(matchee, matcher, message, verbose)
File /home/robertc/personal/testtools/testtools/testcase.py, line 481, in
_matchHelper
mismatch = matcher.match(matchee)
File /home/robertc/personal/testtools/testtools/matchers/_exception.py,
line 108, in match
mismatch = self.exception_matcher.match(exc_info)
File /home/robertc/personal/testtools/testtools/matchers/_higherorder.py,
line 62, in match
mismatch = matcher.match(matchee)
File /home/robertc/personal/testtools/testtools/testcase.py, line 412, in
match
reraise(*matchee)
File /home/robertc/personal/testtools/testtools/matchers/_exception.py,
line 101, in match
result = matchee()
File /home/robertc/personal/testtools/testtools/testcase.py, line 965, in
__call__
return self._callable_object(*self._args, **self._kwargs)
File /home/robertc/personal/testtools/testtools/run.py, line 413, in main
stdout=stdout)
File /home/robertc/personal/testtools/testtools/run.py, line 208, in
__init__
self.parseArgs(argv)
File /home/robertc/personal/testtools/testtools/run.py, line 252, in
parseArgs
self._do_discovery(argv[2:])
File /home/robertc/personal/testtools/testtools/run.py, line 368, in
_do_discovery
loaded = loader.discover(self.start, self.pattern, self.top)
File
/home/robertc/.virtualenvs/testtools-2.7/local/lib/python2.7/site-packages/unittest2/loader.py,
line 353, in discover
raise ImportError('Start directory is not importable: %r' % start_dir)
ImportError: Start directory is not importable: '/tmp/tmpac4uwI'
When a test tries to test the behaviour of TestProgram (or a subclass thereof).
The fix is straight forward: at the end of discover restore the value of
_top_level_dir that it had at entry.
--
messages: 230770
nosy: rbcollins
priority: normal
severity: normal
status: open
title: _top_level_dir state leaks on defaultTestLoader
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22811
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22811] _top_level_dir state leaks on defaultTestLoader
Changes by Robert Collins robe...@robertcollins.net: -- components: +Library (Lib) versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22811 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22794] missing test for issue 22457 regression commit
New submission from Robert Collins: I did a brownbag fix for my change to issue22457 which exposed a untested corner case - this issue is for me to come back and add a regression test for it. -- messages: 230628 nosy: rbcollins priority: normal severity: normal status: open title: missing test for issue 22457 regression commit versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22794 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22680] unittest discovery is fragile
Robert Collins added the comment: This was reported as https://code.google.com/p/unittest-ext/issues/detail?id=71 a while back. I think blacklisting FunctionTestCase in TestLoader is entirely reasonable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22680 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Changes by Robert Collins robe...@robertcollins.net: Added file: http://bugs.python.org/file37118/issue22457.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
New submission from Robert Collins: test_assertRaises_frames_survival (unittest2.test.test_assertions.Test_Assertions Depends on refcount behaviour to pass - adding a gc.collect() before the weakref checks is sufficient to fix things on pypy. test_no_exception_leak (unittest2.test.test_case.Test_TestCase similarly here adding a juidicious gc.collect solves the issue. -- messages: 230258 nosy: rbcollins priority: normal severity: normal status: open title: object lifetime fragility in unittest tests versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Robert Collins added the comment: Herewith a patch. Applied to unittest2 for backport to unbreak its tests on pypy. -- keywords: +patch Added file: http://bugs.python.org/file37072/issue22764.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Changes by Robert Collins robe...@robertcollins.net: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Robert Collins added the comment: Hmm? I must have misunderstood the test. Here's my understanding: the test is testing that a an object ref only held in the traceback object of the exception is cleaned up such that it can be collected. In a refcount system that collection is immediate, in a gc world its after the next gc run. Ah, perhaps the test was flawed to start with, since no effort is made in it to capture the error and then process it. If we pass a result in, the traceback will have a ref and gc.collect() can't possibly be discarding the entire structure. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Robert Collins added the comment: I've done some experimentation. Yes, the updated test passes when the clear_frames call is removed in cPython 3.5 But the original test also passes when clear_frames is not called if one drops into pdb and steps through, which still fits the symptoms of having a loop. The problem is then, that gc-only interpreters make no guarantees about lifetime of objects and this test needs a guarantee. As such I think conditional skipping is probably best. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Changes by Robert Collins robe...@robertcollins.net: Added file: http://bugs.python.org/file37080/issue22764.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22153] Documentation of TestCase.runTest is incorrect and confusing
Robert Collins added the comment: I'll apply the patch monday if there are no further comments before then. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Robert Collins added the comment: (Pinging for reviews - I'm going to time out and land this early next week if I can't get a review on it, since this is actually a fairly significant oversight and I don't want unittest2 to run ahead of the stdlib - that way leads unmaintainable madness). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22153] There is no standard TestCase.runTest implementation
Robert Collins added the comment: Oh, one thought - in testtools we split out 'docs for test writers' and 'docs for framework folk'. That would facilitate getting runTest out of test writers face while still documenting it appropriately. Related to that is my ongoing push to split the protocol so that these concerns are not intertwined the way they are today, but that needs to wait for the existing backlog to clear up :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22153] Documentation of TestCase.runTest is incorrect and confusing
Changes by Robert Collins robe...@robertcollins.net: -- title: There is no standard TestCase.runTest implementation - Documentation of TestCase.runTest is incorrect and confusing ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22763] load_tests chaining into discover from non-discover entry point gets top_level_dir wrong
New submission from Robert Collins:
The following trivial chain-into-discover load_tests:
def load_tests(loader, tests, pattern):
import os.path
# top level directory cached on loader instance
this_dir = os.path.dirname(__file__)
return loader.discover(start_dir=this_dir, pattern=pattern)
Will work fine when that module was loaded by discover in the first place, but
if the entry point was e.g. loader.loadTestsFromModule then it will fail
because _top_level_dir starts None and is, if not supplied, inferred from
start_dir.
One possible way to improve this would be to check for start_dir being a child
of rather than just an exact match of, the elements of sys.path. This isn't
complete of course, because individual packages can have their own path. And we
also compare with top_level_dir to assess importability - but perhaps we can
deprecate/ get rid of the top_level_dir concept entirely - it only has two
functional uses: a) making it possible to import things when the path to be
discovered isn't on sys.path yet, which could be done by the unittest front
end, leaving the core API less complicated, and b) to map from paths back to
modules which is complicated by the need to handle namespaces and other
packages with multiple directories providing modules. (Because load_tests can
chain into other directories that aren't under top_level_dir this same bug can
show up in the inverse situation).
Another possibility would be to make a new api 'discover from a package' and
split discover's internals into 'find packages' and then a chain call to this
new api. I'm in favour of this latter approach because I think it will have
less compromises and work better. It might also make it easier for us in fixing
the rather ugly thing at the moment where discover('foo.bar') adds foo.bar to
sys.path before figuring out that its a module dotted path, not a filesystem
path.
--
messages: 230253
nosy: rbcollins
priority: normal
severity: normal
status: open
title: load_tests chaining into discover from non-discover entry point gets
top_level_dir wrong
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22763
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Robert Collins added the comment: Updated patch, after other recent conflicting changes. -- Added file: http://bugs.python.org/file37071/issue22457.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Changes by Robert Collins robe...@robertcollins.net: -- type: - behavior versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22153] There is no standard TestCase.runTest implementation
Robert Collins added the comment: runTest is part of the current API. I think if we're going to hide it we should do so as part of a deprecation path. (I'm +1 on hiding it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21820] unittest: unhelpful truncating of long strings.
Changes by Robert Collins robe...@robertcollins.net: -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21820 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22153] There is no standard TestCase.runTest implementation
Robert Collins added the comment: Constructing test case objects directly is part of the protocol, and its needed for framework and extension authors. I've seen folk use runTest, but rarely enough that I think we could deprecate it. My argument is that while its supported we should be clear about when it should be used, and how. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22756] testAssertEqualSingleLine gives poor errors
New submission from Robert Collins: found while backporting unittest fixes. The current test fails like so: == FAIL: testAssertEqualSingleLine (unittest2.test.test_case.Test_TestCase) -- Traceback (most recent call last): File /home/robertc/work/unittest2.hg/unittest2/test/test_case.py, line 1014, in testAssertEqualSingleLine self.assertEqual(sample_text, revised_sample_text) AssertionError: 'laden swallows fly slowly' != 'unladen swallows fly quickly' - laden swallows fly slowly? + unladen swallows fly quickly? ++ ^ During handling of the above exception, another exception occurred: Traceback (most recent call last): File /home/robertc/work/unittest2.hg/unittest2/test/test_case.py, line 1017, in testAssertEqualSingleLine self.assertTrue(sample_text_error == error) AssertionError: False is not true - it shouldn't be using assertTrue. -- messages: 230194 nosy: rbcollins priority: normal severity: normal status: open title: testAssertEqualSingleLine gives poor errors ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22756] testAssertEqualSingleLine gives poor errors
Robert Collins added the comment: There's comments in the test above about 'not testing ourself with ourselves' - but we're testing the rendering of an error case, so its entirely legitimate to use the same method's success path to check equality. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22756] testAssertEqualSingleLine gives poor errors
Changes by Robert Collins robe...@robertcollins.net: -- keywords: +patch Added file: http://bugs.python.org/file37057/issue22756.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7559] TestLoader.loadTestsFromName swallows import errors
Robert Collins added the comment: I've updated the patch to try and address the niggling clarity issues from the review. Please let me know what you think (and if I hear nothing I'll commit it as-is since the review was still ok). -- Added file: http://bugs.python.org/file37045/issue7559.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7559 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Robert Collins added the comment:
assertions in setUp are fine IMO. But here's the thing. WHat should this code
do?
class Demo(unittest.TestCase):
def setUp(self):
raise Exception('hi')
def test_normal(self):
# this should NOT be covered by expectedFailure
pass
@unittest.expectedFailure
def test_expected_fail(self):
pass
This will fail today because the decorator doesn't affect setUp.
If we apply a patch to change this, it will fail because test_normal doesn't
apply the decorator.
I can imagine with dependency injection that one could set this up and have it
genuinely configured correctly: but if one is doing that I'd expect the
dimension of variance to be per scenario, not per test method. So it still
wouldn't make sense to me.
@nick - yes, thats exactly right, this is at most docs IMO.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10548
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Robert Collins added the comment: A few thoughts. Adding a new public symbol seems inappropriate here: this is a performance issue that is well predictable and we should cater for that (given difflibs current performance). I'll note in passing that both bzr and hg have much higher performance difference algorithms that we could pick up and includes as a replacement SequenceMatcher, which might significantly reduce the threshold at which we need to default-cap things - but such a threshold will still exist. I totally agree that _diffThreshold should apply to non-string sequences - anything where we're going to hit high-order complexity outputting the difference. That said, I speculate that perhaps we'd be better off outputting both objects in some structured fashion and letting a later process render them (for things like CI systems and test databases, where fidelity of reproduction is more important than having the output fit on one screen. This is a different issue though and something we should revisit later. That suggests to me though that the largest diff we output should be chosen based on the textual representation of the diff - we're doing it for human readability. Whereas the threshold for calculating a diff at all should be based on performance. It can be very expensive to calculate a diff on large sequences, but the diff might be much much larger than the sequence length indicates [because each item in the sequence may be very large]. Perhaps thats over thinking it? Anyhow- short term, surely just making the threshold apply to any sequenced type is sufficient to fix the bug? -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19217 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Robert Collins added the comment: Just to note that unittest2 tip (unreleased)had michaels proposed fix, which is different to that here. I'm going to back that out before doing a release, because they should be harmonisious. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Robert Collins added the comment: My take on this, FWIW, is that any methods in the under-test API - setUp, tearDown, test_* and anything registered via addCleanup should all support the same protocol as much as possible, whatever it is. That is, raising a skip in setUp should skip the test. raising a skip in tearDown should skip the test, and raising a skip from a cleanup should skip the test. This is complicated by the case where some code is called after exceptions- teardown and cleanups. Thats fairly straight forward: errors are higher precedence than failure than skips than anything which resolved as a pass. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Robert Collins added the comment: I'd argue for - An error - its not covered by the decorator. - An error - the last two are not covered by the decorator. - An error - the last two are not covered by the decorator. - An error - the exception isn't a 'failure' [today - we should revisit this but its a separate issue to the code coverage aspect and the last two aren't covered by the decorator. Perhaps I'm infected by knowing too much about the plumbing, but we can make things *super* complex (both implementation and reasoning-about-for-users) if we are too clever - and making the decorator affect multiple different methods is very much across that line IMO. If the test itself fails as expected, then I'm OK with cleanup code also failing as a consequence. I'm not unless we've got a really specific reason to be OK with it - in my experience that will mask nasty things like leaked temp files which can have bad consequences - and because its masked its then hard for developers to diagnose. So its bad all around. However, I'd also be OK with the simpler model that treats the decorator as covering the whole setUp/test/cleanUp/tearDown cycle, in which case an exception from *any* of those methods would be categorised as satisfying the expected failure decorator. So - I think a simpler still model which is that the decorator covers the decorated code is better still, as it doesn't need any explanation about how its different to regular python decorators. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Robert Collins added the comment: Oh, I got a profile from the test case for my own interest. 6615 seconds .. some highlights that jumped out at me 200010.1270.000 6610.0250.330 difflib.py:868(compare) which means we're basically using ndiff, which is cubic rather than quadratic - the same performance issue the html module had. I think we'll probably make a better tradeoff by using unified_diff instead which is quadratic. -- Added file: http://bugs.python.org/file37001/issue19217-profile.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19217 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7559] TestLoader.loadTestsFromName swallows import errors
Robert Collins added the comment: Thanks for the review, updated patch here - I'll let this sit for a day or two for more comments then commit it Monday. -- Added file: http://bugs.python.org/file37002/issue7559.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7559 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
Robert Collins added the comment: Yeah thats nicer. I'll apply that later unless you can. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
Robert Collins added the comment: Showing it only when False would have higher cognitive load. Showing it always is simple and clear. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Changes by Robert Collins robe...@robertcollins.net: Removed file: http://bugs.python.org/file36716/issue22457.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Robert Collins added the comment: Updated patch. -- Added file: http://bugs.python.org/file36973/issue22457.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
Changes by Robert Collins robe...@robertcollins.net: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7559] TestLoader.loadTestsFromName swallows import errors
Changes by Robert Collins robe...@robertcollins.net: Added file: http://bugs.python.org/file36974/issue7559.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7559 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7559] TestLoader.loadTestsFromName swallows import errors
Robert Collins added the comment: Patch polished up and updated - ready for review IMO. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7559 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22673] Incorrect fileno for CONOUT$ / stdout
Robert Collins added the comment: I think its worth a note that the stdio streams are constructed specially, even with the repr improvements. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22673 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16662] load_tests not invoked in package/__init__.py
Robert Collins added the comment: Closing as the fix to the test suite is applied. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22663] patchcheck alters content of .png files
New submission from Robert Collins: cpython.hg$ make patchcheck ./python ./Tools/scripts/patchcheck.py Getting the list of files that have been added/changed ... 448 files Fixing whitespace ... 0 files Fixing C file whitespace ... 5 files: Include/patchlevel.h Modules/_ctypes/callbacks.c Modules/_io/_iomodule.c Modules/_io/fileio.c Modules/_posixsubprocess.c Fixing docs whitespace ... 1 file: Doc/tools/static/py.png Docs modified ... yes Misc/ACKS updated ... yes Misc/NEWS updated ... yes configure regenerated ... yes pyconfig.h.in regenerated ... no Note the change to py.png: its not a text filetohave its whitespace changed :/. -- messages: 229609 nosy: rbcollins priority: normal severity: normal status: open title: patchcheck alters content of .png files ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22663 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16079] list duplicate test names with patchcheck
Robert Collins added the comment: FWIW testtools rejects test suites with duplicate test ids; I'm considering adding that feature into unittest itself. We'd need an option to make it warn rather than error I think, but if we did that we wouldn't need a separate script at all. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16079 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11664] Add patch method to unittest.TestCase
Robert Collins added the comment: FWIW I'd really like to be reducing the TestCase API not extending it - particularly since there are lots of good convenient ways of doing this already (not least mock.patch/mock.patch.object). So I'm -0.5 on adding this, as I don't see it adding value. That said, I'll happily review for correctness if there is consensus that we want it. Relatedly I'd like to find some way to let regular functions tie into cleanups automatically, so that we don't need helpers like this *at all*. That probably needs a PEP though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.util.dump_wsgistr load_wsgistr
Robert Collins added the comment:
So this looks like its going to instantly create bugs in programs that use it.
HTTP/1.1 headers are one of:
latin1
MIME encoded (RFC2047)
invalid and working only by accident
HTTP/2 doesn't change this.
An API that encourages folk to encode into utf8 and then put that in their
headers is problematic.
Consider:
def dump_wsgistr(data, encoding, errors='strict'):
data.encode(encoding, errors).decode('iso-8859-1')
This takes a string that one wants to put into a header value, encodes it with
a *user specified encoding*, then decodes that into iso-8859-1 [at which point
it can be encoded back to octets by the wsgi server before putting on the wire].
But this is fundamentally wrong in the common case: either 'data' is itself
suitable as a header value (e.g. it is ASCII - recommended per RFC7230 section
3.2.4) or 'data' needs encoding via RFC 2047 encoding not via utf8.
There are a few special cases where folk have incorrectly shoved utf8 into
header values and we need to make it possible for folk working within WSGI to
do that - which is why the API is the way it is - but we shouldn't make it
*easier* for them to do the wrong thing.
I'd support an API that DTRT here by taking a string, tries US_ASCII, with
fallback to MIME encoded with utf8 as the encoding parameter.
--
nosy: +rbcollins
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22264
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21472] Fix wsgiref handling of absolute HTTP Request-URI
Robert Collins added the comment: FWIW we probably need to capture the original unaltered URL somewhere, but also ensure that PATH_INFO is always a relative path. One should be able to implement a proxy in WSGI (because thats just another specialised app), and doing that today requires special handling depending on the WSGI container, which isn't great for consistency. On security; Host header - url host mismatches occur when the host to which a request is sent != the url; this is expected only in the case of forward proxies: any other time it would indeed be a smuggling attack, trying to find mismatches between acls and access in servers - this is another reason to consolidate things so that wsgi apps can rely on urls looking consistent. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21472 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21472] Fix wsgiref handling of absolute HTTP Request-URI
Robert Collins added the comment: Oh, also - while its tempting to say that it doesn't matter whether we take the urls host portion, or the host header or the server name - it does. Deployments that look like: LB/Firewall - backend container - WSGI app are likely to have assumptions within the WSGI app about what sort of urls they expect to reach them. We can mitigate this by being very explicit about whatever solution we have. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21472 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.util.dump_wsgistr load_wsgistr
Robert Collins added the comment: So I guess the API concern I have is that there are two cases: - common spec compliant - US-ASCII + RFC2047 - dealing with exceptions - UTF8 or otherwise The former totally makes sense as a codec, though the current email implementation of it isn't quite a codec. The latter almost wants to be a separate API, which I may propose as part of WSGI for HTTP/2; nevertheless in PEP- its integral to the main API because of the bytes-encoded-as-codepoints-00-ff solution. So, perhaps: - a codec or something looking like it that covers the common case this would not permit specifying codecs on decode, for instance [since RFC2047 is self describing]. - documentation for the uncommon case. *Possibly* a helper function. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22264 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16662] load_tests not invoked in package/__init__.py
Robert Collins added the comment: Fix up the tests patch - tested on windows 7. -- Added file: http://bugs.python.org/file36713/fix-windows-tests.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16662] load_tests not invoked in package/__init__.py
Robert Collins added the comment: bah, wrong extension to trigger review code :) -- Added file: http://bugs.python.org/file36714/fix-windows-tests.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16662] load_tests not invoked in package/__init__.py
Changes by Robert Collins robe...@robertcollins.net: Removed file: http://bugs.python.org/file36713/fix-windows-tests.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22489] .gitignore file
New submission from Robert Collins: The .gitignore file was missing some build products on windows. The attached patch makes the tree be clean after doing a debug build. -- files: windows-git-ignore.diff keywords: patch messages: 227498 nosy: rbcollins priority: normal severity: normal status: open title: .gitignore file Added file: http://bugs.python.org/file36715/windows-git-ignore.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22489 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Robert Collins added the comment: Updated patch - fixes windows tests for this patch. -- Added file: http://bugs.python.org/file36716/issue22457.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19746] No introspective way to detect ModuleImportFailure in unittest
Robert Collins added the comment: Right: the existing code stringifies the original exception and creates an exception object and a closure def test_thing(self): raise exception_obj but that has the stringified original exception. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19746 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Robert Collins added the comment: This should fix this issue :) -- keywords: +patch Added file: http://bugs.python.org/file36694/issue22457.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16662] load_tests not invoked in package/__init__.py
Robert Collins added the comment: I've managed to get a windows setup working. Its my mini-vfs which needs to be Windows aware (because the abs path of /foo is C:\\foo). I'll work up a patch tomorrowish. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19746] No introspective way to detect ModuleImportFailure in unittest
Robert Collins added the comment: I can certainly write the reporter glue to work with either a string or a full reference. Note that the existing late-reporting glue captures the import error into a string, and then raises an exception containing that string - so what I've done is consistent with that. As for why the original code is like that - well I've had plenty of bad experiences with memory loops due to objects held in stack frames of exceptions, I don't like to keep long lived references to them, and I wager Michael has had the same experience. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19746 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
New submission from Robert Collins: python -m unittest discover -t . foo where foo is a package will not trigger load_tests in foo/__init__.py. To reproduce: mkdir -p demo/tests cd demo cat EOF tests/__init__.py import sys import os def load_tests(loader, tests, pattern): print(HI WE ARE LOADING!) this_dir = os.path.dirname(__file__) tests.addTest(loader.discover(start_dir=this_dir, pattern=pattern)) return tests EOF python -m unittest discover -t . tests -- messages: 227250 nosy: rbcollins priority: normal severity: normal status: open title: load_tests not invoked in root __init__.py when start=package root ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7559] TestLoader.loadTestsFromName swallows import errors
Robert Collins added the comment: You may need to apply the patch from http://bugs.python.org/issue19746 first as well - I was testing with both applied. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7559 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7559] TestLoader.loadTestsFromName swallows import errors
Robert Collins added the comment: This is what I see in my tree: E == ERROR: test_os (unittest.loader.ModuleImportFailure) -- Traceback (most recent call last): File /home/robertc/work/cpython/Lib/unittest/case.py, line 58, in testPartExecutor yield File /home/robertc/work/cpython/Lib/unittest/case.py, line 577, in run testMethod() File /home/robertc/work/cpython/Lib/unittest/loader.py, line 36, in testFailure raise exception ImportError: Failed to import test module: test_os Traceback (most recent call last): File /home/robertc/work/cpython/Lib/unittest/loader.py, line 146, in loadTestsFromName module = __import__(module_name) File /home/robertc/work/cpython/Lib/test/test_os.py, line 5, in module import broken ImportError: No module named 'broken' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7559 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7559] TestLoader.loadTestsFromName swallows import errors
Robert Collins added the comment: Raced with your comment. Great - and thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7559 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19746] No introspective way to detect ModuleImportFailure in unittest
Robert Collins added the comment:
Thanks; I'm still learning how to get the system here to jump appropriately :).
I thought I'd told hg to reset me to trunk...
You are right about the docs. Reading that, I thought it was saying that
errors would have a list of the errors that show up in the summary as Errors=N,
and not the ones that show up as Failures=N, which of course is completely off
base for two reasons (but, then, I can never remember the difference between
Failure and Error and always ignore what type the test failures are).
Ah, so this is specifically about *loader* errors, nothing to do with the ERROR
and FAILURE concepts for the TestResult class; that definitely needs to be made
more clear.
Anyway, you probably want to talk about actual error types. I understand
ImportError, but I have no idea what would trigger the 'Failed to call
load_tests' error. Nor is it clear what would be a fatal error (easier just to
say which errors are trapped, I think).
'Failed to call load_tests' is an existing error that can be triggered if a
load_tests method errors.
e.g. put this in a test_foo.py:
def load_tests(loader, tests, pattern):
raise Exception('fred')
to see it with/without the patch. I'll take a stab at improving the docs in a
bit.
It should also be mentioned that the contents of the list are an error message
followed by a full traceback. And, frankly, I'm not sure why this is useful,
and in particular why this implementation satisfies your use case.
Ah! So I have an external runner which can enumerate the tests without running
them. This is useful when the test suite is being distributed across many
machines (simple hash based distribution can have very uneven running times, so
enumerating the tests that need to run then scheduling based on runtime (or
other metadata) gets better results). If the test suite can't be imported I
need to show the failure of the import to users so they can fix it, but since
the test suite may take hours (or even not be runnable locally) I need to do
this without running the tests. Thus a simple list of the tracebacks
encountered loading the test suite is sufficient. Where would be a good place
to make this clearer?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19746
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21929] Rounding properly
Robert added the comment: I'm not sure if this is related or not, but on 3.4.1 I get the following: print(round(float(3/2))) 2 (as expected) print(round(float(5/2))) 2 (expected 3, as float should round .5 up) -- nosy: +fenofonts ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21929 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16662] load_tests not invoked in package/__init__.py
Robert Collins added the comment:
Thanks for landing this barry, there's a couple quirks with your improvements -
loadTestsFromModule(mod, foo, bar) will raise a TypeError but not warn about
foo the way loadTestsFromModule(mod, foo) will.
Secondly, the TypeError has an off-by-one error in its output:
loadTestsFromModule(mod, foo, bar) will claim 2 arguments were passed. Three
were.
diff -r d0ff527c53da Lib/unittest/loader.py
--- a/Lib/unittest/loader.pyMon Sep 08 14:21:37 2014 -0400
+++ b/Lib/unittest/loader.pyTue Sep 09 07:32:05 2014 +1200
@@ -79,12 +79,12 @@
# use_load_tests argument. For backward compatibility, we still
# accept the argument (which can also be the first position) but we
# ignore it and issue a deprecation warning if it's present.
-if len(args) == 1 or 'use_load_tests' in kws:
+if len(args) or 'use_load_tests' in kws:
warnings.warn('use_load_tests is deprecated and ignored',
DeprecationWarning)
kws.pop('use_load_tests', None)
if len(args) 1:
-raise TypeError('loadTestsFromModule() takes 1 positional argument
but {} were given'.format(len(args)))
+raise TypeError('loadTestsFromModule() takes 1 positional argument
but {} were given'.format(len(args) + 1))
if len(kws) != 0:
# Since the keyword arguments are unsorted (see PEP 468), just
# pick the alphabetically sorted first argument to complain about,
diff -r d0ff527c53da Lib/unittest/test/test_loader.py
--- a/Lib/unittest/test/test_loader.py Mon Sep 08 14:21:37 2014 -0400
+++ b/Lib/unittest/test/test_loader.py Tue Sep 09 07:32:05 2014 +1200
@@ -272,7 +272,7 @@
# however use_load_tests (which sorts first) is ignored.
self.assertEqual(
str(cm.exception),
-'loadTestsFromModule() takes 1 positional argument but 2 were
given')
+'loadTestsFromModule() takes 1 positional argument but 3 were
given')
@warningregistry
def test_loadTestsFromModule__use_load_tests_other_bad_keyword(self):
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16662
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16662] load_tests not invoked in package/__init__.py
Robert Collins added the comment: OH! One more thing I just spotted, which is that this change causes non-'discover' unittest test loading to invoke load_tests. IMO this is the Right Thing - its what I intended when I described the protocol a few years back, but we should document it, no? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
Robert Collins added the comment: Its more than just a docs issue - AFAICT it isn't possible to tell if closefd is set after the object is created. The presence of the parameter in the signature is there, but it isn't documented *where the bulk of the FileIO parameters are* - there are docs for mode for instance. Why would we force users to follow breadcrumbs for one parameter but not other ones? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
Robert Collins added the comment: Oh - the the 'open' function docs are fine - they are just a pointer. I was specifically referring to the class docs around line 513 of Doc/library/io.rst. Attached is a patch that changes repr to show this attribute and extends the docs to document this as part of FileIO. -- keywords: +patch Added file: http://bugs.python.org/file36574/issue17401.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16662] load_tests not invoked in package/__init__.py
Robert Collins added the comment: @michael - ah I think I inverted the sense of the old parameter. It was defaulting True. So - no need to document anything extra:) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
