Hi,
I was thinking about adding a versioning into the deprecation
related functions. E.g., you could say that one function is deprecated
in version 1.2, but adding a in_version in deprecate. Does anyone have
strong feeling against it ? It should be a transparant change. I would
also like
On Fri, Jun 20, 2008 at 01:29, David Cournapeau
[EMAIL PROTECTED] wrote:
Hi,
I was thinking about adding a versioning into the deprecation
related functions. E.g., you could say that one function is deprecated
in version 1.2, but adding a in_version in deprecate. Does anyone have
strong
Robert Kern wrote:
As long as we keep the policy that DeprecationWarnings last precisely
one minor version, I don't think it really adds any information.
I was not aware of this policy. Obviously, it has no use in that case.
It will be hard to write something generic. The individual
On Fri, Jun 20, 2008 at 01:54, David Cournapeau
[EMAIL PROTECTED] wrote:
Robert Kern wrote:
It will be hard to write something generic. The individual functions
will still have to write code that handles the old arguments anyways,
so all it would do is move the warning message from a
Robert Kern wrote:
I don't see a reason to wrap it in a decorator. It saves no significant
effort.
If the warning is spit out in any case (whether the user uses the
default value or not), and if we don't need versioning, I understand it
is not that useful.
I guess my concern is what do
On Fri, Jun 20, 2008 at 02:15, David Cournapeau
[EMAIL PROTECTED] wrote:
I guess my concern is what do we do with deprecated functions: do we
keep them, for how long ? There are some deprecate in current numpy
which dates back to the pre 1.0 release. Maybe that's not really important.
They
Robert Kern wrote:
They should deprecated for one minor version and then deleted.
Ok, thanks for the clarification. Since I was not aware of this, and did
not see this information on the wiki, I added it in
http://scipy.org/scipy/numpy/wiki/ApiDeprecation. Let me know if there
is something I
Hi Anne,
Thanks for the approach ideas - I'll take a look at this soon to try to
understand it. Currently I'm visiting a LabView-based lab who already
have something that works, and works fast, so I'm being encouraged to
use LabView, but I'd like to show them more of the joys of Python. The
Hi
Is there a reason why the syntax is rand(n,n), but zeros((n,n)) to create an
n*n array? If not, perhaps this could be cleaned up?
Regards,
Izak Marais
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
On Fri, Jun 20, 2008 at 4:28 AM, izak marais [EMAIL PROTECTED] wrote:
Hi
Is there a reason why the syntax is rand(n,n), but zeros((n,n)) to create an
n*n array? If not, perhaps this could be cleaned up?
SciPy's rand() is just a convenience wrapper:
help(rand)
Help on built-in function
I apologise for the horrible spelling mistake in the mail title!
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Hi,
While trying to reproduce some bugs on windows with recent numpy, I
got major failures for the whole test suite, with something related to
numeric not found in numpy\core\__init__.py (__all__ += numeric.__all__
line). Nose crashes because at that line, meaning most of the tests
fail;
I have successfully written several extension modules that use the numpy
CAPI to manipulate numpy arrays. I have to say numpy is great.
I am now having a problem, however, when calling numpy capi functions
when running python embedded in a third party, closed source,
application. It
Lane Brooks wrote:
I have successfully written several extension modules that use the numpy
CAPI to manipulate numpy arrays. I have to say numpy is great.
I am now having a problem, however, when calling numpy capi functions
when running python embedded in a third party, closed source,
David Cournapeau wrote:
Lane Brooks wrote:
I have successfully written several extension modules that use the numpy
CAPI to manipulate numpy arrays. I have to say numpy is great.
I am now having a problem, however, when calling numpy capi functions
when running python embedded in a
Hi,
I am trying to figure the right way of looping throught ndarrays using
Cython, currently. Things seem to have evolved a bit compared to what
some documents on the web claim (eg for i from 0=in does not seem
faster than for i in range(n)). I know there is integration of pex with
cython on the
On Thu, Jun 19, 2008 at 9:18 PM, Fernando Perez [EMAIL PROTECTED] wrote:
On Thu, Jun 19, 2008 at 5:29 PM, Robert Kern [EMAIL PROTECTED] wrote:
I just tested the changes and there seem to be no ill effects. Should
I go ahead and commit it? I'll do it in a single commit with no other
changes
On Fri, Jun 20, 2008 at 11:11 AM, Andrew Straw [EMAIL PROTECTED] wrote:
Fernando Perez wrote:
I verified further by putting the import_array() back into the .pyx
file and indeed:
- i_a() in .pxd - missing from .c file.
- i_a() in .pyx - OK in .c file.
It thus seems that we must keep the
Hi,
As a matter of interest, what is the relationship, if any, between (in Cython)
import numpy
and
cnp.import_array()
Are they initializing different copies of the same thing?
Best,
Matthew
___
Numpy-discussion mailing list
On Fri, Jun 20, 2008 at 02:07:08PM -0500, Robert Kern wrote:
Does somebody have a example of fast looping through ndarrays using
modern Cython idioms?
If you're using normal Python indexing, then that's where all your
time is being spent. You need to grab the actual .data pointer and do
C
Oups, forgot the attachement.
On Fri, Jun 20, 2008 at 09:13:34PM +0200, Gael Varoquaux wrote:
On Fri, Jun 20, 2008 at 02:07:08PM -0500, Robert Kern wrote:
Does somebody have a example of fast looping through ndarrays using
modern Cython idioms?
If you're using normal Python indexing,
On Fri, Jun 20, 2008 at 14:11, Matthew Brett [EMAIL PROTECTED] wrote:
Hi,
As a matter of interest, what is the relationship, if any, between (in Cython)
import numpy
and
cnp.import_array()
Are they initializing different copies of the same thing?
No. import numpy is essentially the
I realise this, but 1659 tests in 8.739s with Nose as opposed to just
over 1000 tests in right around 1 second with the previous test system
means there is some kind of slowdown involved besides just the number
of tests being found. Not that I mind: I'm not looking for blazing
speed when running
On Fri, Jun 20, 2008 at 9:37 AM, David Cournapeau
[EMAIL PROTECTED] wrote:
Robert Kern wrote:
They should deprecated for one minor version and then deleted.
Ok, thanks for the clarification. Since I was not aware of this, and did
not see this information on the wiki, I added it in
On Fri, Jun 20, 2008 at 15:17, Sebastian Haase [EMAIL PROTECTED] wrote:
On Fri, Jun 20, 2008 at 9:37 AM, David Cournapeau
[EMAIL PROTECTED] wrote:
Robert Kern wrote:
They should deprecated for one minor version and then deleted.
Ok, thanks for the clarification. Since I was not aware of
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 6/20/08, Gael Varoquaux [EMAIL PROTECTED] wrote:
I am trying to figure the right way of looping throught ndarrays using
Cython, currently. Things seem to have evolved a bit compared to what
some documents on the web claim (eg for i from 0=in does not seem
faster than for i in range(n)).
Hi
If I specify a fortran compiler when building numpy, does that have
any effect on what is installed? In other words, must I build numpy
against a fortran compiler in order to successfully build and use
extension written in fortran - such as scipy?
Cheers
Adam
On Fri, Jun 20, 2008 at 16:01, Alan McIntyre [EMAIL PROTECTED] wrote:
- 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
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 16:27, Adam Mercer [EMAIL PROTECTED] wrote:
Hi
If I specify a fortran compiler when building numpy, does that have
any effect on what is installed? In other words, must I build numpy
against a fortran compiler in order to successfully build and use
extension written
On Fri, Jun 20, 2008 at 16:35, Alan McIntyre [EMAIL PROTECTED] wrote:
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
On Fri, Jun 20, 2008 at 4:38 PM, Robert Kern [EMAIL PROTECTED] wrote:
No. It just affects the Fortran compiler (if any) used to build numpy.
The only place this might affect you is if you use a LAPACK or BLAS
that needs to be linked with a Fortran compiler. Generally, you don't
have to
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 16:52, Alan McIntyre [EMAIL PROTECTED] wrote:
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
On Fri, Jun 20, 2008 at 3:04 PM, Alan McIntyre [EMAIL PROTECTED] wrote:
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.
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
Howdy,
I made some progress on the issue I mentioned earlier:
http://lists.idyll.org/pipermail/testing-in-python/2008-June/000709.html
As indicated there, a bug report has been filed with Python itself:
http://bugs.python.org/issue3158
But in the meantime, Alan may want to apply the
What should we do about this:
DeprecationWarning: complex divmod(), // and % are deprecated
Note that these functions are not defined in numpy, rather complex numbers
are promoted to python objects and the appropriate method/pyfunction is
called. For fmod this returns an attribute error because
Shouldn't this raise an NotImplementedError exception?
In [7]: type(remainder(complex192(1), complex192(1)))
Out[7]: type 'NotImplementedType'
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
41 matches
Mail list logo
