[py-dev] we are about to get press:

[holger krekel]

On Fri, Jan 28, 2005 at 17:38 -0600, Ian Bicking wrote:
> holger krekel wrote:
> >I just read through your blog entry and enjoyed it. All of it, especially
> >the criticism seems pretty sensible.  Of course, it motiviates me to 
> >finally get rid of remaining ugly tracebacks. I'd actually like to 
> >do it by really improving the collection logic ... 
> 
> I don't know if this is related, but I was thinking recently about 
> tracebacks in other contexts.  The Zope exception reporter looks for 
> __traceback_info__ local variables in the frames and uses them to add 
> extra information... I thought it might be possible to use another local 
> variable like that to signal that a frame (or maybe all further frames 
> from where the variable was found) should be left out of the traceback. 
>  It seems like a simple way to handle the problem of long tracebacks.

Hehe, actually there is already support for that with py.test in 
that you can say 

    __tracebackhide__ = True 

in a function (and modify that value during the execution 
of a function) and a py.test-traceback will leave out that traceback. 
You can also modify this value during the run of the function, 
of course.  This is nice for proxy or decorating functions
that want to hide themselves when they  dispatch to their underlying
object. In a custom import hook, for example, you can set 
__tracebackhide__ initially to False and when you dispatch 
to cpython's __import__ you set it to True because showing
your hook becomes unteresting. 

It may be worthwhile to extend this idea to be able to have 
more general interactions at traceback-show time. With something
like: 

    __traceback__ = """ 
            def repr(frame): 
                # text representation for this frame 
    """ 

This would only add a minimal runtime penalty and the speed
at traceback-showtime (when we need to compile the above)
is irrelevant. This would allow for rather custom tracebacks. 

> >Btw, another interesting development may be that we spent some time 
> >at the Switzerland PyPy sprint to run CPython's unittest-using 
> >regression tests to work _unmodified_ from invoking them with 
> >py.test.  It's easier than i thought but i am not sure that 
> >i want to offer this "officially" from py.test. Maybe i put
> >it into the py/documentation/example directory to show off
> >what you can do from "conftest.py" files. 
> 
> You mean, py.test can automatically find and run unittest-based tests? 
> That would be great, certainly not something to hide away -- it makes it 
> more viable to adopt py.test incrementally, or as a developer to use it 
> in projects that already use unittest (and where you might not have the 
> authority to change that).  Tests written for py.test are still 
> compelling because they are simple -- making it unittest-compatible just 
> means there's less initial investment required to start using py.test.

Yes, i agree.  But I am afraid that there may be more and more demand
to support more and more of unittest's uglynesses :-) 

cheers, 

    holger