On 04/03/2011 01:33, anatoly techtonik wrote:
On Thu, Mar 3, 2011 at 11:58 PM, Michael Foord
wrote:
Without this option interrupting a test run with a ctrl-c kills the run
and
reports nothing. Seeing an unexpected failure or error during a long test
run and having to wait to the end of the tes
On Thu, Mar 3, 2011 at 11:58 PM, Michael Foord
wrote:
>>>
>>> Without this option interrupting a test run with a ctrl-c kills the run
>>> and
>>> reports nothing. Seeing an unexpected failure or error during a long test
>>> run and having to wait to the end of the test run to see the traceback
>>>
On 03/03/2011 21:54, anatoly techtonik wrote:
On Thu, Mar 3, 2011 at 10:44 PM, Michael Foord
wrote:
On 03/03/2011 20:31, anatoly techtonik wrote:
I am looking at --help of test runner and asking the question: what is
the use case for -c, --catch option?
It catches keyboard interrupt and inst
On Thu, Mar 3, 2011 at 10:44 PM, Michael Foord
wrote:
> On 03/03/2011 20:31, anatoly techtonik wrote:
>>
>> I am looking at --help of test runner and asking the question: what is
>> the use case for -c, --catch option?
>
> It catches keyboard interrupt and instead of just bombing out of the test
>
On 03/03/2011 20:31, anatoly techtonik wrote:
I am looking at --help of test runner and asking the question: what is
the use case for -c, --catch option?
It catches keyboard interrupt and instead of just bombing out of the
test run it reports all the results collected so far.
Without this opti
I am looking at --help of test runner and asking the question: what is
the use case for -c, --catch option? It doesn't look like it should be
present in generic runner. I also can't find reasons to waste short
option for it. There will be big problems with people complaining
about BC break even if
