RE: [pypy-dev] Pypy frontend/ testall.py
"logistix" <vze55z8s@verizon.net> wrote:
Great! I wanted something like this over the weekend. (Have you been borrowing Guido's time machine?)
N.B. If you look at the implementation of testall.py (at least for 2.2.2) it's just a hack which fiddles with sys.argv and then calls into test.regrtest (I mention this because regrtest.py has different output formating features which look much nicer than the verbose output of testall.py.
It should be noted that testall.py fails quite spectacularly, as can be expected at this point, and aborts execution.
That's interesting - Which platform and ObjSpace were you using? When I tried this weekend with TrivialObjSpace under Python 2.2.2 on Win98 the results were encouraging - most of the tests passed (eventually). One MAJOR caveat on that issue is that I had to edit regrtest.py to get it to work. Out of the box all the tests failed miserably with "Module Not Found Errors". regrtest.py assumes that tests are in test_???.py files in the current package level (Lib/test, but the level is implicit). However, when the pypy interpreter runs an import, the import runs local in the Lib/pypy/interpreter package - no test_??? files are found. Additionally, when testing, an "import test" opens the "test" submodule of Lib/pypy/interpreter. If you delete/rename the test directory, and edit regrtest.py such that it does an absolute import: Change: the_module = __import__(test, globals(), locals(), []) to: the_module = __import__("test", globals(), locals(), [test]) then testall/regrtest is happy. (No, I don't think this is a long-term solution to the problem ...) -Rocco __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
I'm running 2.2.2 on XP. I've attached the fatal traceback to the end of this message if you're interested. There were also some less catastrophic failures in the various tests.
I originally had that problem too. I'm running this script outside of the whole pythonpath in a directory called pypy that has all of the pypy source. You'll see some bad voodoo that manually adds the path back in. This lets you execute any script anywhere with "C:\pypy\pypython.py script.py". I just noticed that this only works when you run "pypython.py", and not "python pypython.py". I guess I'll have to hack in something from argv[0] for the latter case? TRACEBACK (for what it's worth) =============================== C:\Python22\Lib\test>c:\pypy\pypython.py testall.py > c:\dummy.txt C:\Python22\Lib\test\test_b1.py:329: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4 and up if len(hex(-1)) != len(hex(sys.maxint)): raise TestFailed, 'len(hex(-1))' C:\Python22\Lib\test\test_b1.py:330: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4 and up if hex(-16) not in ('0xfffffff0', '0xfffffffffffffff0'): C:\Python23\lib\pre.py:94: DeprecationWarning: Please use the 're' module, not t he 'pre' module DeprecationWarning) C:\Python23\lib\Cookie.py:687: DeprecationWarning: SerialCookie class is insecur e; do not use it DeprecationWarning) C:\Python23\lib\Cookie.py:712: DeprecationWarning: Cookie/SmartCookie class is i nsecure; do not use it DeprecationWarning) Traceback (most recent call last): File "c:\pypy\pypython.py", line 57, in ? x.execFile(sys.argv[1]) File "c:\pypy\pypython.py", line 46, in execFile self.execString(f.read()) File "c:\pypy\pypython.py", line 42, in execString self.ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 206, in ca ll return apply(callable, args, kwds) File "c:\python23\lib\profile.py", line 214, in trace_dispatch_i if self.dispatch[event](self, frame,t): File "c:\python23\lib\profile.py", line 280, in trace_dispatch_return assert frame is self.cur[-2].f_back, ("Bad return", self.cur[-3]) AssertionError: ('Bad return', ('profile', 0, 'testfunc()')) C:\Python22\Lib\test>
Hello, On Mon, Mar 03, 2003 at 09:17:25PM -0500, Rocco Moretti wrote:
Additionally, when testing, an "import test" opens the "test" submodule of Lib/pypy/interpreter.
Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory? We will keep running again and again into this problem. Either none of our test/ subdirectory is a package, or we rename them all (e.g. to testing/) to avoid this confusion. Armin
Armin Rigo <arigo@tunes.org> writes:
? Shouldn't do, if $PYTHONPATH is pointing at the directory containing the pypy directory.
Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory?
Because I wanted to import something from there at some point.
We will keep running again and again into this problem.
Why?
Either none of our test/ subdirectory is a package,
Bad idea, IMO.
or we rename them all (e.g. to testing/) to avoid this confusion.
Better, but should be unecessary. Cheers, M. -- MGM will not get your whites whiter or your colors brighter. It will, however, sit there and look spiffy while sucking down a major honking wad of RAM. -- http://www.xiph.org/mgm/
Hello Michael, On Mon, Mar 10, 2003 at 11:42:47AM +0000, Michael Hudson wrote:
It does, if the current directory is pypy/interpreter (for example when you run python 'interactive.py').
Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory? Because I wanted to import something from there at some point.
Ok, but then:
We will keep running again and again into this problem. Why?
Because then you have no way to import the standard library 'test' package if you current directory happens to contain a local 'test' package -- which will eventually mean almost any PyPy directory. I had the same problems over and over again with Psyco, which had a 'test.py', until I finally decided to rename it to 'test1.py'. I my humble opinion it might have been a bad idea to give a Python standard library package a name as common as 'test', but well, not everybody is supposed to import it in everyday applications. Armin
Armin Rigo <arigo@tunes.org> writes:
So don't do that, run $ PYTHONPATH=. python pypy/interperter/interactive.py then. I can see this being tedious, though. interactive.py could remove the cwd from sys.path, but that also might be surprising.
I actually realised this bit :-) It's just that if you set up your paths the Right Way(tm) you shouldn't bump into this. Perhaps we should do a mass test -> pypytest (or something) renaming, for simplicity. Cheers, M. (relative imports are evil, have I mentioned this lately?) -- I would hereby duly point you at the website for the current pedal powered submarine world underwater speed record, except I've lost the URL. -- Callas, cam.misc
At 13:04 2003-03-10 +0000, Michael Hudson wrote:
I wonder if some kind of aliasing mechanism could solve this kind of problem. E.g., if about to raise an exception for non-existent file/directory, first check for a match to some rewrite patterns in an alias file. They could be simple prefix replacements for paths or more complex regex subs. Then, after rewriting, try the modified path, and only after that fails raise the exception. This would allow creation of platform-independent sys.path name prefixes like, e.g., r"/$$py_lib" and generating, e.g., r"D:\python22\lib" or the unix equivalent as the modified path prefix actually used. All python system files could thus exist under a tree of platform- independent alias prefixes, and pypy could define some for special purposes. There could even be a mechanism for pushing/popping a temporary prefix definition override. Appropriate naming conventions should avoid problems. (I have previously posted about virtualizing part of the file/directory namespace accessed via python's open/file built-ins, and gotten objections that this would not appear to i/o done via the os module or user-written extension modules. I didn't pursue it further, but I still think something platform-independent could be useful.) my .02USD Regards, Bengt Richter (Back from 2 wks on a sunny beach ;-)
Hello Bengt, On Thu, Mar 13, 2003 at 07:04:33PM -0800, Bengt Richter wrote:
I wonder if some kind of aliasing mechanism could solve this kind of problem.
In some point of view we had the opposite problem: importing 'test' finds too many 'test' packages and imports the wrong one.
I think this is interesting, and I need it for the "unit" thing: a platform-independent way to point to a file that can be either 'local', i.e. relative to the directory of the file containing the pointer, or absolute within Python's standard library. Right now I am simply saying that a posix-style name containing at least a '/' is local, and otherwise it is a (possibly dotted) module name from the standard library. Maybe a more general virtual file namespace could be an interesting thing to have. A bientôt, Armin.
I'm running 2.2.2 on XP. I've attached the fatal traceback to the end of this message if you're interested. There were also some less catastrophic failures in the various tests.
I originally had that problem too. I'm running this script outside of the whole pythonpath in a directory called pypy that has all of the pypy source. You'll see some bad voodoo that manually adds the path back in. This lets you execute any script anywhere with "C:\pypy\pypython.py script.py". I just noticed that this only works when you run "pypython.py", and not "python pypython.py". I guess I'll have to hack in something from argv[0] for the latter case? TRACEBACK (for what it's worth) =============================== C:\Python22\Lib\test>c:\pypy\pypython.py testall.py > c:\dummy.txt C:\Python22\Lib\test\test_b1.py:329: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4 and up if len(hex(-1)) != len(hex(sys.maxint)): raise TestFailed, 'len(hex(-1))' C:\Python22\Lib\test\test_b1.py:330: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4 and up if hex(-16) not in ('0xfffffff0', '0xfffffffffffffff0'): C:\Python23\lib\pre.py:94: DeprecationWarning: Please use the 're' module, not t he 'pre' module DeprecationWarning) C:\Python23\lib\Cookie.py:687: DeprecationWarning: SerialCookie class is insecur e; do not use it DeprecationWarning) C:\Python23\lib\Cookie.py:712: DeprecationWarning: Cookie/SmartCookie class is i nsecure; do not use it DeprecationWarning) Traceback (most recent call last): File "c:\pypy\pypython.py", line 57, in ? x.execFile(sys.argv[1]) File "c:\pypy\pypython.py", line 46, in execFile self.execString(f.read()) File "c:\pypy\pypython.py", line 42, in execString self.ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 206, in ca ll return apply(callable, args, kwds) File "c:\python23\lib\profile.py", line 214, in trace_dispatch_i if self.dispatch[event](self, frame,t): File "c:\python23\lib\profile.py", line 280, in trace_dispatch_return assert frame is self.cur[-2].f_back, ("Bad return", self.cur[-3]) AssertionError: ('Bad return', ('profile', 0, 'testfunc()')) C:\Python22\Lib\test>
Hello, On Mon, Mar 03, 2003 at 09:17:25PM -0500, Rocco Moretti wrote:
Additionally, when testing, an "import test" opens the "test" submodule of Lib/pypy/interpreter.
Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory? We will keep running again and again into this problem. Either none of our test/ subdirectory is a package, or we rename them all (e.g. to testing/) to avoid this confusion. Armin
Armin Rigo <arigo@tunes.org> writes:
? Shouldn't do, if $PYTHONPATH is pointing at the directory containing the pypy directory.
Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory?
Because I wanted to import something from there at some point.
We will keep running again and again into this problem.
Why?
Either none of our test/ subdirectory is a package,
Bad idea, IMO.
or we rename them all (e.g. to testing/) to avoid this confusion.
Better, but should be unecessary. Cheers, M. -- MGM will not get your whites whiter or your colors brighter. It will, however, sit there and look spiffy while sucking down a major honking wad of RAM. -- http://www.xiph.org/mgm/
Hello Michael, On Mon, Mar 10, 2003 at 11:42:47AM +0000, Michael Hudson wrote:
It does, if the current directory is pypy/interpreter (for example when you run python 'interactive.py').
Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory? Because I wanted to import something from there at some point.
Ok, but then:
We will keep running again and again into this problem. Why?
Because then you have no way to import the standard library 'test' package if you current directory happens to contain a local 'test' package -- which will eventually mean almost any PyPy directory. I had the same problems over and over again with Psyco, which had a 'test.py', until I finally decided to rename it to 'test1.py'. I my humble opinion it might have been a bad idea to give a Python standard library package a name as common as 'test', but well, not everybody is supposed to import it in everyday applications. Armin
Armin Rigo <arigo@tunes.org> writes:
So don't do that, run $ PYTHONPATH=. python pypy/interperter/interactive.py then. I can see this being tedious, though. interactive.py could remove the cwd from sys.path, but that also might be surprising.
I actually realised this bit :-) It's just that if you set up your paths the Right Way(tm) you shouldn't bump into this. Perhaps we should do a mass test -> pypytest (or something) renaming, for simplicity. Cheers, M. (relative imports are evil, have I mentioned this lately?) -- I would hereby duly point you at the website for the current pedal powered submarine world underwater speed record, except I've lost the URL. -- Callas, cam.misc
At 13:04 2003-03-10 +0000, Michael Hudson wrote:
I wonder if some kind of aliasing mechanism could solve this kind of problem. E.g., if about to raise an exception for non-existent file/directory, first check for a match to some rewrite patterns in an alias file. They could be simple prefix replacements for paths or more complex regex subs. Then, after rewriting, try the modified path, and only after that fails raise the exception. This would allow creation of platform-independent sys.path name prefixes like, e.g., r"/$$py_lib" and generating, e.g., r"D:\python22\lib" or the unix equivalent as the modified path prefix actually used. All python system files could thus exist under a tree of platform- independent alias prefixes, and pypy could define some for special purposes. There could even be a mechanism for pushing/popping a temporary prefix definition override. Appropriate naming conventions should avoid problems. (I have previously posted about virtualizing part of the file/directory namespace accessed via python's open/file built-ins, and gotten objections that this would not appear to i/o done via the os module or user-written extension modules. I didn't pursue it further, but I still think something platform-independent could be useful.) my .02USD Regards, Bengt Richter (Back from 2 wks on a sunny beach ;-)
Hello Bengt, On Thu, Mar 13, 2003 at 07:04:33PM -0800, Bengt Richter wrote:
I wonder if some kind of aliasing mechanism could solve this kind of problem.
In some point of view we had the opposite problem: importing 'test' finds too many 'test' packages and imports the wrong one.
I think this is interesting, and I need it for the "unit" thing: a platform-independent way to point to a file that can be either 'local', i.e. relative to the directory of the file containing the pointer, or absolute within Python's standard library. Right now I am simply saying that a posix-style name containing at least a '/' is local, and otherwise it is a (possibly dotted) module name from the standard library. Maybe a more general virtual file namespace could be an interesting thing to have. A bientôt, Armin.
participants (5)
-
Armin Rigo -
Bengt Richter -
logistix -
Michael Hudson -
roccomoretti＠netscape.net