roccomoretti@netscape.net (Rocco Moretti) writes:
Michael Hudson <mwh@python.net> wrote:
Michael Hudson <mwh@python.net> writes:
roccomoretti@netscape.net (Rocco Moretti) writes:
Before I realized that metaclasses were involved, I first thought of using a special subclass of TestCase - probably by overloading TestCase.__call__() to appropriately wrap the function before it is run.
Yes, that would probably work.
And it does, after a fashion. Well, it works fine as far as I can tell, it's just that running the assertFoo methods in app-space *too* (what the attached does) isn't ideal. OTOH, the fact that doing so *works* is something we can be proud of.
Glad to hear it works!
Re: running method in appspace - I hoped that was something that was "fixed" with the addition of the PyByteCode Object. I'm assuming (as I wasn't at the sprint and haven't heard about it otherwise) that a regular bytecode object gets run on the CPython interpreter, and a PyByteCode object gets run on the PyPy interpreter.
Ah, no. All functions are somewhat wrapped -- even in the trivial object space. app level functions have a (interpreter-level) func_code attribute of type PyByteCode; interpreter level functions have a func_code attribute of type PyBuiltinCode. It's the func.func_code.eval_code method that determines how a function is executed. This means that PyPy's "builtin functions" are much more introspectable than CPython's builtins -- they have meaningful func_code.co_argcount & func_code.co_varnames parameters, for instance. We think this is a good thing. I think I've improved the state of builtin function support to allow running the assertFoo methods as builtins now, so it's a question of preference now (although my implementation of varargs & so on for builtin functions may be excessively clever & should probably be run past someone else...).
Although that's what I assume, I haven't been able to confirm this in the code, as I loose track of the control flow after calling ObjSpace.call(). (I started tracking from the CALL_FUNCTION opcode in opcode.py)
I recommend reading interpreter/pycode.py, interpreter/extmodule.py and objspace/trivial.py:newfunction() to get an idea of how this works. Mmm, this should probably be documented somewhere... but it's not that hard once you get the idea, IMHO.
The only decision to be made is: do we distinguish between app-space tests by a naming convention (as attached: any test starting test_app_ runs in app space) or by inheriting from a different TestCase subclass? I can't make my mind up which I prefer.
I'd vote for seperate TestCases.
OK, I was leaning that way too.
App space should be suitably separated from interpreter level such that we avoid confusion. This also allows setup () and teardown() methods to work semi-sanely. It will also give a consistent interface to the assert*() methods (whether they are being called from interpreter level or app. level.)
I think the last comment is a bit of a red herring -- you can't present unittest_w.TestCase_w.assertEquals_w as a builtin method directly because it doesn't expect a wrapped 'msg' argument (and similarly for most of the others).
In either case, I want to check something like this in, soon. The implementation can be made more elegant/faster in due course.
I'm +1 on checkin - as you say, it doesn't break anything, and we can always improve it later.
I'll tweak my code to do the "separate subclasses" thing & check something in later. Cheers, M. -- All programs evolve until they can send email. -- Richard Letts Except Microsoft Exchange. -- Art -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html