Re: [Numpy-discussion] Setting small numbers to zero.
On Wed, Mar 17, 2010 at 8:51 AM, gerardob gberbeg...@gmail.com wrote: How can i modified all the values of a numpy array whose value is smaller than a given epsilon to zero? Example epsilon=0.01 a = [[0.003,2][23,0.0001]] output: [[0,2][23,0]] Give this a try: import numpy as np epsilon=0.01 a=np.array([[0.003,2],[23,0.0001]]) a array([[ 3.e-03, 2.e+00], [ 2.3000e+01, 1.e-04]]) a[np.abs(a) epsilon] = 0 a array([[ 0., 2.], [ 23., 0.]]) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] min bug
On Mon, Nov 16, 2009 at 11:07 PM, Chris fonnesb...@gmail.com wrote: I'm pretty sure this shouldn't happen: In [1]: from numpy import min In [2]: min(5000, 4) Out[2]: 5000 The way you're calling it is working like this: min((5000,) , axis=4) so you'd need to do this instead: min((5000,4)) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] min bug
On Mon, Nov 16, 2009 at 11:34 PM, V. Armando Solé s...@esrf.fr wrote: Sebastian Berg wrote: Known issue, I think someone posted about it a while ago too. The numpy min is array aware, and it expects an array. The second argument is the axis, which in the case of a single number doesn't matter. I think I have to agree with the original poster. It would be more correct to rise an exception because the axis is beyond the number of axes than to return a confusing result. Hm, now that I actually try my example min((5000,), 4) it fails with an axis out of bounds error. I presume there's a reason why a 0-D array gets special treatment? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Removal of deprecated test framework stuff
Hi all, Unless somebody objects, I'd like to remove from NumPy 1.3 the following numpy.testing items that were deprecated in NumPy 1.2 (since the warnings promise we'll do so ;): - ParametricTestCase (also removing the entire file numpy/testing/parametric.py) - The following arguments from numpy.testing.Tester.test() (which is used for module test functions): level, verbosity, all, sys_argv, testcase_pattern - Path manipulation functions: set_package_path, set_local_path, restore_path - NumpyTestCase, NumpyTest Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] cannot find numpy 1.2 for python 2.6 on window
On Sat, Oct 4, 2008 at 11:14 AM, Daniel Wolff [EMAIL PROTECTED] wrote: Hello, I recently upgraded to python 2.6. I cannot seem to find the appropriate numpy install file. I tried to make use of the .exe built for python 2.5 but the installer hung. Any suggestions? Regards, Daniel Hi Daniel, Last I heard, there are still some things that need to be ironed out for NumPy on Python 2.6, so you will probably have to stick with 2.5 for a while. (Somebody please correct me if I'm wrong and there's an imminent release for 2.6 coming up ;) Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove ParametricTestCase from numpy.testing
On Sun, Aug 24, 2008 at 3:20 PM, Jarrod Millman [EMAIL PROTECTED] wrote: On Sun, Aug 24, 2008 at 3:20 PM, Jarrod Millman [EMAIL PROTECTED] wrote: On Sat, Aug 23, 2008 at 10:23 PM, Alan McIntyre [EMAIL PROTECTED] wrote: Actually, it was removed right after the nose framework was working, but I think a decision was made to keep it around until 1.3 in case somebody was using it, so I put it back. :) After the 1.2 release it can just be deleted without any issues, I think. Could you through a deprecation warning in? I suppose throw makes more sense. Sorry, J Done. :) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Buildbot failure
In case it hasn't been noted yet, three of the buildbots (Windows_XP_x86_64_MSVC, Linux_SPARC_64_Debian, Linux_SPARC_64_Debian_gcc4) are failing to build. The Linux builds have the error: gcc: build/src.linux-sparc64-2.4/numpy/core/src/umathmodule.c numpy/core/src/umathmodule.c.src:332: error: static declaration of 'trunc' follows non-static declaration The MSVC build appears to fail with build\src.win32-2.5\numpy\core\include\numpy\__umath_generated.c(580) : error C2065: 'truncf' : undeclared identifier ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove ParametricTestCase from numpy.testing
On Sat, Aug 23, 2008 at 4:49 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: Now that we have switched to Nose as a test framework, we should look into deprecating ParametricTestCase. Alan, have you looked into this before? Actually, it was removed right after the nose framework was working, but I think a decision was made to keep it around until 1.3 in case somebody was using it, so I put it back. :) After the 1.2 release it can just be deleted without any issues, I think. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] What happened to numpy.testing.Tester ?
On Wed, Aug 6, 2008 at 3:57 PM, Robert Pyle [EMAIL PROTECTED] wrote: My machine: Mac dual G5, OSX 10.5.4, Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53), numpy 1.1.1 After considerable agony, I succeeded in building and installing scipy from SVN, only to be told upon importing it: Traceback (most recent call last): File stdin, line 1, in module File /Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/scipy/__init__.py, line 86, in module from numpy.testing import Tester ImportError: cannot import name Tester A message here from Alan McIntyre on June 20, said, in part: NoseTester will still be made available as numpy.testing.Tester. It appears that each of the seemingly innumerable __init__.py files throughout the scipy sources calls for numpy.testing.Tester. Should I ask over on the scipy list as well? Is there some trivial change that will fake out either numpy or scipy into thinking all is well? You will actually need to use NumPy from svn as well, since 1.1.1 didn't have NoseTester (SciPy 0.7 will require NumPy 1.2). ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] running numpy tests
At the moment, bench() doesn't work. That's something I'll try to look at this week, but from Friday until the 15th I'm going to be driving most of the time and may not get as much done as I'd like. On 8/5/08, Andrew Dalke [EMAIL PROTECTED] wrote: On Aug 5, 2008, at 4:19 AM, Robert Kern wrote: def test(...): ... test.__test__ = False That did it - thanks! Does import numpy; numpy.bench() work for anyone? When I try it I get [josiah:~] dalke% python -c 'import numpy; numpy.bench()' -- Ran 0 tests in 0.003s OK I can go ahead and remove those if they don't work for anyone. Andrew [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] import numpy is slow
On Thu, Jul 31, 2008 at 2:12 AM, Andrew Dalke [EMAIL PROTECTED] wrote: Hmm. And it looks like testing/nosetester.py (which implements the 'test' function above) is meant to make it easier to run nose, except my feeling is the extra level of wrapping makes things more complicated. The nosetest command-line appears to be more flexible, with support for, for examples, dropping into the debugger on errors, and reseting the coverage test files. You can actually pass those sorts of options to nose through the extra_argv parameter in test(). That might be a little cumbersome, but (as far as I know) it's something I'm going to do so infrequently it's not a big deal. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Suppressing skipped tests
On Wed, Jul 30, 2008 at 5:01 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: If others agree, could we suppress the output of skipped tests unless specifically requested? They clutter the output, and makes it more difficult to see which real tests fail. I'll see if there's some easy way to do that (I can't remember if I looked for this before), but one way to make them go away is to upgrade nose to 0.10.3 or later. ;) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] import numpy is slow
On Wed, Jul 30, 2008 at 8:19 PM, Andrew Dalke [EMAIL PROTECTED] wrote: numpy defines numpy.test numpy.bench and numpy.testing.test The two 'test's use the same implementation. This is a likely unneeded duplication and one should be removed. The choice depends on if people think the name should be 'numpy.test' or 'numpy.testing.test'. They actually do two different things; numpy.test() runs test for all of numpy, and numpy.testing.test() runs tests for numpy.testing only. There are similar functions in numpy.lib, numpy.core, etc. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.1.1rc2 Mac binary - Please Test.
On Fri, Jul 25, 2008 at 2:48 PM, Christopher Burns [EMAIL PROTECTED] wrote: Reminder, please test the Mac installer for rc2 so we have time to fix any bugs before the release next week. I just tried it; it installs with no problems and tests run with no failures. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Benchmarking code
There's a function (_test_unique1d_speed) in numpy/lib/arraysetops.py that looks to me like it should be in a benchmark suite instead of in the library module. Would anyone mind if I moved it to numpy/lib/benchmarks? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Benchmarking code
On Wed, Jul 23, 2008 at 9:40 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: 2008/7/23 Alan McIntyre [EMAIL PROTECTED]: There's a function (_test_unique1d_speed) in numpy/lib/arraysetops.py that looks to me like it should be in a benchmark suite instead of in the library module. Would anyone mind if I moved it to numpy/lib/benchmarks? No, please go ahead. Thanks, done. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documenting chararrays
On Wed, Jul 23, 2008 at 9:57 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: Hi all, Should we document character arrays? Does anybody still use them? I think their behaviour can largely be duplicated by object arrays. They also seem to be broken: FWIW, I've got issues and patches for a couple of chararray problems: __mul__ problem: http://scipy.org/scipy/numpy/ticket/855 __mod__ problem: http://scipy.org/scipy/numpy/ticket/856 I was wondering myself when I looked at the class whether anybody was actually using it. ;) If it's to be replaced, we should probably remove it from the compiled extension wishlist on http://projects.scipy.org/scipy/numpy/wiki/ProjectIdeas. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.1.1rc1 to be tagged tonight
On Tue, Jul 22, 2008 at 11:44 AM, Charles R Harris [EMAIL PROTECTED] wrote: OK, the only other change since 1.1.0 is using np.x in the doctests, which doesn't look like a big problem. I wonder what the status of that is in 1.1.x? Alan? All the changes I made for that were in the trunk after 1.1.1 was tagged, so the 1.1.1 test behavior should be completely under the old framework's rules. I could probably backport the np.x context to rundocs() (off the top of my head I can't remember if there was any mechanism to run all the doctests in NumPy), but it might just be easier to add import numpy as np to the modules containing doctests that use np.x. I can help with that if need be, just let me know. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.1.1rc1 to be tagged tonight
On Tue, Jul 22, 2008 at 12:48 PM, Charles R Harris [EMAIL PROTECTED] wrote: Actually, I think this should fail in mainline also. Alan, does nose show import failures? I've seen talk of it swallowing some exceptions, but I'm not sure of the specifics. Are you referring to import numpy.ma.mrecords under Python 2.3, NumPy trunk? Here's what I get: Python 2.3.7 (#1, Jul 14 2008, 22:34:29) [GCC 4.1.2 (Gentoo 4.1.2 p1.1)] on linux2 Type help, copyright, credits or license for more information. import numpy.ma.mrecords Traceback (most recent call last): File stdin, line 1, in ? File /usr/local/lib/python2.3/site-packages/numpy/__init__.py, line 107, in ? import ma File /usr/local/lib/python2.3/site-packages/numpy/ma/__init__.py, line 14, in ? import core File /usr/local/lib/python2.3/site-packages/numpy/ma/core.py, line 113, in ? max_filler.update([(k, -np.inf) for k in [np.float32, np.float64]]) AttributeError: keys ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.1.1rc1 to be tagged tonight
On Tue, Jul 22, 2008 at 1:00 PM, Pierre GM [EMAIL PROTECTED] wrote: On Tuesday 22 July 2008 13:00:08 Alan McIntyre wrote: I've seen talk of it swallowing some exceptions, but I'm not sure of the specifics. Are you referring to import numpy.ma.mrecords under Python 2.3, NumPy trunk? Here's what I get: Hold on a second, what are we taling about ? If it's the trunk, it's Numpy1.2, and Python2.3 shouldn't be supported, right ? I've been told NumPy 1.2 doesn't have to support Python 2.3, so I hope that's right. :) If it's the 1.1.x branch, then I'm in trouble. Please don't tell me I'm in trouble. No, I was just trying NumPy trunk against Python 2.3 based on something Charles said; sorry for the confusion. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.1.1rc1 to be tagged tonight
On Tue, Jul 22, 2008 at 4:48 PM, Pierre GM [EMAIL PROTECTED] wrote: Could anybody working on the 1.1.x branch test r5507 ? I just backported a bugfix from 1.2, and I'd like to make sure that 1. it doesn't break anything (I can't see why it should, but), 2. I can close the ticket (#857) Thx a lot in advance ! 1.1.x runs with no errors against 2.3.7, 2.4.5, and 2.5.3 for me on Linux. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Testing: Failed examples don't raise errors on buildbot.
On Sun, Jul 20, 2008 at 9:17 PM, Alan McIntyre [EMAIL PROTECTED] wrote: The skipped test verbosity is annoying; I'll see if there's a way to make that a bit cleaner-looking for some low verbosity level. The latest release version of nose from easy_install (0.10.3) doesn't generate that verbose output for skipped tests. Should we move up to requiring 0.10.3 for tests? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Testing: Failed examples don't raise errors on buildbot.
On Sun, Jul 20, 2008 at 10:56 PM, Robert Kern [EMAIL PROTECTED] wrote: I don't think aesthetics are worth requiring a particular version. numpy doesn't need it; the users can decide whether they want it or not. We should try to have it installed on the buildbots, though, since we *are* the users in that case. Actually I was considering asking to move the minimum nose version up to 0.10.3 just because it's the current version before this aesthetic issue came up. There's about 30 bug fixes between 0.10.0 and 0.10.3, including one that fixed some situations in which exceptions were being hidden and one that makes the coverage reporting more accurate. It's not a big deal, though. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Testing: Failed examples don't raise errors on buildbot.
On Sun, Jul 20, 2008 at 11:17 PM, Gael Varoquaux [EMAIL PROTECTED] wrote: There might be a case to move to 10.3, considering the large amount of bug fixes, but in general I think it is a bad idea to require leading edge packages. The reason being that you would like people to be able to rely on packaged version of the different tools to build an test a package. By packaged versions, I mean versions in the repositories of the main linux distributions, and macport and fink. Each time we require something outside a repository, we loose testers. Fair enough; does anybody have any idea which version of nose is generally available from distributions like the ones you mentioned? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Testing: Failed examples don't raise errors on buildbot.
On Sun, Jul 20, 2008 at 11:34 PM, Gael Varoquaux [EMAIL PROTECTED] wrote: For the rest I can't figure out how to get the information. I suspect we can standardise on things around six month old. Debian unstable tracks closely upstream, Ubuntu and Fedora have a release cycle of 6 months, I don't know about SUSE, but I think it is similar, and macports, fink, or Gentoo trac closely upstream. It looks like Macports is at 0.10.1: http://py-nose.darwinports.com/ So it looks like 0.10.0 should still be a safe bet for being generally available. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chararray __mod__ behavior
On Fri, Jul 18, 2008 at 8:32 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: That looks like a bug to me. I would have expected at least one of the following to work: A % [[1, 2], [3, 4]] A % 1 A % (1, 2, 3, 4) and none of them do. I wouldn't expect the last one to work, since the shapes are different. The first two work if I use .flat to assign the result. Since this actually changes the existing behavior of chararray, I figured it deserved a tracker item: http://scipy.org/scipy/numpy/ticket/856 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] chararray __mod__ behavior
This seems odd to me: A=np.array([['%.3f','%d'],['%s','%r']]).view(np.chararray) A % np.array([[1,2],[3,4]]) Traceback (most recent call last): File stdin, line 1, in module File /opt/local/lib/python2.5/site-packages/numpy/core/defchararray.py, line 126, in __mod__ newarr[:] = res ValueError: shape mismatch: objects cannot be broadcast to a single shape Is this expected behavior? The % gets broadcast as I'd expect for 1D arrays, but more dimensions fail as above. Changing the offending line in defchararray.py to newarr.flat = res makes it behave properly. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Testing -heads up with #random
On Thu, Jul 17, 2008 at 4:25 AM, Fernando Perez [EMAIL PROTECTED] wrote: I was trying to reuse your #random checker for ipython but kept running into problems. Is it working for you in numpy in actual code? Because in the entire SVN tree I only see it mentioned here: maqroll[numpy] grin #random ./numpy/testing/nosetester.py: 43 : if #random in want: 67 : # #random directive to allow executing a command while ignoring its 375 : # try the #random directive on the output line 379 : BadExample object at 0x084D05AC #random: may vary on your system maqroll[numpy] The second example is a doctest for the feature; for me it fails if #random is removed, and passes otherwise. I'm asking because I suspect it is NOT working for numpy. The reason is some really nasty, silent exception trapping being done by nose. In nose's loadTestsFromModule, which you've overridden to include: Ah, thanks; I recall seeing a comment somewhere about nose swallowing exceptions in code under test, but I didn't know it would do things like that. Unfortunately, nose will silently swallow *any* exception there, simply ignoring your tests and not even telling you what happened. Very, very annoying. You can see if you have an exception by doing something like I added that to my local nosetester.py, but it didn't turn up any exceptions. I'll keep it in my working copy so I'm not as likely to miss some problem in the future. Anyway, I mention this because I just wasted a good chunk of time fighting this one for ipython, where I need the #random functionality. It seems it's not used in numpy yet, but I imagine it will soon, and I figured I'd save you some time. Thanks :) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Monkeypatching vs nose plugin?
On Wed, Jul 16, 2008 at 10:00 PM, Robert Kern [EMAIL PROTECTED] wrote: Is there a way to do it programatically without requiring numpy to be installed with setuptools? There is; you have to pass a list of plugin instances to the constructor of TestProgram--all plugins that you might want to use, even the builtin ones. (As far as I know, that is.) The monkeypatching approach was the first one that I could make to work with the least amount of hassle, but it's definitely not the best way. I only had to monkeypatch a couple of things at first, but as I figured out what the test framework needed to do, it just got worse, so I was beginning to get uncomfortable with it myself. (Honest! :) Once the NumPy and SciPy test suites are mostly fixed up to work under the current rules, I'll go back and use a method that doesn't require monkeypatching. It shouldn't have any effect on the public interface or the tests themselves. Since we're discussing this sort of thing, there's something I've been meaning to ask anyway: do we really need to allow end users to pass in arbitrary extra arguments to nose (via the extra_argv in test())? This seems to lock us in to having a mostly unobstructed path from test() through to an uncustomized nose backend. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Monkeypatching vs nose plugin?
On Wed, Jul 16, 2008 at 11:32 PM, Robert Kern [EMAIL PROTECTED] wrote: Since we're discussing this sort of thing, there's something I've been meaning to ask anyway: do we really need to allow end users to pass in arbitrary extra arguments to nose (via the extra_argv in test())? This seems to lock us in to having a mostly unobstructed path from test() through to an uncustomized nose backend. At least with other projects, I occasionally want to do things like run with --pdb-failure or --detailed-errors, etc. What exactly is extra_argv blocking? It's not blocking anything; it just feels wrong for some reason. Probably because I've been duck-punching nose and doctest to death to make them act the way I want, and I can't fit all the doctest/nose/unittest behavior in my head all at once to comfortably say that any of those other options will still work correctly. ;) It's probably just a pointless worry that will be moot after all the monkeypatching is removed, since the underlying test libraries will be in an unaltered state. My preference, actually, is for the nosetests command to be able to run our tests correctly if at all possible. The unit tests will run just fine via nosetests, but the doctests generally will not, because of the limited execution context NoseTester now enforces on them. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Python version support for NumPy 1.2
Which versions of Python are to be officially supported by NumPy 1.2? I've been working against 2.5 and testing against 2.4 occasionally, but 2.3 still has some issues I need to address (or at least that was the case the last time I checked). ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Run np.test() twice, get message.
On Mon, Jul 14, 2008 at 7:58 PM, Fernando Perez [EMAIL PROTECTED] wrote: It's actually coming from doctest. Hardcode import doctest doctest.master = None in the code that runs the tests. This resets a module-global that's the cause of that message. Thanks, Fernando, I added that and it prevents the message. This change is checked in. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release 1.1.1
On Mon, Jul 14, 2008 at 8:21 PM, Pierre GM [EMAIL PROTECTED] wrote: I did as much as I could to ensure compatibility with Python 2.3, but I can't test it myself (can't install Python 2.3 on my machine). It'd be great if somebody could check it works with that version, otherwise I'm all go (the recent pbs with mrecords and exotic flexible types are for 1.2). For what it's worth, I ran the full test suite of NumPy 1.1.1 with Python 2.3.7 (both from svn) on a Linux machine (Gentoo 2.6.24, gcc 4.1.2) and everything passed. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Unused private functions
Does anybody know whether there's any reason to keep the following functions? They don't appear to be used anywhere. linalg/linalg.py:95 _castCopyAndTranspose lib/function_base.py:659 _asarray1d ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Run np.test() twice, get message.
On Mon, Jul 14, 2008 at 1:31 AM, Charles R Harris [EMAIL PROTECTED] wrote: Any idea what this is: *** DocTestRunner.merge: '__main__' in both testers; summing outcomes. Hmm..that's coming from nose. I'll see what it's about tomorrow. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] new chararray test fails on Mac OS X
On Thu, Jul 10, 2008 at 10:06 AM, Christopher Hanley [EMAIL PROTECTED] wrote: From the svn log it looks like the tests are intended to fail? However I would prefer tests that are designed only to fail when problems occur. Otherwise we end up with problems with our automatic build and test scripts. Sorry about that, I just wanted to make sure the tests would actually fail on all the builders before the bug in chararray is fixed. I just checked in a change that disables the failing portions of the test. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] new chararray test fails on Mac OS X
On Thu, Jul 10, 2008 at 8:14 PM, Robert Kern [EMAIL PROTECTED] wrote: For things that you don't expect to be platform specific, there is no need. For things that you do expect to be platform specific on platforms that you cannot access, please ask for volunteers. Make an SVN branch if the changes are extensive. I would like to keep to the rule of not checking in unit tests (on trunk or a 1.1.x branch, etc.) that you expect to fail. Ok. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] A couple of testing issues
Hi all, I wanted to point out a couple of things about the new test framework that you should keep in mind if you're writing tests: - Don't use NumpyTestCase any more, just use TestCase (which is available if you do from numpy.testing import *). Using NumpyTestCase now causes a deprecation warning. - Test functions and methods will only be picked up based on name if they begin with test; check_* will no longer be seen as a test function. I figured I should mention these since there probably hasn't been a general announcement about the testing changes. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A couple of testing issues
On Wed, Jul 9, 2008 at 9:26 AM, Anne Archibald [EMAIL PROTECTED] wrote: - Test functions and methods will only be picked up based on name if they begin with test; check_* will no longer be seen as a test function. Is it possible to induce nose to pick these up and, if not actually run them, warn about them? It's not so good to have some tests silently not being run... Having nose pick up check_ functions as tests may interfere with SciPy testing; it looks like there are a couple dozen functions/methods named that way in the SciPy tree. I didn't look at all of them, though; it could be that some are tests that still need renaming. Since I'm looking at coverage (including test code coverage), any tests that don't get run will be found, at least while I'm working on tests. Still, it might not hurt to have something automated looking for potentially missed tests for 1.2. That would also help with third-party code that depends on NumPy for testing, since they probably don't have the luxury of someone able to spend all their time worrying over test coverage. I can make a pass through all the test_* modules in the source tree under test and post a warning if def check_ is found in them before handing things over to nose.Anyone else have thoughts on this? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A couple of testing issues
On Wed, Jul 9, 2008 at 3:26 PM, Robert Kern [EMAIL PROTECTED] wrote: I don't think it's worth automating on every run. People can see for themselves if they have any such check_methods() and make the conversion once: Does this fall into the how in the world should I have known to do that category? As long as there's a prominent note in the release notes, either containing such suggestions or links to a page that does, I don't have any problem just including this in the list of things that people should do if they're planning on upgrading to 1.2. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Unused matrix method
There's a _get_truendim method on matrix that isn't referenced anywhere in NumPy, SciPy, or matplotlib. Should this get deprecated or removed in 1.2? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unused matrix method
On Wed, Jul 9, 2008 at 4:23 PM, Robert Kern [EMAIL PROTECTED] wrote: On Wed, Jul 9, 2008 at 15:16, Alan McIntyre [EMAIL PROTECTED] wrote: There's a _get_truendim method on matrix that isn't referenced anywhere in NumPy, SciPy, or matplotlib. Should this get deprecated or removed in 1.2? We could remove it. It's a private method. Done. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] chararray constructor change
I'd like to make the following change to the chararray constructor. This is motivated by some of chararray's methods constructing new chararrays with NumPy integer arguments to itemsize, and it just seemed easier to fix this in the constructor. Index: numpy/numpy/core/defchararray.py === --- numpy/numpy/core/defchararray.py(revision 5378) +++ numpy/numpy/core/defchararray.py(working copy) @@ -25,6 +25,11 @@ else: dtype = string_ +# force itemsize to be a Python long, since using Numpy integer +# types results in itemsize.itemsize being used as the size of +# strings in the new array. +itemsize = long(itemsize) + _globalvar = 1 if buffer is None: self = ndarray.__new__(subtype, shape, (dtype, itemsize), ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chararray behavior
On Tue, Jul 8, 2008 at 1:29 PM, Travis E. Oliphant [EMAIL PROTECTED] wrote: Alan McIntyre wrote: Since chararray doesn't currently have any tests, I'm writing some, and I ran across a couple of things that didn't make sense to me: 1. The code for __mul__ is exactly the same as that for __rmul__; is there any reason __rmul__ shouldn't just call __mul__? Just additional function call overhead, but it's probably fine to just call __mul__. 1.5. __radd__ seems like it doesn't do anything fundamentally different from __add__, is there a reason to have a separate implementation of __radd__? Possibly. I'm not sure. I'll probably leave them alone; I was just curious, mostly. 2. The behavior of __mul__ seems odd: What is odd about this? It is patterned after 'a' * 3 'a' * 4 'a' * 5 for regular python strings. That's what I would have expected, but for N = 4, Q*N is the same as Q*4. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chararray behavior
On Tue, Jul 8, 2008 at 3:30 PM, Anne Archibald
[EMAIL PROTECTED] wrote:
In particular, the returned type is always string of length four,
which is very peculiar - why four? I realize that variable-length
strings are a problem (object arrays, I guess?), as is returning
arrays of varying dtypes (strings of length N), but this definitely
violates the principle of least surprise...
Hmm..__mul__ calculates the required size of the result array, but the
result of the calculation is a numpy.int32. So ndarray__new__ is
given this int32 as the itemsize argument, and it looks like the
itemsize of the argument (rather than its contained value) is used as
the itemsize of the new array:
np.chararray((1,2), itemsize=5)
chararray([[';f', '\x00\x00\x00@']],
dtype='|S5')
np.chararray((1,2), itemsize=np.int32(5))
chararray([['{5', '']],
dtype='|S4')
np.chararray((1,2), itemsize=np.int16(5))
chararray([['{5', '']],
dtype='|S2')
Is this expected behavior? I can fix this particular case by forcing
the calculated size to be a Python int, but this treatment of the
itemsize argument seems like it might be an easy way to cause subtle
bugs.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] chararray behavior
Since chararray doesn't currently have any tests, I'm writing some, and I ran across a couple of things that didn't make sense to me: 1. The code for __mul__ is exactly the same as that for __rmul__; is there any reason __rmul__ shouldn't just call __mul__? 1.5. __radd__ seems like it doesn't do anything fundamentally different from __add__, is there a reason to have a separate implementation of __radd__? 2. The behavior of __mul__ seems odd: Q=np.chararray((2,2),itemsize=1,buffer='abcd') Q chararray([['a', 'b'], ['c', 'd']], dtype='|S1') Q*3 chararray([['aaa', 'bbb'], ['ccc', 'ddd']], dtype='|S4') Q*4 chararray([['', ''], ['', '']], dtype='|S4') Q*5 chararray([['', ''], ['', '']], dtype='|S4') Is it supposed to work this way? Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Running doctests on buildbots
On Thu, Jul 3, 2008 at 3:16 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: Sorry for the slow response, I'm still catching up. I think if we turned on doctests right now, there would be about 100 test failures, so I've got plenty of my own catching up to do before doctests really need to be enabled. ;) The Buildbot configuration is kept on buildmaster.scipy.org, that won't help you. It sends a request to the client for (something similar to) make build; make install; make test to be run. The administrator of each slave has control over the Makefile itself, so we'll have to ask those individuals to fix the problem. I wonder how hard it would be to have simpler local makefiles that pull the build/install/test instructions out of svn after the update? That way we don't have to bother the slave maintainers whenever we want to tweak the build/test parameters. If I recall correctly, Python does something like this. I could look into it if it seems worth doing. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] More doctest questions
Just a couple of quick questions for whomever knows: 1. Should we skip the numpy/f2py directory when looking for doctests? 2. Are the functions in numpy/lib/convdtype.py used anywhere? I can fix the doctests so they run, but I can't find anywhere they are used, so I wanted to see if they were intended for removal but forgotten. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] More doctest questions
On Thu, Jul 3, 2008 at 8:26 PM, Robert Kern [EMAIL PROTECTED] wrote: 1. Should we skip the numpy/f2py directory when looking for doctests? I don't see anything there that should cause problems (according to my understanding of the collector). Are you seeing problems? Actually it's a problem with the execution context restriction we added for NumPy doctests; they no longer have access to all the stuff in the module where they are declared. So in f2py/lib/extgen/base.py, the Container doctest expects the Container class to be available, but it isn't. 2. Are the functions in numpy/lib/convdtype.py used anywhere? I can fix the doctests so they run, but I can't find anywhere they are used, so I wanted to see if they were intended for removal but forgotten. I think they were intended to be used for the Numeric-numpy code transformation. It never got used. Delete it. Ok. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] set_local_path in test files
Some test files have a set_local_path()/restore_path() pair at the top, and some don't. Is there any reason to be changing sys.path like this in the test modules? If not, I'll take them out when I see them. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] set_local_path in test files
On Wed, Jul 2, 2008 at 9:35 AM, Pearu Peterson [EMAIL PROTECTED] wrote: Alan McIntyre wrote: Some test files have a set_local_path()/restore_path() pair at the top, and some don't. Is there any reason to be changing sys.path like this in the test modules? If not, I'll take them out when I see them. The idea behind set_local_path is that it allows running tests inside subpackages without the need to rebuild the entire package. Ah, thanks; I'd forgotten about that. I'll leave them alone, then. I made a note for myself to make sure it's possible to run tests locally without doing a full build/install (where practical). ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] set_local_path in test files
On Wed, Jul 2, 2008 at 1:25 PM, Robert Kern [EMAIL PROTECTED] wrote: Please remove them and adjust the imports. As I've mentioned before, numpy and scipy can now reliably be built in-place with python setup.py build_src --inplace build_ext --inplace. This is a more robust method to test uninstalled code than adjusting sys.path. Ok. Since set_package_path is also just used for adjusting sys.path, should that go away as well? If so, I'll remove set_package_path, set_local_path, and restore_path from numpy/testing/numpytest.py, and of course remove all their uses. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] New numpy.test() failures
On Wed, Jul 2, 2008 at 5:22 PM, Charles R Harris [EMAIL PROTECTED] wrote: The Mac seems to have a whole different set of errors than the other bots, lots of import errors like ERROR: Failure: ImportError (cannot import name log) I wonder if there is a path issue somewhere? At least one of those looks nose-related, and is probably due to a difference between 0.10 and 0.11. I was mistakenly using nose from svn locally, and I think I might need to check in a change to NoseTester. I won't be able to get to it for a few hours though. I'm not sure what those other import errors are about. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Doctest items
On Wed, Jul 2, 2008 at 5:47 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: How about a slight modification to Fernando's idea: a dummy function that a) Does nothing if matplotlib is not installed b) Otherwise passes through calls to matplotlib, after setting the backend to /dev/null. Any results (lines, figures, etc.) are suppressed. That's doable; it turned out to be easy to explicitly specify the execution context of the doctests, so we can add in any number of dummy objects/functions. In my working NumPy, the only globally available items are __builtins__ and np; I was going to update all the doctests that won't run under that context before changing the tester behavior, though. At the moment I don't know anything about configuring matplotlib's backend and all that, but I'm sure it shouldn't be hard to figure out. If somebody was to write a first draft of these dummy objects before I got around to it I wouldn't complain about it, though. ;) (By the way, I'm not assuming that there's a consensus about the matplotlib dummy objects, just saying it turns out to be easy to add if we want to.) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] More pending test framework changes (please give feedback)
On Mon, Jun 30, 2008 at 1:54 PM, Alan McIntyre [EMAIL PROTECTED] wrote: 1. All doctests in NumPy will have the numpy module available in their execution context as np. 2. Turn on the normalized whitespace option for all doctests. Having a doctest fail just because there's a space after your result seems like an unnecessary hassle for documenters. 3. Output will be ignored for each doctest expected output line that contains #random. I figured this can serve both as an ignore flag and indication to the reader that the listed output may differ from what they see if they execute the associated command. So you would be able to do: random.random() 0.1234567890 #random: output may differ on your system And have the example executed but not cause a failure. You could also use this to ignore the SomeObject at 0x1234ABCD output from plot methods as well. Since I didn't see any objections, these changes are now committed. I'll be updating some doctests to take advantage of them later today. Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Doctest items
Just a few questions/comments about doctests: 1. Should all doctests be written such that you could start Python, do an import numpy as np, and then type in the examples verbatim? There are a number that currently wouldn't work that way (they depend on the function under test being in the local namespace, for example). 2. In regard to the auto-ignore of plt., etc. in commands: using the existing ellipsis feature of doctest should cover a significant portion of the cases that the auto-ignore was suggested to solve, and it's a very minor change to enable it (whereas the auto-ignore is more involved). If nobody objects, I will enable ellipsis for all doctests (which doesn't cause any obvious problems in existing NumPy tests), and use it to clean up existing doctests where appropriate. If the auto-ignore capability is still needed after that, I'll work on it. 3. When the test suite is run with doctests enabled, some unit tests fail that normally wouldn't, and some doctests fail that shouldn't. There's probably some state that needs to be reset (or otherwise managed) between doctest runs; I'll look into that and provide a fix as soon as possible. I just figured I should mention it in case it causes somebody problems before it gets fixed. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Coverage improvement requests
Hi all, This week I'm going to start working on new tests to improve Python code coverage in NumPy (C code coverage will come later in the summer, or maybe even after GSoC). Does anyone have recommendations for particularly important bits of code that need coverage? If not, I'm just going to start on modules with the largest number of uncovered lines, and go from there. Thanks, Alan (Sorry for the flood of posts) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Doctest items
On Tue, Jul 1, 2008 at 2:45 PM, Robert Kern [EMAIL PROTECTED] wrote: If the auto-ignore capability is still needed after that, I'll work on it. It seems to me that the ellipsis mechanism just allows the output to differ. However, matplotlib would still be required because plt.plot() would still be executed. matplotlib should not be a requirement for running the tests. Oops, I misunderstood, then: I thought the intent was to execute the statement but not compare the output (because they returned objects that had their address in the repr). I didn't look before to see how many times this feature would be needed (yeah, should have done that before complaining about using #doctest: +SKIP), but now that I look, I only see one batch of plt. commands, in numpy.lib.function_base.bartlett. In view of that, does it make more sense to use the SKIP directive for the ten plt. lines in that one example? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] More pending test framework changes (please give feedback)
On Tue, Jul 1, 2008 at 2:37 PM, Charles R Harris [EMAIL PROTECTED] wrote: I note that a lot of unit test files import tons of specific functions, numpy.core, etc., etc. Is there any reason not to fix things up to import numpy as np from numpy.testing import * I fixed one file this way, but I wonder if we shouldn't make all of them work like that. Personally, I prefer the imports to be as simple as possible, but I managed to restrain myself from cleaning up test module imports when I was making my changes. ;) If making them somewhat standardized is desirable, I might as well do it while I'm cleaning up and fixing tests. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Doctest items
On Tue, Jul 1, 2008 at 3:20 PM, Robert Kern [EMAIL PROTECTED] wrote: Can it work on an entire section? If not, can we do something that works on a whole section? Everything after Plot the window and its frequency response: is not required for testing. It's on a per-line basis at the moment, so each lines needs a #doctest: +SKIP. Changing a directive to apply to multiple lines probably isn't trivial (I haven't really looked into doing that, though). We could always just make the plotting section one of those it's just an example not a doctest things and remove the (since it doesn't appear to provide any useful test coverage or anything). ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Doctest items
On Tue, Jul 1, 2008 at 3:39 PM, Charles R Harris [EMAIL PROTECTED] wrote: We could always just make the plotting section one of those it's just an example not a doctest things and remove the (since it doesn't appear to provide any useful test coverage or anything). Would it serve to overload plot with a function that does zippo? Probably not in this case; there's an explicit matplotlib import, and then a bunch of method calls on a matplotlib object: from matplotlib import pyplot as plt window = np.bartlett(51) plt.plot(window) plt.title(Bartlett window) and so on. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Doctest items
On Tue, Jul 1, 2008 at 3:33 PM, Robert Kern [EMAIL PROTECTED] wrote: That's not a bad idea. Coordinate with Stéfan about the details (if any are left to be decided). Ok, will do. I'll also update all the test documentation I can find so that documenters have a chance of being aware of the doctest assumptions/requirements/capabilities. So, unless anyone else has objections, I'll: 1. Enabled ellipsis for all doctests 2. Update all doctests so that they only assume import numpy as np. I'll also check into restricting the doctest execution environment so that tests that make other assumptions should fail (as part of figuring out the test state pollution problem). ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] More pending test framework changes (please give feedback)
On Tue, Jul 1, 2008 at 3:37 PM, Charles R Harris [EMAIL PROTECTED] wrote: A lot of the imports seem to have just grown over the years, some even contain duplicates. So I think cleaning up would be a good idea if no one objects. Ok. As a pre-emptive clarification, I'll only be tweaking imports in unit test files--I don't want to mess with any of the magic that goes on in the package imports. ;) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Doctest items
On Tue, Jul 1, 2008 at 4:41 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: All in all, I'd estimate this to be ~100 lines, put in a suitable location. If possible, I'd like other possibilities be considered first before jumping this route. I think it would be nice to retain the ability to run also the matplotlib examples as (optional) doctests, to make sure also they execute correctly. Also, using two different markups in the documentation to work around a shortcoming of doctest is IMHO not very elegant. Well, for the moment, it's 100 lines of new code that's needed in order to *avoid* running 10 lines of doctest code in one function's docstring. Maybe down the road there will be more examples that need a bulk don't execute me mechanism, and if we do I'll be glad to work on it, but for right now I need to spend more time increasing coverage. I also agree with Ryan that matplotlib is where the tests for this particular use case of the object returned by bartlett should be. So at the moment I'm inclined to just remove the and come back to it later. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Undefined wrap in linalg.py:tensorsolve.py
While I was working on the doctest tweaks, I ran across a doctest that failed because tensorsolve uses a function wrap that's not defined. It seems that I should make the following change to fix it (at the start of tensorsolve's code) : -a = asarray(a) +a,wrap = _makearray(a) Doing so seems to make the example run, but I just wanted to see if this was the appropriate thing to do. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] More pending test framework changes (please give feedback)
Hi all, I can commit any/all of the following changes as long as they are agreeable to everybody: 1. All doctests in NumPy will have the numpy module available in their execution context as np. 2. Turn on the normalized whitespace option for all doctests. Having a doctest fail just because there's a space after your result seems like an unnecessary hassle for documenters. 3. Output will be ignored for each doctest expected output line that contains #random. I figured this can serve both as an ignore flag and indication to the reader that the listed output may differ from what they see if they execute the associated command. So you would be able to do: random.random() 0.1234567890 #random: output may differ on your system And have the example executed but not cause a failure. You could also use this to ignore the SomeObject at 0x1234ABCD output from plot methods as well. If these get committed, I'll also revert doctests I changed earlier so that they use the provided np instead of importing it, and fix any currently failing doctests that can be addressed with the new behavior. I've already got a batch of these changes made locally just to try out the new features, but I'll wait to see if adding the features causes any troubles on the buildbots first. There are a couple of options that I haven't got patches for yet: 4. Doctest commands starting with plt. or plot. will automatically have their output ignored. 5. Add a decorator that causes all doctest output for that function/method's docstring to be ignored. (This is for cases with many examples, all of which should be executed but not compared, so you don't have to clutter up each output line with #random or ellipsis) If there is still a big need for these, I'll work on them. As an alternative to 3,4 and 5, you could use the ELLIPSIS directive to ignore the varying bits of the output, but you'd still have to put the directive on each command line where you needed it. Unless I turn on the ellipsis feature for all doctests, that is; it's easy to do, and it doesn't cause me any obvious problems locally. I don't know whether that's something that's generally a good idea, though. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Running doctests on buildbots
Hi all, It seems to me that the buildbots should be running the doctests in addition to the unit tests, but right now the buildbot test command numpy.test(level=,verbosity=) doesn't do that. We could either add doctests=True to the buildbot test command, or make level above some threshhold run them (currently the level argument is just ignored anyway). Since the level and verbosity parameters are going away in the release after 1.2, it seems more appropriate to just add the doctests argument. Any thoughts? Thanks, Alan P.S. Thanks to whoever installed nose on the buildbots! ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Running doctests on buildbots
On Mon, Jun 30, 2008 at 2:55 PM, Robert Kern [EMAIL PROTECTED] wrote: Add the doctests argument. Where is the buildbot configuration kept? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nosetester.py can't use decorators and work with python2.3
On Thu, Jun 26, 2008 at 1:37 PM, Charles R Harris [EMAIL PROTECTED] wrote: Decorators weren't introduced until Python2.4. I'm not sure what version we require now, that information should probably be added to a DEPENDENCY file, or maybe the README. Anyway, if we still support Python2.3 we can't use decorators. I can remove those decorators; there's no point in requiring 2.4 just for updating some docstrings. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nosetester.py can't use decorators and work with python2.3
On Thu, Jun 26, 2008 at 1:51 PM, Jarrod Millman [EMAIL PROTECTED] wrote: Starting with NumPy 1.2 and SciPy 0.7 we will require Python 2.4 or greater. I will make sure to update the documentation later today, if no one gets to it before me. In that case I will leave the decorators in nosetester.py. By the way, what about 2.6 and 3.0? I know they're not close to being out yet, but are we going to worry about them at all for 1.2? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code samples in docstrings mistaken as doctests
On Mon, Jun 23, 2008 at 3:03 PM, Alan McIntyre [EMAIL PROTECTED] wrote: On Mon, Jun 23, 2008 at 2:37 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: Can you make the convention chosen for the examples (currently only in the doc wiki, not yet in SVN) to work: assuming import numpy as np in examples? This would remove the need for those from numpy import * lines in the examples that I see were added in r5311. Sure, I'll look at that. It seems like every possible option for importing stuff from numpy is used in doctests (sometimes even in the same module), so having them standardized with that implicit import is much better. It turns out it's possible to give all the doctests an implicit import numpy as np (and probably any other arbitrary tweaks to their execution context, if need be). Once I can include some of the other doctest tweaks discussed in this thread, and it's checked in, I'll go back and remove all those import numpy statements I inserted into the docstrings. Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code samples in docstrings mistaken as doctests
On Mon, Jun 23, 2008 at 2:37 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: Can you make the convention chosen for the examples (currently only in the doc wiki, not yet in SVN) to work: assuming import numpy as np in examples? Are there any other implicit imports that we will need? How about for SciPy, since the NumPy test framework will also be handling SciPy tests in 0.7? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code samples in docstrings mistaken as doctests
On Mon, Jun 23, 2008 at 2:02 PM, Fernando Perez [EMAIL PROTECTED] wrote: There's also the option of marking them so doctest skips them via #doctest: +SKIP http://docs.python.org/lib/doctest-options.html For short examples, that seems like a good option, but it seems like you have to have that comment on every line that you want skipped. There are some long examples (like the one in lib/function_base.py:bartlett) that (to me) would look pretty ugly having that comment tacked on to every line. Either way is fine with me in the end, though, so long as it doesn't produce test failures. :) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code samples in docstrings mistaken as doctests
On Mon, Jun 23, 2008 at 2:37 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: Can you make the convention chosen for the examples (currently only in the doc wiki, not yet in SVN) to work: assuming import numpy as np in examples? This would remove the need for those from numpy import * lines in the examples that I see were added in r5311. Sure, I'll look at that. It seems like every possible option for importing stuff from numpy is used in doctests (sometimes even in the same module), so having them standardized with that implicit import is much better. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code samples in docstrings mistaken as doctests
On Mon, Jun 23, 2008 at 3:21 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: Another alternative is to replace +SKIP with something like +IGNORE. That way, the statement is still executed, we just don't care about its outcome. If we skip the line entirely, it often affects the rest of the tests later on. Ugh. That just seems like a lot of unreadable ugliness to me. If this comment magic is the only way to make that stuff execute properly under doctest, I think I'd rather just skip it in favor of clean, uncluttered, non-doctestable code samples in the docstrings. If the code that's currently in docstrings needs to be retained as test code, I'll gladly take the time to put it into a test_ module where it doesn't get in the way of documentation. I'll defer to the consensus, though. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code samples in docstrings mistaken as doctests
On Mon, Jun 23, 2008 at 3:57 PM, Pauli Virtanen [EMAIL PROTECTED] wrote:
Schematic code (such as that currently in numpy.bmat) that doesn't run
probably shouldn't be written with , and for it the ReST block quote
syntax is also looks OK.
But I'm personally not in favor of a distinction between a doctest and
a code sample, as the difference is not of interest to the main target
audience who reads the docstrings (or the reference documentation
generated based on them). As I see it, Numpy has a test architecture that
is separate from doctests, so that most of the bonus doctests gives us is
ensuring that all of our examples run without errors and produce expected
results.
I agree with you, Anne and Michael that ensuring that the
documentation examples run is important. The more I think about it,
the more I'd rather have examples that are a bit verbose. In the
particular example of bmat, as a new user, I'd really honestly rather
see those three cases fully coded:
A=nd.arange(1,5).reshape(2,2)
B= etc.
F=bmat('A,B;C,D')
F
matrix([[1,2,5,6],
etc.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code samples in docstrings mistaken as doctests
On Mon, Jun 23, 2008 at 4:07 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: Another idea (in addition to whitelisting): how easy would it be to subclass doctest.DocTestParser so that it would eg. automatically +IGNORE any doctest lines containing plt.? I'll play around with that and see how hard it is to just ignore the ugly bits that currently require all that per-line directive stuff. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code samples in docstrings mistaken as doctests
On Mon, Jun 23, 2008 at 4:51 PM, Robert Kern [EMAIL PROTECTED] wrote: I agree that this can be awkward sometimes, and should certainly not be policy, but one can usually get around this. Instead of printing the result, you can use it, or demonstrate porperties: random_array = np.random.rand(3,4) random_array.shape (3,4) random_array.max() 1 True random_array.min() 0 True Yes, this makes it doctestable, but you've destroyed the exampleness. It should be policy *not* to do this. So it seems we have: 1. Example code that is doctestable 2. Example code that probably can't ever be doctestable (random number stuff, etc.), but is still executable 3. Schematic examples that aren't executable Personally, I'm in favor of filling out examples of type #3 to make them at least #2, but maybe that's not always practical. I don't think #3 should ever have prompts, so it shouldn't ever be picked up by doctest. I suppose I could go for a decorator option to flag #2. If we execute them, but not look at the results, then at least we find out about examples that are broken enough to raise exceptions. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Using numpy.testing for SciPy
For what it's worth, I tried deleting scipy/testing, changed all the scipy.testing references to numpy.testing, and it would appear that the NumPy test setup is able to run all the SciPy tests just fine (which shouldn't be too surprising, since that's where I stole it from in the first place). So whenever it's appropriate, it should be easy to switch SciPy over to use the NumPy test code. It does seem that the coverage option doesn't work correctly, though; it reports that no SciPy code is being executed. I'll have a look into that this week. Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Win64 buildbot stuck?
It looks like the Windows_XP_x86_64_MSVC buildbot is stuck in the build phase for some reason. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test framework changes
These changes are now checked in, with the changes Robert suggested: numpy.test() returns a TextTestResult object again, and coverage (if enabled) is limited to the package from which test is called. The tests still fail because the buildbots don't have nose installed, though. On Fri, Jun 20, 2008 at 5:01 PM, Alan McIntyre [EMAIL PROTECTED] wrote: Hi all, Just wanted to get feedback about the following changes before I make them. Please speak up if any of this seems objectionable to you. - The old test framework classes will be restored, but will not be used anywhere in NumPy's tests. If your old tests still don't work with the restored classes, please let me know and I'll fix it. - Add a function to numpy.testing to execute a module's tests via the if __name__ == '__main__' hook. It takes one optional argument, the name of the file to run (if not present, it uses the same method as NoseTester to look it up from the stack). The intent is to make the boilerplate as simple as possible. if __name__ == '__main__': run_module_suite() If somebody has a suggestion for a better name, I'd love to hear it. I didn't want test in the name, because then I have to explicitly tell nose to ignore it when it's looking for test functions. - Remove numpy/testing/pkgtester.py since it now just has one line of code that imports NoseTester (as Tester) from nosetester.py (it used to create a null tester if nose wasn't present, but this was removed by porting of r4424 from SciPy). NoseTester will still be made available as numpy.testing.Tester. - numpy.test (and all the other test functions in subpackages) will take the following positional arguments: label, verbose, extra_argv, doctests, coverage (the same arguments as SciPy.test except for the new coverage option). The old arguments can be passed in as keyword arguments (which seems to be how they were passed in in all the examples I could find), and they will be emulated as much as possible by the new test suite, but a deprecation warning will be issued. - numpy.test now returns an object with a wasSuccessful method; under the old test framework it returned a unittest._TextTestResult, but since nose.run only returns success/failure, I'm just wrapping this result in a dummy object to match the old behavior until I can figure out how to get a real _TextTestResult from nose. (The two changes to numpy.test should allow the buildbots to run the tests properly again) Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Test framework changes
Hi all, Just wanted to get feedback about the following changes before I make them. Please speak up if any of this seems objectionable to you. - The old test framework classes will be restored, but will not be used anywhere in NumPy's tests. If your old tests still don't work with the restored classes, please let me know and I'll fix it. - Add a function to numpy.testing to execute a module's tests via the if __name__ == '__main__' hook. It takes one optional argument, the name of the file to run (if not present, it uses the same method as NoseTester to look it up from the stack). The intent is to make the boilerplate as simple as possible. if __name__ == '__main__': run_module_suite() If somebody has a suggestion for a better name, I'd love to hear it. I didn't want test in the name, because then I have to explicitly tell nose to ignore it when it's looking for test functions. - Remove numpy/testing/pkgtester.py since it now just has one line of code that imports NoseTester (as Tester) from nosetester.py (it used to create a null tester if nose wasn't present, but this was removed by porting of r4424 from SciPy). NoseTester will still be made available as numpy.testing.Tester. - numpy.test (and all the other test functions in subpackages) will take the following positional arguments: label, verbose, extra_argv, doctests, coverage (the same arguments as SciPy.test except for the new coverage option). The old arguments can be passed in as keyword arguments (which seems to be how they were passed in in all the examples I could find), and they will be emulated as much as possible by the new test suite, but a deprecation warning will be issued. - numpy.test now returns an object with a wasSuccessful method; under the old test framework it returned a unittest._TextTestResult, but since nose.run only returns success/failure, I'm just wrapping this result in a dummy object to match the old behavior until I can figure out how to get a real _TextTestResult from nose. (The two changes to numpy.test should allow the buildbots to run the tests properly again) Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] NumPy coverage via nose
Hi all, Nose has a plugin (included in the current version of nose) that uses Ned Batchelder's coverage module (http://nedbatchelder.com/code/modules/coverage.html) to provide coverage information. Is it acceptable to use this capability in nose to provide coverage reporting for NumPy? The coverage module is only needed if you actually want to check coverage. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy coverage via nose
On Fri, Jun 20, 2008 at 5:44 PM, Robert Kern [EMAIL PROTECTED] wrote: Specifically, what changes are you thinking of making? numpy.test(coverage=True) already triggers nose's coverage feature. Actually, that wasn't supposed to get added in my last checkin; I was experimenting with it and forgot to take it out. :/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test framework changes
On Fri, Jun 20, 2008 at 5:35 PM, Robert Kern [EMAIL PROTECTED] wrote: So NoseTester.run() basically just calls nose.run(). That basically just instantiates nose.core.TestProgram and returns the .success attribute of it. Unfortunately, the TextTestResults object (a nose subclass of unittest._TextTestResults) gets created and discarded inside the nose.core.TestProgram.runTests() method. However, if you were to subclass it and override that method to store the TextTestResults to an attribute, you could return it from NoseTester.run(). Yep. I was hoping there was some built-in way to get to the details of the results via the nose API, but that doesn't appear to be something the nose developers considered. I'll probably go ahead and do as you suggested instead of making a temporary class to hold the result. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test framework changes
On Fri, Jun 20, 2008 at 7:22 PM, Fernando Perez [EMAIL PROTECTED] wrote: It may be worth bringing it up wtih the nose guys here: http://lists.idyll.org/listinfo/testing-in-python The nose author seems very responsive, and Titus Brown is on the list and cares a lot about numpy/scipy, and he may offer suggestions as well. Thanks, I'll do that. :) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose changes checked in
On Wed, Jun 18, 2008 at 5:24 PM, Robert Kern [EMAIL PROTECTED] wrote: - The signature of numpy.test in 1.2 will be backward compatible with 1.1, and it will at least return some indication of failure (if not the same object as in 1.1). This will, by the way, make it different from the signature and behavior of scipy.test. scipy.test() should be made to match numpy.test(). scipy.testing was a staging ground for the nose changes in numpy, not a separate branch of development. Ok. Jarrod mentioned that the intent is to change SciPy over to use numpy.testing (and remove scipy.testing) once NumPy's nose transition is complete. Is that something that something that will happen simultaneously in the next release, or will SciPy lag behind one cycle? Either way, at some point in the next few weeks I'll try making that change locally just to see if it turns up any surprising requirements in the NumPy side. For my preference, we should accept the old argument signature with a deprecation warning but prefer the current signature. This is a little hairy, but such is life with deprecations. Do you want a blanket warning, or only a warning if test() gets keyword arguments from the old signature? Also, since the numpy.testing.ScipyTestCase and ScipyTest classes already had deprecation warnings in 1.1, I'll leave them out in 1.2, if that's ok. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose test return values
On Wed, Jun 18, 2008 at 12:21 PM, Christopher Hanley [EMAIL PROTECTED] wrote: I have received the following message from our system guru here at STScI regarding the recent changes to the way testing is done with nose. The automated scripts he was using to monitor the success or failure of numpy builds is now broken. Below is his message: The new numpy test interface returns None instead of unittest._TextTestResult snip I believe that he makes a very good point. Is there any way that some form of test report object can be returned? I'll see if I can make that work correctly. The buildbots currently depend on this behavior as well. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose changes checked in
On Wed, Jun 18, 2008 at 11:42 AM, Anne Archibald [EMAIL PROTECTED] wrote: You can replace ParametricTest with generators, as described here: http://scipy.org/scipy/scipy/wiki/TestingGuidelines Hmm. This won't work with the current version of numpy, will it? That is, it needs nose. (I run much code on the work machines, which I (thankfully) do not administer, and which are running a variety of ancient versions of numpy (some even have only Numeric, to support horrible quasi-in-house C extensions).) So I'd like to write my tests in a way that they can run on both new and old versions of numpy. Yes, right now the generator test method needs nose to work correctly. Once the old test framework stuff is added back, you should be able to run 1.1 tests on 1.2. When I'm adding that stuff back I'll also add tests for numpy.testing to make sure the old test styles keep working. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Buildbot config
On Tue, Jun 17, 2008 at 7:38 AM, Alan McIntyre [EMAIL PROTECTED] wrote: Where do we keep the buildbot configuration? The arguments for numpy.test have changed with the switch to nose, so the test step fails. It also appears nose needs to be installed/updated on the build slaves. Eh, please disregard this request. Unless somebody objects, I'm just going to revert numpy.test to its original signature and (as close as possible) behavior, so the buildbot script (and people's existing code that uses numpy.test) shouldn't need updating. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose changes checked in
On Wed, Jun 18, 2008 at 12:05 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: a) Warn that Nose is becoming a dependency (next release). Is next release referring to 1.2 or the release after that? If it's the release after 1.2, then I assume that 1.2 must still be able to run all its tests without nose. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Buildbot config
To whomever knows, Where do we keep the buildbot configuration? The arguments for numpy.test have changed with the switch to nose, so the test step fails. It also appears nose needs to be installed/updated on the build slaves. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose changes checked in
On Mon, Jun 16, 2008 at 11:17 PM, Robert Kern [EMAIL PROTECTED] wrote: These files were for the in-development g3 version of f2py. That development has moved outside of numpy, so I think they can be removed wholesale. Some of them seem to require a Fortran 90 compiler, so I have had them fail for me. Removing these is a high priority. Nice, thanks. For what it's worth, removing both of those files doesn't seem to cause any problems for me locally with NumPy or SciPy. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose changes checked in
On Tue, Jun 17, 2008 at 9:26 AM, David Huard [EMAIL PROTECTED] wrote: I noticed that NumpyTest and NumpyTestCase disappeared, and now I am wondering whether these classes part of the public interface or were they reserved for internal usage ? In the former, it might be well to deprecate them before removing them. ParametricTestCase is gone too. There was at least one person using it that said he didn't mind porting to the nose equivalent, but I expect that's an indication there's more people out there using them. If there's a consensus that they need to go back in and get marked as deprecated, I'll put them back. Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose changes checked in
On Tue, Jun 17, 2008 at 8:15 PM, Anne Archibald [EMAIL PROTECTED] wrote: Uh, I assumed NumpyTestCase was public and used it. I'm presumably not alone, so perhaps a deprecation warning would be good. What backward-compatible class should I use? unittest.TestCase? Yes, unittest.TestCase seemed to be completely adequate for all the existing tests in NumPy. Unless you need some functionality explicitly implemented in NumpyTestCase (like the 'measure' or 'rundocs' methods), you can just replace it with TestCase. TestCase can be imported from numpy.testing, although (now that I think about it) it's probably less cryptic to just import it from unittest. For module-level doctests, you can place something like this in the module: from numpy.testing import * def test(): return rundocs() You can replace ParametricTest with generators, as described here: http://scipy.org/scipy/scipy/wiki/TestingGuidelines I will document all this more completely once the test setup isn't changing on a daily basis, honest. I'm assuming this experience should tell me that any item bar that I can get by issuing from numpy.foo import bar should be considered the public API and therefore deprecated instead of removed? ;) Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose changes checked in
On Mon, Jun 16, 2008 at 8:39 PM, Robert Kern [EMAIL PROTECTED] wrote: Please port over the changes I made to scipy.testing in scipy's r4424 in order to avoid importing nose until the actual execution of tests. By the way, I notice that making those changes broke the ability to run a single test module with the command python numpy/numpy/foo/tests/test_bar.py. So for both NumPy and SciPy, the boilerplate if __name__ == '__main__' stuff needs to be changed if we're going to retain that capability. I think I'd prefer to see a convenience function in numpy.testing that could be used to run the module instead of sprinkling import nose in all that boilerplate, especially since most of the test modules are already doing a from numpy.testing import * anyway. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] nose changes checked in
Hi all, I just checked in the switch to use nose to run unit tests. Please let me know if you experience any difficulties as a result. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose changes checked in
On Mon, Jun 16, 2008 at 8:39 PM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Jun 16, 2008 at 19:28, Alan McIntyre [EMAIL PROTECTED] wrote: Please port over the changes I made to scipy.testing in scipy's r4424 in order to avoid importing nose until the actual execution of tests. Done in r5289. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose changes checked in
On Mon, Jun 16, 2008 at 9:04 PM, Charles R Harris [EMAIL PROTECTED] wrote: Did you add any documentation to the readme? Any particular version dependency for Nose? I did update README.txt, but I forgot to put the minimum Nose version in there; thanks for mentioning that. I just checked in an update that includes it. Hmm, plenty of output, 1 failure, and it looks like a future warning in histogram needs to be disabled. In [1]: numpy.test() Not implemented: Defined_Binary_Op Not implemented: Defined_Binary_Op Defined_Operator not defined used by Generic_Spec Needs match implementation: Allocate_Stmt Needs match implementation: Associate_Construct snip That stream of Not implemented and Needs match implementation stuff comes from numpy/f2py/lib/parser/test_Fortran2003.py and Fortran2003.py. I can silence most of that output by disabling those module-level if 1: blocks in those two files, but there's still complaints about Defined_Binary_Op not being implemented. If someone more knowledgeable about that module could comment on that I'd appreciate it. I'll also look into that test_linalg failure first thing in the morning; I don' get that here. Looks slower than the old testing framework, but not enough to matter. There were at least a couple of tests that didn't get run under the old framework, but the ones I can recall didn't look complicated enough to make a difference. Looks like the buildbots need nose installed or upgraded as well. Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Switching to nose test framework (was: NumpyTest problem)
On Wed, Jun 11, 2008 at 6:09 PM, Robert Kern [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 04:57, Stéfan van der Walt [EMAIL PROTECTED] wrote: 2008/6/10 Alan McIntyre [EMAIL PROTECTED]: Is the stuff Robert pointed out on a wiki page somewhere? It would be nice to have a Welcome noob NumPy developer, here's how to do NumPy-specific development things, page. There may be such a page, but I just haven't stumbled across it yet. We could add this info the the `numpy` docstring; that way new users will have it available without having to search the web. Build instructions don't really belong in docstrings. Put it in the README.txt or DEV_README.txt. I agree; I'm far more likely to look at the READMEs than in module docstrings for build/test instructions. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
