[issue16997] subtests
holger krekel added the comment: On Sun, Feb 10, 2013 at 12:41 PM, Antoine Pitrou rep...@bugs.python.orgwrote: Antoine Pitrou added the comment: Please don't commit I think we still need a discussion as to whether subtests or paramaterized tests are a better approach. I certainly don't think we need both and there are a lot of people asking for parameterized tests. I think they don't cater to the same crowd. I see parameterized tests as primarily used by people who like adding formal complexity to their tests in the name of architectural elegance (decorators, non-intuitive constructs and other additional boilerplate). Subtests are meant to not get in the way. IMHO, this makes them more suitable for stdlib inclusion, while the testing-in-python people can still rely on their additional frameworks. Parametrized testing wasn't introduced because I or others like formal complexity. I invented the yield syntax that both pytest and nose still support and it was enhanced for several years until it was deemed not fit for a general purpose testing approach. More specifically, if you have functional parametrized tests, they each run relatively slow. People often want to re-run a single failing test or otherwise select tests which use a certain fixture, or send tests to different CPUs to speed up execution. That's all not possible with subtests or am i missing something? That being said, I have plans to support some form of subtests for pytest as well, as there are indeed cases where a more lightweight approach fits well, especially for unit- or integration tests where one doesn't care if a group of tests need to be re-run when working on fixing a failure to a single subtest. And where it's usually more about reporting, getting nice debuggable output on failures. I suspect the cases which Antoine refers satisfy this pattern. best, holger -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16997 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16997] subtests
holger krekel added the comment: On Sun, Feb 10, 2013 at 12:43 PM, Nick Coghlan rep...@bugs.python.orgwrote: Nick Coghlan added the comment: You can use subtests to build parameterized tests, you can't use parameterized tests to build subtests. I doubt you can implement parametrized tests via subtests especially for functional testing and its fixture needs. The standard library can also be converted to using subtests *far* more readily than it could be converted to parameterized tests. I can see that and for this reason and the stdlib's use cases it might make sense to support it. The unittest module is also used in many other contexts so it shouldn't be the only verification criterium. best, holger -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16997 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Changes by holger krekel holger.kre...@gmail.com: -- nosy: +hpk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13490] broken downloads counting on pypi.python.org
New submission from holger krekel holger.kre...@gmail.com: Seems like pypi.python.org does not properly maintain download counters anymore, at least for a few packages i looked at like pytest,execnet,tox,nose. -- components: None messages: 148447 nosy: hpk priority: normal severity: normal status: open title: broken downloads counting on pypi.python.org type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
holger krekel holger.kre...@gmail.com added the comment: Michael, if you have it i'd like to see the original post/concrete use case. thanks, holger -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Changes by holger krekel holger.kre...@gmail.com: -- nosy: +hpk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
holger krekel holger.kre...@gmail.com added the comment: FWIW i tend to agree and would probably prefer setup/teardown to result in an error rather than be subsumed in an expected-to-fail marked test. I guess if one regards setup/teardown as a place to implement pre/post-conditions than the changes suggested by Michael make more sense. I'd like to see a more real use case / user than the abstract case provided here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
holger krekel holger.kre...@gmail.com added the comment: Seems the inspect.getsourcefile regression now is in the RC1 of Python2.7 as well. I suggest to apply the getsourcefile.patch patch which was attached from David. I tested it and it works fine for Python2.7 and Python3.1. -- status: open - pending versions: +Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
holger krekel holger.kre...@gmail.com added the comment: David, your getsourcefile.patch looks fine (and better than mine) to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
holger krekel holger.kre...@gmail.com added the comment: Well, maybe we could introduce a linecache.setlines function to give the linecache module control over its internal caching and data handling. What do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8782] inspect.getsource returns invalid source for non-newline-ending module
New submission from holger krekel holger.kre...@gmail.com: Executing the attached inspect_failure.py under python2.6 or python3.1 results in an assertion error: Python fails to obtain the source code of a function that is defined at the end of a module whose last line does not contain a line ending character. After brief analysis i think there are two approaches to fixing it: normalizing newlines in inspect.findsource (see attached inspect.patch file against r312) or performing normalization in linecache.updatecache which does it already for source code obtained from PEP302 loaders. Or any other ideas? -- files: inspect.patch keywords: patch messages: 106245 nosy: hpk priority: normal severity: normal status: open title: inspect.getsource returns invalid source for non-newline-ending module type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file17431/inspect.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
holger krekel holger.kre...@gmail.com added the comment: Thanks for helping with this! Attached is a patch that adds a keyword check=True to getsourcefile so that findsource can defer existence-checking until after cache lookup. Eventually, findsource will still raise an IOError if it can't find the source file and cannot recover the source from cache. The patch mainly consists of adding a number of tests to specify the (refined) behaviour of findsource and getsourcefile. best, holger -- keywords: +patch Added file: http://bugs.python.org/file17350/findsource.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
New submission from holger krekel holger.kre...@gmail.com: Somewhere between python 3.0.1 and 3.1.2 the behaviour of inspect.findsource changed: it does not find the source code anymore for a code object whose filename/source is in the linecache.cache because instead of the previous:: file = getsourcefile(object) or getfile(object) it only does now:: file = getsourcefile(object) IMO it is enough if findsource() raises if it can't eventually discover the source code - i don't see the need to do this ahead. In any case, the r312 findsource version requires an ugly work around within py.test in order for it to continue to be able to use the inspect module with dynamically compiled code. The underlying issue is that at code-compile time no sensible (PEP302 compliantly loaded) module can be constructed because this is only known at exec-time but this is not part of the test tool API and is done somewhere in user code. Proposed fix: revert to r301 behaviour and add back or getfile(object) to the first line of inspect.findsource() -- components: Library (Lib) messages: 105776 nosy: benjamin.peterson, hpk priority: normal severity: normal status: open title: undo findsource regression/change type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8547] unittest test discovery can fail when package under test is also installed globally
holger krekel holger.kre...@gmail.com added the comment: FWIW checking if an imported module really comes from a certain location and erroring out is also how py.test does it. -- nosy: +hpk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8547 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8564] Update documentation on doctest/unittest2 integration
Changes by holger krekel holger.kre...@gmail.com: -- nosy: +hpk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8558] StringIO().truncate causes zero-bytes in getvalue()
New submission from holger krekel holger.kre...@gmail.com: Running the attached file with python3.1.1 works fine, all assertions pass. Running it with 3.1.2 gives me this output: $ python3.1.2/bin/python3.1 stringio_fail.py Traceback (most recent call last): File stringio_fail.py, line 12, in module assert s == world, repr(s) AssertionError: '\x00\x00\x00\x00\x00world' -- components: IO files: stringio_fail.py messages: 104423 nosy: hpk priority: normal severity: normal status: open title: StringIO().truncate causes zero-bytes in getvalue() type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file17116/stringio_fail.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8558 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8558] StringIO().truncate causes zero-bytes in getvalue()
holger krekel holger.kre...@gmail.com added the comment: Ah, thanks for the pointer. So indeed, for me truncate(0)+seek(0) works fine for all interpreters i care for (python2.4 - 3.1.X), previously truncate(0) was enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8558 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6333] logging: ValueError: I/O operation on closed file
holger krekel holger.kre...@gmail.com added the comment: Actually py.test catches stdout separately for setup and for the test code. Moreover, functional or integration test code (py.test is not only for unittests) can easily trigger some implicit logging-module usage which cannot eaysily be factored into a testcase-setup method, i am afraid. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6333 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6333] logging: ValueError: I/O operation on closed file
holger krekel holger.kre...@gmail.com added the comment: I think the issue is unrelated to py.test - it just presents a use case as it wants to run 1000's of tests and capture stdout/stderr per each test function, cannot guess about a test's logging-usage yet wants to minimize memory/resource usage and close any temporary files it opens. Anyway, a standalone minimal example involving the issue is this: import logging import StringIO stream = StringIO.StringIO() logging.basicConfig(stream=stream) stream.close() # to free memory/release resources At exit logging's shutdown() will try to flush/close resulting in an exception. Is it a problem to have the logging module be a bit more defensive and only try a flush/close if the stream isn't already closed? -- nosy: +hpk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6333 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6333] logging: ValueError: I/O operation on closed file
holger krekel holger.kre...@gmail.com added the comment: To recap the use case: stdout is redirected during a test function run which might trigger arbitrary usage of logging-functionality. Not closing the temporary file would mean that there could be as many open files as there are test functions - or one needs to rely on garbage collection for closing the resource - this is generally considered bad practise. So I consider it best practise to do resource cleanup immediately and close the temp file. Note that the test tool *does not touch the logging module at all*, and it has no way to mandate the usage of the logging module like you suggest. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6333 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
