Re: [Numpy-discussion] NumPy 1.12.0b1 released

2016-11-18 Thread Nathaniel Smith
On Nov 18, 2016 01:14, "Ralf Gommers"  wrote:
>
>
>
> On Fri, Nov 18, 2016 at 9:08 PM, Matthew Brett 
wrote:
>>
>> Hi,
>>
>> On Thu, Nov 17, 2016 at 3:24 PM, Matti Picus 
wrote:
>> > Congrats to all on the release.Two questions:
>> >
>> > Is there a guide to building standard wheels for NumPy?
>>
>> I don't think so - there is a repository that we use to build the
>> wheels, that has the Windows, OSX and manyllinux recipes for the
>> standard CPython build:
>>
>> https://github.com/MacPython/numpy-wheelso
>>
>> If you can work out a way to automate the PyPy builds and tests -
>> especially using the same repo - that would be very useful.
>>
>> > Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and
>> > OSX64, how can I get them blessed and uploaded to PyPI?
>>
>> If you can automate the build and tests, I'm guessing there will be no
>> objections - but it's not my call...
>
>
> I'm in favor, assuming that the wheel tags and PyPy backwards
compatibility situation is OK. Can't really find any examples. What I mean
is that for CPython wheels contain tags like "cp27" or "cp35". PyPy wheels
should have tags "pp". Are the PyPy cpyext layer and the
 defined such that a new PyPy release won't break older wheels?

Another thing to think about is that 1.12 on pypy won't pass its test suite
(though it's close), and we're not yet testing new PRs on pypy, so no
guarantees about 1.13 yet. I think on balance these probably aren't reasons
*not* to upload wheels, but it's a funny place where we're talking about
providing "official" builds even though it's not an "officially supported
platform". So we will at least want to be clear about that. And someone
will have to handle the bug reports about the test suite failing :-).

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


Re: [Numpy-discussion] NumPy 1.12.0b1 released

2016-11-18 Thread Peter Cock
Thanks Nathan,

That makes sense (compile using the oldest version of NumPy
we wish to support).

The information on https://github.com/MacPython/numpy-wheels
will probably be very useful too (I've been meaning to try out
appveyor at some point for Windows builds/testing).

Regards,

Peter

On Fri, Nov 18, 2016 at 2:46 PM, Nathan Goldbaum  wrote:
> Since the NumPy API is forwards compatible, you should use the oldest
> version of NumPy you would like to support to build your wheels with. The
> wheels will then work with any future NumPy versions.
>
> On Fri, Nov 18, 2016 at 9:30 AM Peter Cock 
> wrote:
>>
>> I have a related question to Matti's,
>>
>> Do you have any recommendations for building standard wheels
>> for 3rd party Python libraries which use both the NumPy Python
>> and C API?
>>
>> e.g. Do we need to do anything special given the NumPy C API
>> itself is versioned? Does it matter compiler chain should we use?
>>
>> Thanks
>>
>> Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] NumPy 1.12.0b1 released

2016-11-18 Thread Nathan Goldbaum
Since the NumPy API is forwards compatible, you should use the oldest
version of NumPy you would like to support to build your wheels with. The
wheels will then work with any future NumPy versions.

On Fri, Nov 18, 2016 at 9:30 AM Peter Cock 
wrote:

