[py-dev] Strange failure with py.test - too much magic?

[holger krekel]

On Fri, Jan 28, 2005 at 19:28 +0000, Paul Moore wrote:
> On Fri, 28 Jan 2005 19:28:52 +0100, holger krekel <hpk at trillke.net> wrote:
> > On Fri, Jan 28, 2005 at 18:13 +0000, Paul Moore wrote:
> > > PS Is it possible to use py.test apart from the rest of the py
> > > library? I'm not interested in the XML stuff, or execnet, and while
> > > greenlets sound cool, I don't want to package them up with my testing
> > > framework...
> > 
> > py.test uses itself at least execnet (for distributing tests, running
> > on different python interpreters via --exec=XXX) and the py.path
> > implementations and soon also the 100-line xml-stuff in order to do
> > html-reporting.   So i am afraid there is not much use in
> > trying to separate py.test out.
> 
> Ah. I've got the wrong impression of py.test. Because its principle is
> simplicity of use, I took that as implying a certain simplicity of
> implementation, whereas in actual fact (my apologies if I misrepresent
> things) it is doing some fairly sophisticated things at the
> implementation level, to allow things to "just happen" as the user
> expects.

That is a fair description. Quite arguably the py lib tries to
provide more capabilities than are strictly neccessary for py.test. 

For example, the py.code.Traceback/ExceptionInfo/Code/Frame 
Classes thinly wrap their raw python counterpart objects.  They 
offer somewhat higher level introspection facilities and thus make 
the life of the test reporter (who has to display tracebacks etc.pp)
easier and cleaner.  At the same time, those classes offer e.g. a much 
nicer interface to implement from PyPy which now completely
integrates with py.test and uses it to run tests against the
current PyPy interpreter (without requiring any changes on py.test's 
part of course, including new command line options etc.pp.). 

> It's an entirely fair tradeoff, but probably not what I'm after. Too
> much "magic" for me, I suspect, as well as including a lot of things
> (distributing tests, html reporting) that I don't need/want.

Fair enough.  In some ways the py lib tries to be supplemental 
to the std lib which offers some hundred modules, many of which
both of us probably not use, although they may be used indirectly :-) 

> I don't want to dismiss py on the basis of superficial impressions,
> but at least my *new* superficial impression stands a better chance of
> matching reality than my previous one :-)

Feel free to ask any questions and complain about uglyness :-) 

> I'll go back to playing, and look at things with a more realistic
> view. Thanks for taking the time to explain.

I'd be interested to hear if you can manage to just use py.test 
without having to worry much about the rest of the py lib.    

    holger