[pypy-dev] Re: App-space tests
mwh at python.net
Tue Jun 17 11:52:29 CEST 2003
roccomoretti at netscape.net (Rocco Moretti) writes:
> Michael Hudson <mwh at python.net> wrote:
>>Michael Hudson <mwh at python.net> writes:
>>> roccomoretti at 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
>>> 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.
All programs evolve until they can send email. -- Richard Letts
Except Microsoft Exchange. -- Art
More information about the Pypy-dev