> I have a related question to Matti's,
>
> Do you have any recommendations for building standard wheels
> for 3rd party Python libraries which use both the NumPy Python
> and C API?
>
> e.g. Do we need to do anything special given the NumPy C API
> itself is versioned? Does it matter compiler chain should we use?
>
> Thanks
>
> Peter
>
> On Thu, Nov 17, 2016 at 11:24 PM, Matti Picus 
> wrote:
> > Congrats to all on the release.Two questions:
> >
> > Is there a guide to building standard wheels for NumPy?
> >
> > Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and
> > OSX64, how can I get them blessed and uploaded to PyPI?
> >
> > Matti
> >
> >
> > On 17/11/16 07:47, numpy-discussion-requ...@scipy.org wrote:
> >>
> >> Date: Wed, 16 Nov 2016 22:47:39 -0700
> >> From: Charles R Harris
> >> To: numpy-discussion, SciPy Users List
> >> ,  SciPy Developers
> >> List,
> >> python-announce-l...@python.org
> >> Subject: [Numpy-discussion] NumPy 1.12.0b1 released.
> >>
> >> Hi All,
> >>
> >> I'm pleased to annouce the release of NumPy 1.12.0b1. This release
> >> supports  Python 2.7 and 3.4 - 3.6 and is the result of 388 pull
> requests
> >> submitted by 133 contributors. It is quite sizeable and rather than put
> >> the
> >> release notes inline I've attached them as a file and they may also be
> >> viewed at Github<https://github.com/numpy/numpy/releases/tag/v1.12.0b1
> >.
> >> Zip files and tarballs may also be found the Github link. Wheels and
> >> source
> >> archives may be downloaded from PyPI, which is the recommended method.
> >>
> >> This release is a large collection of fixes, enhancements, and
> >> improvements
> >> and it is difficult to select just a few as highlights. However, the
> >> following enhancements may be of particular interest
> >>
> >> - Order of operations in ``np.einsum`` now can be optimized for
> large
> >> speed improvements.
> >> - New ``signature`` argument to ``np.vectorize`` for vectorizing
> with
> >> core dimensions.
> >> - The ``keepdims`` argument was added to many functions.
> >> - Support for PyPy 2.7 v5.6.0 has been added. While not complete,
> this
> >> is a milestone for PyPy's C-API compatibility layer.
> >>
> >> Thanks to all,
> >>
> >> Chuck
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] NumPy 1.12.0b1 released

2016-11-18 Thread Peter Cock
I have a related question to Matti's,

Do you have any recommendations for building standard wheels
for 3rd party Python libraries which use both the NumPy Python
and C API?

e.g. Do we need to do anything special given the NumPy C API
itself is versioned? Does it matter compiler chain should we use?

Thanks

Peter

On Thu, Nov 17, 2016 at 11:24 PM, Matti Picus  wrote:
> Congrats to all on the release.Two questions:
>
> Is there a guide to building standard wheels for NumPy?
>
> Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and
> OSX64, how can I get them blessed and uploaded to PyPI?
>
> Matti
>
>
> On 17/11/16 07:47, numpy-discussion-requ...@scipy.org wrote:
>>
>> Date: Wed, 16 Nov 2016 22:47:39 -0700
>> From: Charles R Harris
>> To: numpy-discussion, SciPy Users List
>> ,  SciPy Developers
>> List,
>>     python-announce-l...@python.org
>> Subject: [Numpy-discussion] NumPy 1.12.0b1 released.
>>
>> Hi All,
>>
>> I'm pleased to annouce the release of NumPy 1.12.0b1. This release
>> supports  Python 2.7 and 3.4 - 3.6 and is the result of 388 pull requests
>> submitted by 133 contributors. It is quite sizeable and rather than put
>> the
>> release notes inline I've attached them as a file and they may also be
>> viewed at Github<https://github.com/numpy/numpy/releases/tag/v1.12.0b1>.
>> Zip files and tarballs may also be found the Github link. Wheels and
>> source
>> archives may be downloaded from PyPI, which is the recommended method.
>>
>> This release is a large collection of fixes, enhancements, and
>> improvements
>> and it is difficult to select just a few as highlights. However, the
>> following enhancements may be of particular interest
>>
>> - Order of operations in ``np.einsum`` now can be optimized for large
>> speed improvements.
>> - New ``signature`` argument to ``np.vectorize`` for vectorizing with
>> core dimensions.
>> - The ``keepdims`` argument was added to many functions.
>> - Support for PyPy 2.7 v5.6.0 has been added. While not complete, this
>> is a milestone for PyPy's C-API compatibility layer.
>>
>> Thanks to all,
>>
>> Chuck
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] NumPy 1.12.0b1 released

2016-11-18 Thread Ralf Gommers
On Fri, Nov 18, 2016 at 9:08 PM, Matthew Brett 
wrote:

