[issue19359] reversed() does not work with weakref.proxy of sequences
New submission from Austin Bingham: When passed a weakref.proxy to a legitimate sequence, reversed() throws a TypeError complaining that its argument isn't a sequence. Perhaps this is the expected behavior, but it's surprising to at least me and the few others I've spoken with about it. -- components: Library (Lib) files: reversed_proxy_failure.py messages: 201002 nosy: abingham priority: normal severity: normal status: open title: reversed() does not work with weakref.proxy of sequences type: behavior versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file32309/reversed_proxy_failure.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13807] logging.Handler.handlerError() may raise AttributeError in traceback.print_exception()
Changes by Austin Bingham austin.bing...@gmail.com: -- nosy: +abingham ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12600] Support parameterized TestCases in unittest
Austin Bingham austin.bing...@gmail.com added the comment: Yes, in some sense that's what I'm thinking of. But one problem with this straightforward approach is that it doesn't scale well. If I've got many TestCases, each if which I want to parameterize, I have to create subclasses for each parameterization. If I add a new parameterization, of course I have to add new subclasses for each. Even worse, if my parameterizations are dynamically generated (e.g. if my parameterizations are based on installed plugins or something), then this naive approach just breaks down. There are, as has been mentioned, various ways to implement quite sophisticated parameterized test cases purely by subclassing the existing loaders, runner, and TestCase functionality. On the other hand (and recognizing that I may well be missing something), it's not particularly straightforward to do so, and it feels like a bit more of a hack than I would like. There are a lot of moving parts in unittest, and when I have to start fiddling with one to get special new behavior I always worry that I might subtly break something else...but maybe I'm just being neurotic ;) So, I'll put forward two arguments for official support for parameterized test cases. The first is what I mentioned above: implementing it extrinsic to the existing system seems non-obvious and complex, and thus error prone. Putting official support in unittest would mean nobody else ever had to worry about it. On the other hand, assuming that parameterized test cases can be fully and cleanly implemented without touching unittest, this also argues that someone should just create an external package to do so, and leave unittest alone. The second argument is symmetry. If you implement parameterization of individual tests, it seems like the logic for justifying them really could be generalized for collections of tests, both cases and suites. I admit that this is just a gut feeling, but there you go. Ultimately, I'm less concerned that any changes are made to unittest than I am that the issue is given due consideration. Heck, a proper fix might be to just add a section to the docs describing how one might implement parameterized testcases. On Sat, Jul 23, 2011 at 12:04 AM, Terry J. Reedy rep...@bugs.python.org wrote: Terry J. Reedy tjre...@udel.edu added the comment: David, is this the sort of thing you mean? @skip # so do not run without backend class AbstractDB2Testcase: backend = None code class PostgressDB2Testcase(AbstractDB2Testcase): backend = postgress # well, enough info to fine it ... If so, I think we should close this. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12600 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12600 ___ ___ 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
Austin Bingham austin.bing...@gmail.com added the comment: Has a decision been made to implement some form of parametric tests? Is working being done? Along with parameterizing individual test methods, I'd also like to throw out a request for parametric TestCases. In some cases I find that I want the behavior of setUp() or tearDown() to vary based on some set of parameters, but the individual tests are not parametric per se. -- nosy: +abingham ___ 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
[issue12600] Support parameterized TestCases in unittest
New submission from Austin Bingham austin.bing...@gmail.com: In the discussion about adding support for parameterized tests (issue 7897), it seemed clear that parameterizing individual tests was a different issue from parameterizing TestCases. This, then, is a request to support parameterization of TestCases. The fundamental idea is that one should be able to define a TestCase - fixtures, individual tests, etc. - and then be able to reuse that TestCase with different sets of parameters. This should all mesh cleanly with the rest of the unittest system, though it's not entirely clear what that entails. As a motivation, consider a TestCase that tests the public API for a database abstraction system. The abstraction may work against any of a number of backends, but the public API remains the same for each. A parameterized TestCase would let you write one test for the public API and then run it for each of the backends. -- components: Tests messages: 140784 nosy: abingham priority: normal severity: normal status: open title: Support parameterized TestCases in unittest type: feature request versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12600 ___ ___ 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
Austin Bingham austin.bing...@gmail.com added the comment: OK, I created issue 12600 for dealing with parameterized TestCases as opposed to individual tests. On Wed, Jul 20, 2011 at 4:03 PM, R. David Murray rep...@bugs.python.org wrote: Unless someone sees a clever way to implement both with the same mechanism, parameterizing test cases should probably be a separate issue. Doing it via subclassing is straightforward, which also argues for a separate issue, since an 'is this worth it' discussion should be done separately for that feature. -- ___ 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
[issue10805] traceback.print_exception throws AttributeError when exception is None
New submission from Austin Bingham austin.bing...@gmail.com: traceback.print_exception() will throw an AttributeException if `value` is None and `chain` is True. This is because `_iter_chain` assumes that the exception object has a `__cause__` attribute. You can trigger this by trying for format a non-existent exception: import logging, sys logging.Formatter().formatException(sys.exc_info()) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.1/logging/__init__.py, line 418, in formatException traceback.print_exception(ei[0], ei[1], ei[2], None, sio) File /usr/lib/python3.1/traceback.py, line 155, in print_exception for value, tb in values: File /usr/lib/python3.1/traceback.py, line 122, in _iter_chain cause = exc.__cause__ This is assuming that sys.exc_info() returns (None, None, None). -- components: Library (Lib) messages: 125054 nosy: abingham priority: normal severity: normal status: open title: traceback.print_exception throws AttributeError when exception is None type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10805 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
