Hi Ralf, On Wed, Jul 23, 2008 at 14:43 +0200, Ralf Schmitt wrote: > 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.
The "not complaining" part is not essential to me. We'll find a good solution i am sure. After all one could specify "fixed=True", "shouldfail=True" or whatever once the basic machinery is there to satisfy use cases. > > 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. for large projects it could evolve as being really helpful, particularly if you can also specify platforms. > >> 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? yes - but this is not the right thing for packaged or setup.py installs. One may not have write access to the installation path for starters. Or no c-compiler is available on win32 etc. holger -- collaborative expert contracting: http://merlinux.eu PyPy Python/Compiler tool chain: http://codespeak.net/pypy pylib py.test/greenlets/svn APIs: http://pylib.org _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
