On Wed, Jul 23, 2008 at 1:34 PM, holger krekel <[EMAIL PROTECTED]> wrote:
> I think it's fine to have the decorator mostly stay forever. > It looks like you want that decorator to attach more information to test functions. In the case where you only want to mark a test as expected failure, I think it should be removed. > I think that py.test should usually always run the > "bug" test but report them specially (no tracebacks) > if they fail and maybe > > .........bb................... > > for the progress bar etc. However, py.test would not > complain if it passes. Then, for example, -0 for not complaining when it passes I don't like that idea, but I also currently don't have the time to argue about it. twisted's trial raises an error for expected failures that succeed. > > py.test --bugs=173,...,... > > would run all tests that are marked with these bug numbers > and turn on full traceback reporting when they fail. > > There are also other things that i'd like to tell > py.test about a test, e.g. having it run "boxed", > i.e. isolated so that it can segfault without > disrupting the testing process. I would have used that a few times in the past..but I can surely live without such a feature. >> Thinking about it I have maybe another issue for 0.9.2. When using >> easy_install >> the greenlets module is not installed correctly. I haven't looked into >> this (python setup.py install works). But I will probably have a look >> at it in the next days.... > > cool. You may just work in release/0.9.x or branch off from there. > The current way of compiling c-extension modules is a hack IIRC ... > mostly because i am a bit clueless on how to this correctly, > particularly for win32. I thought the trick was that it automatically compiles the c modules on demand when it is imported? _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
