[pypy-dev] Re: Objects and types in the stdobjspace

[Michael Hudson]

roccomoretti at netscape.net (Rocco Moretti) writes:

> Michael Hudson <mwh at python.net> wrote:
>
>>roccomoretti at netscape.net (Rocco Moretti) writes:
>
>>> Secondly, the testing framework as written will only run tests at the
>>> interpreter level. Some tests (such as test_exceptcomp and test_exec)
>>> should be run at the application level.
>>
>>Yes.  I don't see how to easily and gracefully allow this.
>
> Naming convention? test_excptcomp_app.py and test_exec_app.py for example?

Could do.  But what would such a file look like?  I don't think pypy
can import unittest yet, and I doubt that's something we really want
to do.

>>Hmm, maybe.  regrtest has become somewhat crufty over the years, I
>>don't think we need all of it.  In a way, I'd prefer to keep things
>>within the unittest framework if possible 
>
> regrtest has provisions for working with unittest files, and if we want to 
> work with the CPython regression tests, we need to deal with regrtest in 
> some fashion anyway. (But I agree - regrtest is intimidating to work with.)

True.

>>(although working closely
>>with it for the first time has made its Java heritage unpleasantly
>>clear...).
>
> How so?

Using classes where a function would have done, basically.  I don't
know -- I don't know Java at all well -- but it just seems a bit
over-OOP-y.

>>We also need a LOT more tests!
>
> Like what? (Knowing what to test is 73.495% of the battle [+- 50%])

Think of something.  We probably don't test it <wink>.

Tests of app-defined classes seem to be particularly absent.

>>> And in keeping with my rearranging mood, I think main.py should
>>> probably be placed in the pypy/ directory.
>>
>>Hmm.  Maybe, or maybe the executable that people actually run will
>>look like this:
>>
>>#!/usr/bin/python
>>from pypy.interpreter import main
>>main.main()
>
> I think: 
>
> #!/usr/bin/python
> from pypy import main
> main.main()
>
> is a bit cleaner, especially if we start to expand into the realm of 
> multiple BytecodeSpaces/ExecutionSpaces (i.e. if interpreter becomes 
> std_interpreter)

I say it's a wash.  But if you want to change it, please go right
ahead...

>>Thanks, I think we really moved things forward.  Are you able to come
>>to the next sprint?
>
> Unfortunately no, I'm not able to travel at this time. (Too busy.)

Shame!

Cheers,
M.

-- 
  In short, just business as usual in the wacky world of floating
  point <wink>.                        -- Tim Peters, comp.lang.python