On Wed, Mar 17, 2010 at 8:51 AM, gerardob 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.0
On Mon, Nov 16, 2009 at 11:34 PM, "V. Armando Solé" 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.
>
>
On Mon, Nov 16, 2009 at 11:07 PM, Chris 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))
_
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.
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
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: st
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 remove
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 work
old upon importing it:
>
> Traceback (most recent call last):
> File "", line 1, in
> File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/scipy/__init__.py", line 86, in
> from numpy.testing import Tester
> Impor
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 nos
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 peo
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 wa
On Wed, Jul 30, 2008 at 4:12 PM, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> 4) numpy.testing takes 0.041 seconds to import. The text I quoted
> above says that it's a numpy requirement that 'testing' always be
> imported, even though I'm hard pressed to figure out why that's
> important.
I suppos
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.
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
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 ins
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
Num
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)
> Th
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.mrecor
On Tue, Jul 22, 2008 at 1:00 PM, Alan McIntyre <[EMAIL PROTECTED]> 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?
When I run numpy/n
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.mr
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 afte
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 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
> r
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* th
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)
On Sun, Jul 20, 2008 at 7:10 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Not raising errors seems ok for examples, but some of the unit tests are
> also implemented as doctests and the failures are hidden in the logs. I'm
> not sure what to do about this, but thought it worth pointing out. Al
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
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 "", line 1, in
File "/opt/local/lib/python2.5/site-packages/numpy/core/defchararray.py",
line 126, in __mod__
newarr[:] = res
ValueE
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]> g
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-di
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 s
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 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 (
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
On Sun, Jul 13, 2008 at 8:26 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote:
> 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/
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-d
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.o
On Sun, Jul 13, 2008 at 2:32 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> For numpy, we obviously must first remove all the ipython-specific
> code from there. The two plugins are separated, so it's perfectly
> doable, I just ran out of time. I'm putting it here in the hopes that
> it will be
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
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
>
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 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
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/
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"
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 actuall
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 warni
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
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.
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 a
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 pro
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 int
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
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.
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 o
The buildbot test command should be using sys.exit to return the
success flag from the test run, but it's not. The FreeBSD's test
command is:
/usr/local/bin/python2.4 -c 'import numpy,sys;sys.exit(not
numpy.test(level=,verbosity=).wasSuccessful())'
while the OSX bot's command is
python
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 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 modu
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 lis
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
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 imp
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 d
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 s
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 mome
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 w
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()
>
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 star
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
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 fa
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-d
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 thr
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 th
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 s
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 noset
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 c
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 abo
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: a
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 =
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
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 distinc
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 t
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 *" li
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 ha
Hi all,
Some docstrings have examples of how to use the function that aren't
executable code (see numpy.core.defmatrix.bmat for an example) in
their current form. Should these examples have the ">>>" removed from
them to avoid them being picked up as doctests?
Thanks,
Alan
__
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
un 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 w
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
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, a
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 unittes
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 for
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 cover
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
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 th
On Wed, Jun 18, 2008 at 4:15 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> We've been already been making that warning for some time now, in the
> proper venues. warning.warn() is good for DeprecationWarnings, but not
> this. We are good to go for nose being used in 1.2.
Ok, so somebody tell me if
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
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
>
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.
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 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 t
1 - 100 of 137 matches
Mail list logo
