[pypy-dev] Re: App-space tests

[Michael Hudson]

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
>>>> 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