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

[Ian Bicking]

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.

> Personally, btw, i find the assert statement <-> self.assertEquals 
> difference one of the primary points for using py.test.  But reading your
> blog entry reminded me that we should probably focus a bit more on getting
> the current features more solid (especially tracebacks). 
> However, integrating doctests is still high on the list ... hum, 
> didn't I say that already lately? :-) 
> 
> 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.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org