> Hi,
>
> On Thu, Nov 17, 2016 at 3:24 PM, Matti Picus 
> wrote:
> > Congrats to all on the release.Two questions:
> >
> > Is there a guide to building standard wheels for NumPy?
>
> I don't think so - there is a repository that we use to build the
> wheels, that has the Windows, OSX and manyllinux recipes for the
> standard CPython build:
>
> https://github.com/MacPython/numpy-wheelso
>
> If you can work out a way to automate the PyPy builds and tests -
> especially using the same repo - that would be very useful.
>
> > Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and
> > OSX64, how can I get them blessed and uploaded to PyPI?
>
> If you can automate the build and tests, I'm guessing there will be no
> objections - but it's not my call...
>

I'm in favor, assuming that the wheel tags and PyPy backwards compatibility
situation is OK. Can't really find any examples. What I mean is that for
CPython wheels contain tags like "cp27" or "cp35". PyPy wheels should have
tags "pp". Are the PyPy cpyext layer and the  defined
such that a new PyPy release won't break older wheels?

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


Re: [Numpy-discussion] NumPy 1.12.0b1 released

2016-11-18 Thread Matthew Brett
Hi,

On Thu, Nov 17, 2016 at 3:24 PM, Matti Picus  wrote:
> Congrats to all on the release.Two questions:
>
> Is there a guide to building standard wheels for NumPy?

I don't think so - there is a repository that we use to build the
wheels, that has the Windows, OSX and manyllinux recipes for the
standard CPython build:

https://github.com/MacPython/numpy-wheelso

If you can work out a way to automate the PyPy builds and tests -
especially using the same repo - that would be very useful.

> Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and
> OSX64, how can I get them blessed and uploaded to PyPI?

If you can automate the build and tests, I'm guessing there will be no
objections - but it's not my call...

Cheers,

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


Re: [Numpy-discussion] NumPy 1.12.0b1 released

2016-11-17 Thread Matti Picus

Congrats to all on the release.Two questions:

Is there a guide to building standard wheels for NumPy?

Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and 
OSX64, how can I get them blessed and uploaded to PyPI?


Matti


On 17/11/16 07:47, numpy-discussion-requ...@scipy.org wrote:

Date: Wed, 16 Nov 2016 22:47:39 -0700
From: Charles R Harris
To: numpy-discussion, SciPy Users List
,  SciPy Developers List,
python-announce-l...@python.org
Subject: [Numpy-discussion] NumPy 1.12.0b1 released.

Hi All,

I'm pleased to annouce the release of NumPy 1.12.0b1. This release
supports  Python 2.7 and 3.4 - 3.6 and is the result of 388 pull requests
submitted by 133 contributors. It is quite sizeable and rather than put the
release notes inline I've attached them as a file and they may also be
viewed at Github<https://github.com/numpy/numpy/releases/tag/v1.12.0b1>.
Zip files and tarballs may also be found the Github link. Wheels and source
archives may be downloaded from PyPI, which is the recommended method.

This release is a large collection of fixes, enhancements, and improvements
and it is difficult to select just a few as highlights. However, the
following enhancements may be of particular interest

- Order of operations in ``np.einsum`` now can be optimized for large
speed improvements.
- New ``signature`` argument to ``np.vectorize`` for vectorizing with
core dimensions.
- The ``keepdims`` argument was added to many functions.
- Support for PyPy 2.7 v5.6.0 has been added. While not complete, this
is a milestone for PyPy's C-API compatibility layer.

Thanks to all,

Chuck


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


[Numpy-discussion] NumPy 1.12.0b1 released.

2016-11-16 Thread Charles R Harris
Hi All,

I'm pleased to annouce the release of NumPy 1.12.0b1. This release
supports  Python 2.7 and 3.4 - 3.6 and is the result of 388 pull requests
submitted by 133 contributors. It is quite sizeable and rather than put the
release notes inline I've attached them as a file and they may also be
viewed at Github .
Zip files and tarballs may also be found the Github link. Wheels and source
archives may be downloaded from PyPI, which is the recommended method.

