RetroSearch Browse

Sun Jan 8 15:36:42 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-January/059500.html

Neal Norwitz wrote:
> [moving to python-dev]
> 
>> On 1/7/06, Reinhold Birkenfeld <reinhold-birkenfeld-nospam at wolke7.net> wrote:
>> > Well, it is not the test that's broken... it's compiler.
> 
> [In reference to:
> http://mail.python.org/pipermail/python-checkins/2006-January/048715.html]
> 
> In the past, we haven't checked in tests which are known to be broken.

Okay. I apologize. I originally intended to fix it, but I found that I don't have
the time to search the bug.

>  There are several good reasons for this.  I would prefer you, 1) also
> fix the code so the test doesn't fail, 2) revert the change (there's
> still a bug report open, right?), or 3) generalize tests for known
> bugs.
> 
> I strongly prefer #1, but have been thinking about adding #3.  There
> are many open bug reports that fall into two broad categories: 
> incorrect behaviour and crashers.  I've been thinking about adding two
> tests which incorporate these bugs as a way of consolidating where the
> known problems are.  Also, it's great when we have test cases that can
> be moved to the proper place once the fix has been checked in.
> 
> I'm proposing something like add two files to Lib/test:
> outstanding_bugs.py and outstanding_crashes.py.  Both would be normal
> test files with info about the bug report and the code that causes
> problems.
> 
> This test in test_compiler should be moved to outstanding_bugs.py.

I added outstanding_bugs.py and this initial test.

regards,
Georg

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

Showing content from https://mail.python.org/pipermail/python-dev/2006-January/059500.html below:

[Python-Dev] Checking in a broken test was: Re: [Python-checkins] r41940