[py-dev] truncate too long tracebacks

[holger krekel]

Hi Baptiste, 

yes, it probably makes sense to truncate traceback output to
some 40 lines or so, at least for statements that have no
indentation.  (i CC the issue tracker and try to 
create an issue out of our mail conversation, might go wrong) 

holger

On Sat, Jul 05, 2008 at 09:32 +0200, Baptiste Lepilleur wrote:

> ----- 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>
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
collaborative expert contracting: http://merlinux.eu 
pylib py.test/greenlets/svn APIs: http://pylib.org 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy