RE: [pypy-dev] Re: Objects and types in the stdobjspace
Michael Hudson <mwh@python.net> wrote:
roccomoretti@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?
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.)
(although working closely with it for the first time has made its Java heritage unpleasantly clear...).
How so?
We also need a LOT more tests!
Like what? (Knowing what to test is 73.495% of the battle [+- 50%])
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)
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.) -Rocco __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
roccomoretti@netscape.net (Rocco Moretti) writes:
Michael Hudson <mwh@python.net> wrote:
roccomoretti@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
Michael Hudson <mwh@python.net> writes:
roccomoretti@netscape.net (Rocco Moretti) writes:
Michael Hudson <mwh@python.net> wrote:
roccomoretti@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.
I've had another idea: give unittest_w.TestCase_w a metaclass that looks for methods called 'test_app_whatever' and arrange for such methods to be called as objectspace methods. So, e.g. def test_trivial(self): x = self.codetest(''' def g(): return 42''', 'g', []) self.assertEquals(x, 42) becomes: def test_app_trivial(self): def g(): return 42 self.assertEquals(g(), 42) I have an implementation of this (attached), but it was significantly more of a pain than I would have liked (mostly because 2.2's unittest doesn't cope with TestCase classes being new-style...). It also only works in the standard object space, and only really works there by fluke (it's the self.assertEquals business that casues the problems -- can probably try harder and come up with a better solution). Cheers, M. -- And then the character-only displays went away (leading to increasingly silly graphical effects and finally to ads on web pages). -- John W. Baxter, comp.lang.python
participants (2)
-
Michael Hudson -
roccomoretti＠netscape.net