Re: [Numpy-discussion] 1.8.1rc1 on sourceforge.

2014-03-11 Thread Matthew Brett
Hi,

On Mon, Mar 10, 2014 at 11:09 AM, Ralf Gommers ralf.gomm...@gmail.com wrote:



 On Sat, Mar 8, 2014 at 10:06 PM, Matthew Brett matthew.br...@gmail.com
 wrote:

 Hi,

 Thanks to Chuck and Jarrod for giving me upload permission - wheels
 are on sourceforge now:

 https://sourceforge.net/projects/numpy/files/NumPy/1.8.1rc1


 Nice!


 Until the wheels reach pypi, you'll have to test by:


 If you send me your pypi username I'll give you the right permissions there
 also.

Thanks - that would be great  - 'matthew.brett' on pypi.

Cheers,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] c api deprecations with NPY_NO_DEPRECATED_API

2014-03-11 Thread Paul Brossier
On 08/03/2014 19:25, Charles R Harris wrote:
 

Thanks for your quick reply Charles.

 On Sat, Mar 8, 2014 at 2:54 PM, Paul Brossier p...@piem.org
 mailto:p...@piem.org wrote:
 
2. When defining NPY_NO_DEPRECATED_API, as mentioned in the above
warning and in the documentation, I get this error:
 
#error Should never include npy_deprecated_api directly.

ok, this error was triggered by some older version of numpy,
1.8.0.dev-4600b2f-20130131. updating to 1.8.0 fixed it.

sorry for the noise!

The extension i'm trying to improve is aubio and can be found at
http://aubio.org. A copy of the relevant code is at:
 
https://github.com/piem/aubio/blob/develop/python/ext/aubio-types.h
 
 
 You should include the same files whether or not NPY_NO_DEPRECATED_API
 is defined. Usually  numpy/arrayobject.h is the only needed include
 file. For instance, fftpack_litemodule.c has at the top
 
 #define NPY_NO_DEPRECATED_API NPY_API_VERSION
 
 #include fftpack.h
 #include Python.h
 #include numpy/arrayobject.h

Yes, that's pretty much what I do in aubio.

 Where in this case  NPY_API_VERSION is the current version,
 NPY_1_7_API_VERSION would be the numpy1.7.x API, etc. You use the
 version you intend to support and things deprecated after that version
 will still be available to you.

If I understand correctly, the current version is the one installed on
the user system. So using NPY_API_VERSION would mean this code should
work with any version of numpy. I guess this is what I want (I would
even expect this to be the default setting). Did I miss something?

Thanks, Paul
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] c api deprecations with NPY_NO_DEPRECATED_API

2014-03-11 Thread Nathaniel Smith
On 11 Mar 2014 13:28, Paul Brossier p...@piem.org wrote:
 If I understand correctly, the current version is the one installed on
 the user system. So using NPY_API_VERSION would mean this code should
 work with any version of numpy. I guess this is what I want (I would
 even expect this to be the default setting). Did I miss something?

Using NPY_API_VERSION here means this code will work with any version of
numpy, *including ones that aren't released yet and might have arbitrary
API changes*.

This is almost certainly not what you want.

The idea of the deprecation support is that it gives you a grace period to
adapt to upcoming changes before they break your code. Suppose PyArray_foo
is going to be removed in numpy 1.10. If we just removed it, your first
warning would be when we release 1.10 and suddenly you have angry users who
find your software no longer works. So the trick is that before we remove
it entirely, we release 1.9, in which PyArray_foo is available if your
NPY_DEPRECATED_API version is set to 1.8 or earlier, but not if it's set to
1.9. Your released versions thus continue to work, your users are happy,
and the first person to encounter the problem is you, when you try to
update your NPY_DEPRECATED_API to 1.9. You fix the problem, you make a new
release, and then when 1.10 comes along everything works.

Moral: set NPY_DEPRECATED_API to match the highest numpy version you've
tested.

-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] c api deprecations with NPY_NO_DEPRECATED_API

2014-03-11 Thread Paul Brossier
On 11/03/2014 10:49, Nathaniel Smith wrote:
 On 11 Mar 2014 13:28, Paul Brossier p...@piem.org
 mailto:p...@piem.org wrote:
 If I understand correctly, the current version is the one installed on
 the user system. So using NPY_API_VERSION would mean this code should
 work with any version of numpy. I guess this is what I want (I would
 even expect this to be the default setting). Did I miss something?
 
 Using NPY_API_VERSION here means this code will work with any version
 of numpy, *including ones that aren't released yet and might have
 arbitrary API changes*.
 
 This is almost certainly not what you want.

Thanks for the clarification.

 The idea of the deprecation support is that it gives you a grace period
 to adapt to upcoming changes before they break your code. Suppose
 PyArray_foo is going to be removed in numpy 1.10. If we just removed it,
 your first warning would be when we release 1.10 and suddenly you have
 angry users who find your software no longer works. So the trick is that
 before we remove it entirely, we release 1.9, in which PyArray_foo is
 available if your NPY_DEPRECATED_API version is set to 1.8 or earlier,
 but not if it's set to 1.9. Your released versions thus continue to
 work, your users are happy, and the first person to encounter the
 problem is you, when you try to update your NPY_DEPRECATED_API to 1.9.
 You fix the problem, you make a new release, and then when 1.10 comes
 along everything works.
 
 Moral: set NPY_DEPRECATED_API to match the highest numpy version you've
 tested.

