[py-dev] py.test bug: large stack trace produced with fullsource dump on import failure

[Baptiste Lepilleur]

----- Original Message ----- 
From: "holger krekel" <holger at merlinux.de>
To: "Baptiste Lepilleur" <blep at users.sourceforge.net>
Cc: <py-dev at codespeak.net>
Sent: Thursday, July 03, 2008 12:02 PM
Subject: Re: [py-dev] py.test bug: large stack trace produced with 
fullsource dump on import failure


> Hi Baptiste,
>
> On Fri, Jun 27, 2008 at 10:45 +0200, Baptiste Lepilleur wrote:
>> I have run into an issue with py.test which make it pretty much unsable 
>> with
>> the following scenario:
>> - a test module import another module
>> - the import fails due to an exception thrown by the other module
>>
>> This scenario raise two bugs (hopefully this is the scenario to reproduce
>> this bug):
>> - Py.test produces a stack trace with a full source dump of the imported
>> module source
>> - Information about the exception that caused the failure is missing.
>>
>> The source does not end line 2269, so my guess is that py.test dump the
>> source until the source line where the exception was raised.
>
> exactly.
>
>> I believe py.test should truncate the source to show only the relevant 
>> part,
>> that is ignore the 2000 lines until the global variable declaration
>> SCHEMA_SCHEMA in this case.
>
> Hum, in other cases it might be interesting to see the context, though.
> E.g. if you have a couple of global statements where the
> failing one depends on values produced by earlier ones.
>
I did not know this feature was present, though I've never seen it 
triggering. Does it works with module level global variable ?

> I am not sure what the exact rule should be for such contexts
> but your example showcases that we should try to improve,
> indeed.

My rules of the thumb would be something like:
If the trace at a given level of the stack is longer than two screen in 
height, then truncates it and show only the relevant part. Otherwise, the 
developper will likely spent more time analysing the trace than fixing the 
test.
How frequent is the use case you quote above ? I never stumbled on such a 
case, though I don't write that much python code...

>
> thanks & best,
>
> holger
---
Baptiste Lepilleur <blep at users.sourceforge.net>