This release is a large collection of fixes, enhancements, and improvements
and it is difficult to select just a few as highlights. However, the
following enhancements may be of particular interest

   - Order of operations in ``np.einsum`` now can be optimized for large
   speed improvements.
   - New ``signature`` argument to ``np.vectorize`` for vectorizing with
   core dimensions.
   - The ``keepdims`` argument was added to many functions.
   - Support for PyPy 2.7 v5.6.0 has been added. While not complete, this
   is a milestone for PyPy's C-API compatibility layer.

Thanks to all,

Chuck
NumPy 1.12.0 Release Notes
**

This release supports Python 2.7 and 3.4 - 3.6.

Highlights
==

* Order of operations in ``np.einsum`` now can be optimized for large speed improvements.
* New ``signature`` argument to ``np.vectorize`` for vectorizing with core dimensions.
* The ``keepdims`` argument was added to many functions.

Dropped Support
===

* Support for Python 2.6, 3.2, and 3.3 has been dropped.


Added Support
=

* Support for PyPy 2.7 v5.6.0 has been added. While not complete (nditer
  ``updateifcopy`` is not supported yet), this is a milestone for PyPy's
  C-API compatibility layer.


Build System Changes


* Library order is preserved, instead of being reordered to match that of
  the directories.


Deprecations


Assignment of ndarray object's ``data`` attribute
~
Assigning the 'data' attribute is an inherently unsafe operation as pointed
out in gh-7083. Such a capability will be removed in the future.

Unsafe int casting of the num attribute in ``linspace``
~~~
``np.linspace`` now raises DeprecationWarning when num cannot be safely
interpreted as an integer.

Insufficient bit width parameter to ``binary_repr``
~~~
If a 'width' parameter is passed into ``binary_repr`` that is insufficient to
represent the number in base 2 (positive) or 2's complement (negative) form,
the function used to silently ignore the parameter and return a representation
using the minimal number of bits needed for the form in question. Such behavior
is now considered unsafe from a user perspective and will raise an error in the
future.


Future Changes
==

* In 1.13 NAT will always compare False except for ``NAT != NAT``,
  which will be True.  In short, NAT will behave like NaN
* In 1.13 np.average will preserve subclasses, to match the behavior of most
  other numpy functions such as np.mean. In particular, this means calls which
  returned a scalar may return a 0-d subclass object instead.

Multiple-field manipulation of structured arrays

In 1.13 the behavior of structured arrays involving multiple fields will change
in two ways:

First, indexing a structured array with multiple fields (eg,
``arr[['f1', 'f3']]``) will return a view into the original array in 1.13,
instead of a copy. Note the returned view will have extra padding bytes
corresponding to intervening fields in the original array, unlike the copy in
1.12, which will affect code such as ``arr[['f1', 'f3']].view(newdtype)``.

Second, for numpy versions 1.6 to 1.12 assignment between structured arrays
occurs "by field name": Fields in the destination array are set to the
identically-named field in the source array or to 0 if the source does not have
a field::

>>> a = np.array([(1,2),(3,4)], dtype=[('x', 'i4'), ('y', 'i4')])
>>> b = np.ones(2, dtype=[('z', 'i4'), ('y', 'i4'), ('x', 'i4')])
>>> b[:] = a
>>> b
array([(0, 2, 1), (0, 4, 3)],
  dtype=[('z', '`. This allows
for vectorizing a much broader class of functions. For example, an arbitrary
distance metric that combines two vectors to produce a scalar could be
vectorized with ``signature='(n),(n)->()'``. See ``np.vectorize`` for full
details.

Emit py3kwarnings for division of integer arrays

To help people migrate their code bases from Python 2 to Python 3, the
python interpreter has a handy option -3, which issues warnings at runtime.
One of its warnings is for integer division::

$ python -3 -c "2/3"

-c:1: DeprecationWarning: classic int division

In Python 3, the new integer division semantics also apply to numpy arrays.
With t