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
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))
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.
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
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,
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
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:
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,
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
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:
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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).
___
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
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
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
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.
___
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 =
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
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
, 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
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
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
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
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
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
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
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
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
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
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
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
___
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
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
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
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
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
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
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
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
1 - 100 of 122 matches
Mail list logo
