RetroSearch Browse

Thu Feb 17 15:30:06 CET 2005 · https://mail.python.org/pipermail/python-dev/2005-February/051621.html

"Fredrik Lundh" <fredrik at pythonware.com> writes:

> Nick Coghlan wrote:
>
>>> One thing that actually can motivate that test_subprocess takes 20% of the
>>> overall time is that this test is a good generic Python stress test - this
>>> test might catch some other startup race condition, for example.
>>
>> test_decimal has a short version which tests basic functionality and always runs, but 
>> enabling -udecimal also runs the specification tests (which take a fair bit longer).
>>
>> So keeping the basic subprocess tests unconditional, and running the long ones only if -uall 
>> or -usubprocess are given would seem reasonable.
>
> does anyone ever use the -u options when running tests?

Yes, occasionally.  Esp. with test_compiler a testall run is an
overnight job but I try to do it every now and again.

Cheers,
mwh

-- 
  If design space weren't so vast, and the good solutions so small a
  portion of it, programming would be a lot easier.
                                            -- maney, comp.lang.python

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-February/051621.html below:

[ python-Bugs-1124637 ] test_subprocess is far tooslow (fwd)