When I run numarray.testall.test() from IPython, I get a slew of error messages instead of the successful test output I get when the same version is run from the stock Python interpreter. Anyone else see this?
The same here (OS X, Python 2.3.4, ipython 0.6.5). The problem is due to the way in which numarray performs its tests. It relies on the Python module doctest that execute the script in doc strings. I think that since in numarray doc strings the expected output is written in the standard Python way (i.e. >>> foo) while ipython writes out something like "Out[n]: foo" the checks fail. HTH, Andrea. On 7 Dec 2004, at 01:05, Stephen Walton wrote:
When I run numarray.testall.test() from IPython, I get a slew of error messages instead of the successful test output I get when the same version is run from the stock Python interpreter. Anyone else see this?
This could be true, I noticed that the tests for the nd_image package work fine, and those are written using unittest, which does not rely on the exact textual form of the expected output. On 7 Dec 2004, at 09:54, Andrea Riciputi wrote:
The same here (OS X, Python 2.3.4, ipython 0.6.5). The problem is due to the way in which numarray performs its tests. It relies on the Python module doctest that execute the script in doc strings. I think that since in numarray doc strings the expected output is written in the standard Python way (i.e. >>> foo) while ipython writes out something like "Out[n]: foo" the checks fail.
HTH, Andrea.
On 7 Dec 2004, at 01:05, Stephen Walton wrote:
When I run numarray.testall.test() from IPython, I get a slew of error messages instead of the successful test output I get when the same version is run from the stock Python interpreter. Anyone else see this?
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Andrea Riciputi schrieb:
The same here (OS X, Python 2.3.4, ipython 0.6.5). The problem is due to the way in which numarray performs its tests. It relies on the Python module doctest that execute the script in doc strings. I think that since in numarray doc strings the expected output is written in the standard Python way (i.e. >>> foo) while ipython writes out something like "Out[n]: foo" the checks fail.
Thanks for that info, this is most likely the culprit. Here's a simple test to confirm things: start ipython as 'ipython --classic', which disables the fancy prompt system and makes it produce regular python prompts. Run the tests there and see what happens. Since numarray is more and more likely to be run by ipython users, it might be worth adding a bit of robustness to these tests when under ipython. Here are some suggestions, starting with the simplest: 1. Run a first 'empty' test just to do prompt detection. If this one fails, do: try: __IPYTHON__ except NameError: print 'Big time problem, not caused by ipython' else: print 'Run ipython --classic for doctests to work' or some fancier version of the above. 2. Even better, patch doctest to recognize prompts based on a regexp. The python-mode.el guys did this for (x)emacs support, and it now works very well with ipython. The python-mode CVS code can be studied for the proper regexps. By default this regexp can be set to recognize the normal ipython prompts. 3. If you do 2, and you want to get real fancy, the numarray doctest could build the regexp automatically, from the ipython prompt configuration strings. These are always available at runtime: In [1]: __IPYTHON__.rc.prom __IPYTHON__.rc.prompt_in1 __IPYTHON__.rc.prompt_in2 __IPYTHON__.rc.prompt_out In [1]: __IPYTHON__.rc.prompt_in1 Out[1]: 'In [\\#]:' In [2]: __IPYTHON__.rc.prompt_in2 Out[2]: ' .\\D.:' In [3]: __IPYTHON__.rc.prompt_out Out[3]: 'Out[\\#]:' So the situation looks not too bad. There's a quick fix (--classic) for now, and if someone feels up to the task of patching doctest, a pretty elegant solution can be implemented. Regards, f
I wanted to let you guys know that there's a "post-it note" stuck to my monitor to remind me to look at this. A quick glance indicated that --classic does not fix the problem... but that's all I know so far and all I'll get to in the immediate future. Regards, Todd On Tue, 2004-12-07 at 14:05, Fernando Perez wrote:
Andrea Riciputi schrieb:
The same here (OS X, Python 2.3.4, ipython 0.6.5). The problem is due to the way in which numarray performs its tests. It relies on the Python module doctest that execute the script in doc strings. I think that since in numarray doc strings the expected output is written in the standard Python way (i.e. >>> foo) while ipython writes out something like "Out[n]: foo" the checks fail.
Thanks for that info, this is most likely the culprit. Here's a simple test to confirm things: start ipython as 'ipython --classic', which disables the fancy prompt system and makes it produce regular python prompts. Run the tests there and see what happens.
Since numarray is more and more likely to be run by ipython users, it might be worth adding a bit of robustness to these tests when under ipython. Here are some suggestions, starting with the simplest:
1. Run a first 'empty' test just to do prompt detection. If this one fails, do:
try: __IPYTHON__ except NameError: print 'Big time problem, not caused by ipython' else: print 'Run ipython --classic for doctests to work'
or some fancier version of the above.
2. Even better, patch doctest to recognize prompts based on a regexp. The python-mode.el guys did this for (x)emacs support, and it now works very well with ipython. The python-mode CVS code can be studied for the proper regexps. By default this regexp can be set to recognize the normal ipython prompts.
3. If you do 2, and you want to get real fancy, the numarray doctest could build the regexp automatically, from the ipython prompt configuration strings. These are always available at runtime:
In [1]: __IPYTHON__.rc.prom __IPYTHON__.rc.prompt_in1 __IPYTHON__.rc.prompt_in2 __IPYTHON__.rc.prompt_out
In [1]: __IPYTHON__.rc.prompt_in1 Out[1]: 'In [\\#]:'
In [2]: __IPYTHON__.rc.prompt_in2 Out[2]: ' .\\D.:'
In [3]: __IPYTHON__.rc.prompt_out Out[3]: 'Out[\\#]:'
So the situation looks not too bad. There's a quick fix (--classic) for now, and if someone feels up to the task of patching doctest, a pretty elegant solution can be implemented.
Regards,
f
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion --
Todd Miller schrieb:
I wanted to let you guys know that there's a "post-it note" stuck to my monitor to remind me to look at this. A quick glance indicated that --classic does not fix the problem... but that's all I know so far and all I'll get to in the immediate future.
Bummer. I would have thought that --classic should have been enough. Sorry not to be able to test myself, but I don't have numarray installed at all. Thanks for looking into it, and please let me know if I can help in any way. Regards f
participants (5)
-
Andrea Riciputi -
Fernando Perez -
Peter Verveer -
Stephen Walton -
Todd Miller