I guess you meant NPY_NO_DEPRECATED_API?

Paul
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] c api deprecations with NPY_NO_DEPRECATED_API

2014-03-11 Thread Nathaniel Smith
On 11 Mar 2014 14:25, Paul Brossier p...@piem.org wrote:

 On 11/03/2014 10:49, Nathaniel Smith wrote:
  On 11 Mar 2014 13:28, Paul Brossier p...@piem.org
  mailto:p...@piem.org wrote:
  If I understand correctly, the current version is the one installed on
  the user system. So using NPY_API_VERSION would mean this code should
  work with any version of numpy. I guess this is what I want (I would
  even expect this to be the default setting). Did I miss something?
 
  Using NPY_API_VERSION here means this code will work with any version
  of numpy, *including ones that aren't released yet and might have
  arbitrary API changes*.
 
  This is almost certainly not what you want.

 Thanks for the clarification.

  The idea of the deprecation support is that it gives you a grace period
  to adapt to upcoming changes before they break your code. Suppose
  PyArray_foo is going to be removed in numpy 1.10. If we just removed it,
  your first warning would be when we release 1.10 and suddenly you have
  angry users who find your software no longer works. So the trick is that
  before we remove it entirely, we release 1.9, in which PyArray_foo is
  available if your NPY_DEPRECATED_API version is set to 1.8 or earlier,
  but not if it's set to 1.9. Your released versions thus continue to
  work, your users are happy, and the first person to encounter the
  problem is you, when you try to update your NPY_DEPRECATED_API to 1.9.
  You fix the problem, you make a new release, and then when 1.10 comes
  along everything works.
 
  Moral: set NPY_DEPRECATED_API to match the highest numpy version you've
  tested.

 I guess you meant NPY_NO_DEPRECATED_API?

Yes. I'm just too lazy to check these things on my phone :-).

-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] 2014 John Hunter Fellowship - Call for Applications

2014-03-11 Thread Ralf Gommers
Hi all,

I'm excited to announce, on behalf of the Numfocus board, that applications
for the
2014 John Hunter Technology Fellowship are now being accepted. This is the
first
fellowship Numfocus is able to offer, which we see as a significant
milestone.

The John Hunter Technology Fellowship aims to bridge the gap between
academia and real-world, open-source scientific computing projects by
providing
a capstone experience for individuals coming from a scientific, engineering
or
mathematics background.

The program consists of a 6 month project-based training program
for postdoctoral scientists or senior graduate students. Fellows work on
scientific computing open source projects under the guidance of mentors who
are
leading scientists and software engineers. The aim of the Fellowship is to
enable Fellows to develop the skills needed to contribute to cutting-edge
open
source software projects while at the same time advancing or supporting the
research program they and their mentor are involved in.

While proposals in any area of science and engineering are welcome, the
following areas are encouraged in particular:

  - Accessible and reproducible computing
  - Enabling technology for open access publishing
  - Infrastructural technology supporting open-source scientific software
stacks
  - Core open-source projects promoted by NumFOCUS

Eligible applicants are postdoctoral scientists or senior PhD students,
or have equivalent experience in physics, mathematics, engineering,
statistics,
or a related science. The program is open to applicants from any nationality
and can be performed at any university or institute world-wide (US export
laws permitting).

All applications are due May 15, 2014 by 11:59 p.m. Central Standard Time.

For more details on the program see:
http://numfocus.org/john_hunter_fellowship_2014.html (this call)
http://numfocus.org/fellowships.html (program)

And for some background see this blog post:
http://numfocus.org/announcing-the-numfocus-technology-fellowship-program.html

We're looking forward to receiving your applications!

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] 1.8.1rc1 on sourceforge.

2014-03-11 Thread Ralf Gommers
On Tue, Mar 11, 2014 at 9:26 AM, Matthew Brett matthew.br...@gmail.comwrote:

 Hi,

 On Mon, Mar 10, 2014 at 11:09 AM, Ralf Gommers ralf.gomm...@gmail.com
 wrote:
 
 
 
  On Sat, Mar 8, 2014 at 10:06 PM, Matthew Brett matthew.br...@gmail.com
  wrote:
 
  Hi,
 
  Thanks to Chuck and Jarrod for giving me upload permission - wheels
  are on sourceforge now:
 
  https://sourceforge.net/projects/numpy/files/NumPy/1.8.1rc1
 
 
  Nice!
 
 
  Until the wheels reach pypi, you'll have to test by:
 
 
  If you send me your pypi username I'll give you the right permissions
 there
  also.

 Thanks - that would be great  - 'matthew.brett' on pypi.


You're a numpy admin now. Thanks for picking this up, will be quite useful
in the long run!

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion