Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

2016-01-26 Thread Charles R Harris 
On Mon, Jan 25, 2016 at 10:43 PM, Solbrig,Jeremy <
jeremy.solb...@colostate.edu> wrote:

> Hello,
>
> Much of what is below was copied from this stack overflow question.
>
> 
>
> I am attempting to subclass numpy.ma.MaskedArray.  I am currently using
> Python v2.7.10.  The problem discussed below does not occur in Numpy
> v1.9.2, but does occur in all versions of Numpy v1.10.x.
>
> In all versions of Numpy v1.10.x, using mathematical operators on my
> subclass behaves differently than using the analogous ufunc. When using the
> ufunc directly (e.g. np.subtract(arr1, arr2)), __array_prepare__,
> __array_finalize__, and __array_wrap__ are all called as expected, however,
> when using the symbolic operator (e.g. arr1-arr2) only __array_finalize__
> is called. As a consequence, I lose any information stored in arr._optinfo 
> when
> a mathematical operator is used.
>
> Here is a code snippet that illustrates the issue.
>
> #!/bin/env python
> import numpy as npfrom numpy.ma import MaskedArray, nomask
> class InfoArray(MaskedArray):
> def __new__(cls, info=None, data=None, mask=nomask, dtype=None,
> copy=False, subok=True, ndmin=0, fill_value=None,
> keep_mask=True, hard_mask=None, shrink=True, **kwargs):
> obj = super(InfoArray, cls).__new__(cls, data=data, mask=mask,
>   dtype=dtype, copy=copy, subok=subok, ndmin=ndmin,
>   fill_value=fill_value, hard_mask=hard_mask,
>   shrink=shrink, **kwargs)
> obj._optinfo['info'] = info
> return obj
>
> def __array_prepare__(self, out, context=None):
> print '__array_prepare__'
> return super(InfoArray, self).__array_prepare__(out, context)
>
> def __array_wrap__(self, out, context=None):
> print '__array_wrap__'
> return super(InfoArray, self).__array_wrap__(out, context)
>
> def __array_finalize__(self, obj):
> print '__array_finalize__'
> return super(InfoArray, self).__array_finalize__(obj)
> if __name__ == "__main__":
> arr1 = InfoArray('test', data=[1,2,3,4,5,6])
> arr2 = InfoArray(data=[0,1,2,3,4,5])
>
> diff1 = np.subtract(arr1, arr2)
> print diff1._optinfo
>
> diff2 = arr1-arr2
> print diff2._optinfo
>
> If run, the output looks like this:
>
> $ python test_ma_sub.py #Call to np.subtract(arr1, arr2) here
> __array_finalize__
> __array_finalize__
> __array_prepare__
> __array_finalize__
> __array_wrap__
> __array_finalize__{'info': 'test'}#Executing arr1-arr2 here
> __array_finalize__{}
>
> Currently I have simply downgraded to 1.9.2 to solve the problem for
> myself, but have been having difficulty figuring out where the difference
> lies between 1.9.2 and 1.10.0.
>

I don't see a difference between 1.9.2 and 1.10.0 in this test, so I
suspect it is something else. Could you try 1.10.4 to see if the something
else has been fixed?

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

Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

2016-01-26 Thread Charles R Harris 
On Tue, Jan 26, 2016 at 10:11 AM, Charles R Harris <
charlesr.har...@gmail.com> wrote:

>
>
> On Mon, Jan 25, 2016 at 10:43 PM, Solbrig,Jeremy <
> jeremy.solb...@colostate.edu> wrote:
>
>> Hello,
>>
>> Much of what is below was copied from this stack overflow question.
>>
>> 
>>
>> I am attempting to subclass numpy.ma.MaskedArray.  I am currently using
>> Python v2.7.10.  The problem discussed below does not occur in Numpy
>> v1.9.2, but does occur in all versions of Numpy v1.10.x.
>>
>> In all versions of Numpy v1.10.x, using mathematical operators on my
>> subclass behaves differently than using the analogous ufunc. When using the
>> ufunc directly (e.g. np.subtract(arr1, arr2)), __array_prepare__,
>> __array_finalize__, and __array_wrap__ are all called as expected, however,
>> when using the symbolic operator (e.g. arr1-arr2) only
>> __array_finalize__ is called. As a consequence, I lose any information
>> stored in arr._optinfo when a mathematical operator is used.
>>
>> Here is a code snippet that illustrates the issue.
>>
>> #!/bin/env python
>> import numpy as npfrom numpy.ma import MaskedArray, nomask
>> class InfoArray(MaskedArray):
>> def __new__(cls, info=None, data=None, mask=nomask, dtype=None,
>> copy=False, subok=True, ndmin=0, fill_value=None,
>> keep_mask=True, hard_mask=None, shrink=True, **kwargs):
>> obj = super(InfoArray, cls).__new__(cls, data=data, mask=mask,
>>   dtype=dtype, copy=copy, subok=subok, ndmin=ndmin,
>>   fill_value=fill_value, hard_mask=hard_mask,
>>   shrink=shrink, **kwargs)
>> obj._optinfo['info'] = info
>> return obj
>>
>> def __array_prepare__(self, out, context=None):
>> print '__array_prepare__'
>> return super(InfoArray, self).__array_prepare__(out, context)
>>
>> def __array_wrap__(self, out, context=None):
>> print '__array_wrap__'
>> return super(InfoArray, self).__array_wrap__(out, context)
>>
>> def __array_finalize__(self, obj):
>> print '__array_finalize__'
>> return super(InfoArray, self).__array_finalize__(obj)
>> if __name__ == "__main__":
>> arr1 = InfoArray('test', data=[1,2,3,4,5,6])
>> arr2 = InfoArray(data=[0,1,2,3,4,5])
>>
>> diff1 = np.subtract(arr1, arr2)
>> print diff1._optinfo
>>
>> diff2 = arr1-arr2
>> print diff2._optinfo
>>
>> If run, the output looks like this:
>>
>> $ python test_ma_sub.py #Call to np.subtract(arr1, arr2) here
>> __array_finalize__
>> __array_finalize__
>> __array_prepare__
>> __array_finalize__
>> __array_wrap__
>> __array_finalize__{'info': 'test'}#Executing arr1-arr2 here
>> __array_finalize__{}
>>
>> Currently I have simply downgraded to 1.9.2 to solve the problem for
>> myself, but have been having difficulty figuring out where the difference
>> lies between 1.9.2 and 1.10.0.
>>
>
> I don't see a difference between 1.9.2 and 1.10.0 in this test, so I
> suspect it is something else. Could you try 1.10.4 to see if the something
> else has been fixed?
>

Which is to say, it isn't in the calls to prepare, wrap, and finalize. Now
to look in _optinfo.

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

Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

2016-01-26 Thread Solbrig,Jeremy 
Hello Chuck,

I receive the same result with 1.10.4.  I agree that it looks like 
__array_prepare__, __array_finalize__, and __array_wrap__ have not been 
changed.  I’m starting to dig into the source again, but focusing on the 
_MaskedBinaryOperation class to try to understand what is going on there.

Jeremy

From: NumPy-Discussion 
mailto:numpy-discussion-boun...@scipy.org>> 
on behalf of Charles R Harris 
mailto:charlesr.har...@gmail.com>>
Reply-To: Discussion of Numerical Python 
mailto:numpy-discussion@scipy.org>>
Date: Tuesday, January 26, 2016 at 10:17 AM
To: Discussion of Numerical Python 
mailto:numpy-discussion@scipy.org>>
Subject: Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy 
v1.10.X



On Tue, Jan 26, 2016 at 10:11 AM, Charles R Harris 
mailto:charlesr.har...@gmail.com>> wrote:


On Mon, Jan 25, 2016 at 10:43 PM, Solbrig,Jeremy 
mailto:jeremy.solb...@colostate.edu>> wrote:

Hello,



Much of what is below was copied from this stack overflow question.

I am attempting to subclass numpy.ma.MaskedArray.  I am currently using Python 
v2.7.10.  The problem discussed below does not occur in Numpy v1.9.2, but does 
occur in all versions of Numpy v1.10.x.

In all versions of Numpy v1.10.x, using mathematical operators on my subclass 
behaves differently than using the analogous ufunc. When using the ufunc 
directly (e.g. np.subtract(arr1, arr2)), __array_prepare__, __array_finalize__, 
and __array_wrap__ are all called as expected, however, when using the symbolic 
operator (e.g. arr1-arr2) only __array_finalize__ is called. As a consequence, 
I lose any information stored in arr._optinfo when a mathematical operator is 
used.

Here is a code snippet that illustrates the issue.

#!/bin/env pythonimport numpy as np
from numpy.ma import MaskedArray, nomask

class InfoArray(MaskedArray):
def __new__(cls, info=None, data=None, mask=nomask, dtype=None,
copy=False, subok=True, ndmin=0, fill_value=None,
keep_mask=True, hard_mask=None, shrink=True, **kwargs):
obj = super(InfoArray, cls).__new__(cls, data=data, mask=mask,
  dtype=dtype, copy=copy, subok=subok, ndmin=ndmin,
  fill_value=fill_value, hard_mask=hard_mask,
  shrink=shrink, **kwargs)
obj._optinfo['info'] = info
return obj

def __array_prepare__(self, out, context=None):
print '__array_prepare__'
return super(InfoArray, self).__array_prepare__(out, context)

def __array_wrap__(self, out, context=None):
print '__array_wrap__'
return super(InfoArray, self).__array_wrap__(out, context)

def __array_finalize__(self, obj):
print '__array_finalize__'
return super(InfoArray, self).__array_finalize__(obj)if __name__ == 
"__main__":
arr1 = InfoArray('test', data=[1,2,3,4,5,6])
arr2 = InfoArray(data=[0,1,2,3,4,5])

diff1 = np.subtract(arr1, arr2)
print diff1._optinfo

diff2 = arr1-arr2
print diff2._optinfo

If run, the output looks like this:

$ python test_ma_sub.py
#Call to np.subtract(arr1, arr2) here
__array_finalize__
__array_finalize__
__array_prepare__
__array_finalize__
__array_wrap__
__array_finalize__
{'info': 'test'}#Executing arr1-arr2 here
__array_finalize__
{}

Currently I have simply downgraded to 1.9.2 to solve the problem for myself, 
but have been having difficulty figuring out where the difference lies between 
1.9.2 and 1.10.0.

I don't see a difference between 1.9.2 and 1.10.0 in this test, so I suspect it 
is something else. Could you try 1.10.4 to see if the something else has been 
fixed?

Which is to say, it isn't in the calls to prepare, wrap, and finalize. Now to 
look in _optinfo.

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

Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

2016-01-26 Thread Charles R Harris 
On Tue, Jan 26, 2016 at 10:27 AM, Solbrig,Jeremy <
jeremy.solb...@colostate.edu> wrote:

> Hello Chuck,
>
> I receive the same result with 1.10.4.  I agree that it looks like
> __array_prepare__, __array_finalize__, and __array_wrap__ have not been
> changed.  I’m starting to dig into the source again, but focusing on the
> _MaskedBinaryOperation class to try to understand what is going on there.
>
> Jeremy
>
> From: NumPy-Discussion  on behalf of
> Charles R Harris 
> Reply-To: Discussion of Numerical Python 
> Date: Tuesday, January 26, 2016 at 10:17 AM
> To: Discussion of Numerical Python 
> Subject: Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy
> v1.10.X
>
>
>
> On Tue, Jan 26, 2016 at 10:11 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Mon, Jan 25, 2016 at 10:43 PM, Solbrig,Jeremy <
>> jeremy.solb...@colostate.edu> wrote:
>>
>>> Hello,
>>>
>>> Much of what is below was copied from this stack overflow question.
>>>
>>> 
>>>
>>> I am attempting to subclass numpy.ma.MaskedArray.  I am currently using
>>> Python v2.7.10.  The problem discussed below does not occur in Numpy
>>> v1.9.2, but does occur in all versions of Numpy v1.10.x.
>>>
>>> In all versions of Numpy v1.10.x, using mathematical operators on my
>>> subclass behaves differently than using the analogous ufunc. When using the
>>> ufunc directly (e.g. np.subtract(arr1, arr2)), __array_prepare__,
>>> __array_finalize__, and __array_wrap__ are all called as expected, however,
>>> when using the symbolic operator (e.g. arr1-arr2) only
>>> __array_finalize__ is called. As a consequence, I lose any information
>>> stored in arr._optinfo when a mathematical operator is used.
>>>
>>> Here is a code snippet that illustrates the issue.
>>>
>>> #!/bin/env pythonimport numpy as npfrom numpy.ma import MaskedArray, nomask
>>> class InfoArray(MaskedArray):
>>> def __new__(cls, info=None, data=None, mask=nomask, dtype=None,
>>> copy=False, subok=True, ndmin=0, fill_value=None,
>>> keep_mask=True, hard_mask=None, shrink=True, **kwargs):
>>> obj = super(InfoArray, cls).__new__(cls, data=data, mask=mask,
>>>   dtype=dtype, copy=copy, subok=subok, ndmin=ndmin,
>>>   fill_value=fill_value, hard_mask=hard_mask,
>>>   shrink=shrink, **kwargs)
>>> obj._optinfo['info'] = info
>>> return obj
>>>
>>> def __array_prepare__(self, out, context=None):
>>> print '__array_prepare__'
>>> return super(InfoArray, self).__array_prepare__(out, context)
>>>
>>> def __array_wrap__(self, out, context=None):
>>> print '__array_wrap__'
>>> return super(InfoArray, self).__array_wrap__(out, context)
>>>
>>> def __array_finalize__(self, obj):
>>> print '__array_finalize__'
>>> return super(InfoArray, self).__array_finalize__(obj)if __name__ == 
>>> "__main__":
>>> arr1 = InfoArray('test', data=[1,2,3,4,5,6])
>>> arr2 = InfoArray(data=[0,1,2,3,4,5])
>>>
>>> diff1 = np.subtract(arr1, arr2)
>>> print diff1._optinfo
>>>
>>> diff2 = arr1-arr2
>>> print diff2._optinfo
>>>
>>> If run, the output looks like this:
>>>
>>> $ python test_ma_sub.py #Call to np.subtract(arr1, arr2) here
>>> __array_finalize__
>>> __array_finalize__
>>> __array_prepare__
>>> __array_finalize__
>>> __array_wrap__
>>> __array_finalize__{'info': 'test'}#Executing arr1-arr2 here
>>> __array_finalize__{}
>>>
>>> Currently I have simply downgraded to 1.9.2 to solve the problem for
>>> myself, but have been having difficulty figuring out where the difference
>>> lies between 1.9.2 and 1.10.0.
>>>
>>
>> I don't see a difference between 1.9.2 and 1.10.0 in this test, so I
>> suspect it is something else. Could you try 1.10.4 to see if the something
>> else has been fixed?
>>
>
> Which is to say, it isn't in the calls to prepare, wrap, and finalize. Now
> to look in _optinfo.
>
>
Please open an issue on github, the mailing list is not a good place to
deal with this. I've got a bisect script running, so we should soon know
where the change occurred.

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

Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

2016-01-26 Thread Solbrig,Jeremy 
Will do.  Thanks for looking into this!

From: NumPy-Discussion 
mailto:numpy-discussion-boun...@scipy.org>> 
on behalf of Charles R Harris 
mailto:charlesr.har...@gmail.com>>
Reply-To: Discussion of Numerical Python 
mailto:numpy-discussion@scipy.org>>
Date: Tuesday, January 26, 2016 at 10:35 AM
To: Discussion of Numerical Python 
mailto:numpy-discussion@scipy.org>>
Subject: Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy 
v1.10.X



On Tue, Jan 26, 2016 at 10:27 AM, Solbrig,Jeremy 
mailto:jeremy.solb...@colostate.edu>> wrote:
Hello Chuck,

I receive the same result with 1.10.4.  I agree that it looks like 
__array_prepare__, __array_finalize__, and __array_wrap__ have not been 
changed.  I’m starting to dig into the source again, but focusing on the 
_MaskedBinaryOperation class to try to understand what is going on there.

Jeremy

From: NumPy-Discussion 
mailto:numpy-discussion-boun...@scipy.org>> 
on behalf of Charles R Harris 
mailto:charlesr.har...@gmail.com>>
Reply-To: Discussion of Numerical Python 
mailto:numpy-discussion@scipy.org>>
Date: Tuesday, January 26, 2016 at 10:17 AM
To: Discussion of Numerical Python 
mailto:numpy-discussion@scipy.org>>
Subject: Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy 
v1.10.X



On Tue, Jan 26, 2016 at 10:11 AM, Charles R Harris 
mailto:charlesr.har...@gmail.com>> wrote:


On Mon, Jan 25, 2016 at 10:43 PM, Solbrig,Jeremy 
mailto:jeremy.solb...@colostate.edu>> wrote:

Hello,



Much of what is below was copied from this stack overflow question.

I am attempting to subclass numpy.ma.MaskedArray.  I am currently using Python 
v2.7.10.  The problem discussed below does not occur in Numpy v1.9.2, but does 
occur in all versions of Numpy v1.10.x.

In all versions of Numpy v1.10.x, using mathematical operators on my subclass 
behaves differently than using the analogous ufunc. When using the ufunc 
directly (e.g. np.subtract(arr1, arr2)), __array_prepare__, __array_finalize__, 
and __array_wrap__ are all called as expected, however, when using the symbolic 
operator (e.g. arr1-arr2) only __array_finalize__ is called. As a consequence, 
I lose any information stored in arr._optinfo when a mathematical operator is 
used.

Here is a code snippet that illustrates the issue.

#!/bin/env pythonimport numpy as np
from numpy.ma import MaskedArray, nomask

class InfoArray(MaskedArray):
def __new__(cls, info=None, data=None, mask=nomask, dtype=None,
copy=False, subok=True, ndmin=0, fill_value=None,
keep_mask=True, hard_mask=None, shrink=True, **kwargs):
obj = super(InfoArray, cls).__new__(cls, data=data, mask=mask,
  dtype=dtype, copy=copy, subok=subok, ndmin=ndmin,
  fill_value=fill_value, hard_mask=hard_mask,
  shrink=shrink, **kwargs)
obj._optinfo['info'] = info
return obj

def __array_prepare__(self, out, context=None):
print '__array_prepare__'
return super(InfoArray, self).__array_prepare__(out, context)

def __array_wrap__(self, out, context=None):
print '__array_wrap__'
return super(InfoArray, self).__array_wrap__(out, context)

def __array_finalize__(self, obj):
print '__array_finalize__'
return super(InfoArray, self).__array_finalize__(obj)if __name__ == 
"__main__":
arr1 = InfoArray('test', data=[1,2,3,4,5,6])
arr2 = InfoArray(data=[0,1,2,3,4,5])

diff1 = np.subtract(arr1, arr2)
print diff1._optinfo

diff2 = arr1-arr2
print diff2._optinfo

If run, the output looks like this:

$ python test_ma_sub.py
#Call to np.subtract(arr1, arr2) here
__array_finalize__
__array_finalize__
__array_prepare__
__array_finalize__
__array_wrap__
__array_finalize__
{'info': 'test'}#Executing arr1-arr2 here
__array_finalize__
{}

Currently I have simply downgraded to 1.9.2 to solve the problem for myself, 
but have been having difficulty figuring out where the difference lies between 
1.9.2 and 1.10.0.

I don't see a difference between 1.9.2 and 1.10.0 in this test, so I suspect it 
is something else. Could you try 1.10.4 to see if the something else has been 
fixed?

Which is to say, it isn't in the calls to prepare, wrap, and finalize. Now to 
look in _optinfo.


Please open an issue on github, the mailing list is not a good place to deal 
with this. I've got a bisect script running, so we should soon know where the 
change occurred.

Chuck

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

Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

2016-01-26 Thread Sebastian Berg 
On Di, 2016-01-26 at 17:27 +, Solbrig,Jeremy wrote:
> Hello Chuck,
> 
> I receive the same result with 1.10.4.  I agree that it looks like
> __array_prepare__, __array_finalize__, and __array_wrap__ have not
> been changed.  I’m starting to dig into the source again, but
> focusing on the _MaskedBinaryOperation class to try to understand
> what is going on there.
> 

Well, there was definitely a change in that code that will cause this,
i.e. the code block:

if isinstance(b, MaskedArray):
if isinstance(a, MaskedArray):
result._update_from(a)
else:
result._update_from(b)
elif isinstance(a, MaskedArray):
result._update_from(a)

was changed to something like:

masked_result._update_from(result)

My guess is almost that this fixed some other bug (but you should
probably check git blame to see why it was put in). It might be that
_optinfo should be handled more specifically. It seems like a very
weird feature to me though when the info is always copied from the left
operand...

Is _optinfo even *documented* to exist? Because frankly, unless it is
used far more, and the fact that it is hidden away with an underscore,
I am not sure we should prioritize that it would keep working,
considering that I am unsure that it ever did something very elegantly.

- Sebastian



> Jeremy
> 
> From: NumPy-Discussion  on behalf
> of Charles R Harris 
> Reply-To: Discussion of Numerical Python 
> Date: Tuesday, January 26, 2016 at 10:17 AM
> To: Discussion of Numerical Python 
> Subject: Re: [Numpy-discussion] Inconsistent behavior for ufuncs in
> numpy v1.10.X
> 
> 
> 
> On Tue, Jan 26, 2016 at 10:11 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
> > 
> > 
> > On Mon, Jan 25, 2016 at 10:43 PM, Solbrig,Jeremy <
> > jeremy.solb...@colostate.edu> wrote:
> > > Hello,
> > > 
> > > Much of what is below was copied from this stack overflow
> > > question.
> > > I am attempting to subclass numpy.ma.MaskedArray.  I am currently
> > > using Python v2.7.10.  The problem discussed below does not occur
> > > in Numpy v1.9.2, but does occur in all versions of Numpy v1.10.x.
> > > In all versions of Numpy v1.10.x, using mathematical operators on
> > > my subclass behaves differently than using the analogous ufunc.
> > > When using the ufunc directly (e.g. np.subtract(arr1,
> > >  arr2)), __array_prepare__, __array_finalize__, and
> > > __array_wrap__ are all called as expected, however, when using
> > > the symbolic operator (e.g. arr1-arr2) only __array_finalize__ is
> > > called. As a consequence, I lose any information stored in
> > >  arr._optinfo when a mathematical operator is used.
> > > Here is a code snippet that illustrates the issue.
> > > 
> > > #!/bin/env pythonimport numpy as np
> > > from numpy.ma import MaskedArray, nomask
> > > 
> > > class InfoArray(MaskedArray):
> > > def __new__(cls, info=None, data=None, mask=nomask,
> > > dtype=None, 
> > > copy=False, subok=True, ndmin=0, fill_value=None,
> > > keep_mask=True, hard_mask=None, shrink=True,
> > > **kwargs):
> > > obj = super(InfoArray, cls).__new__(cls, data=data,
> > > mask=mask,
> > >   dtype=dtype, copy=copy, subok=subok,
> > > ndmin=ndmin, 
> > >   fill_value=fill_value, hard_mask=hard_mask,
> > >   shrink=shrink, **kwargs)
> > > obj._optinfo['info'] = info
> > > return obj
> > > 
> > > def __array_prepare__(self, out, context=None):
> > > print '__array_prepare__'
> > > return super(InfoArray, self).__array_prepare__(out,
> > > context)
> > > 
> > > def __array_wrap__(self, out, context=None):
> > > print '__array_wrap__'
> > > return super(InfoArray, self).__array_wrap__(out,
> > > context)
> > > 
> > > def __array_finalize__(self, obj):
> > > print '__array_finalize__'
> > > return super(InfoArray, self).__array_finalize__(obj)if
> > > __name__ == "__main__":
> > > arr1 = InfoArray('test', data=[1,2,3,4,5,6])
> > > arr2 = InfoArray(data=[0,1,2,3,4,5])
> > > 
> > > diff1 = np.subtract(arr1, arr2)
> > > print diff1._optinfo
> > > 
> > > diff2 = arr1-arr2
> > > print diff2._optinfo
> > > If run, the output looks like this:
> > > 
> > > $ python test_ma_sub.py 
> > > #Call to np.subtract(arr1, arr2) here
> > > __array_finalize__
> > > __array_finalize__
> > > __array_prepare__
> > > __array_finalize__
> > > __array_wrap__
> > > __array_finalize__
> > > {'info': 'test'}#Executing arr1-arr2 here
> > > __array_finalize__
> > > {}
> > > Currently I have simply downgraded to 1.9.2 to solve the problem
> > > for myself, but have been having difficulty figuring out where
> > > the difference lies between 1.9.2 and 1.10.0.
> > > 
> > I don't see a difference between 1.9.2 and 1.10.0 in this test, so
> > I suspect it is something else. Could you try 1.10.4 to see if the
>

Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

2016-01-26 Thread Solbrig,Jeremy 
The problem isn’t specifically with _optinfo.  _optinfo losing information is 
just a symptom of the fact that __array_prepare__, __array_wrap__, and 
__array_finalize__ do not appear to be working as documented.  So far as I can 
tell, there is no way to access attributes of subclasses when using 
mathematical operators so it is impossible to maintain subclasses that contain 
additional attributes.



On 1/26/16, 10:45 AM, "NumPy-Discussion on behalf of Sebastian Berg" 
 
wrote:

>was changed to something like:
>
>masked_result._update_from(result)
>
>My guess is almost that this fixed some other bug (but you should
>probably check git blame to see why it was put in). It might be that
>_optinfo should be handled more specifically. It seems like a very
>weird feature to me though when the info is always copied from the left
>operand...
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

2016-01-26 Thread Solbrig,Jeremy 
New issue submitted here:  https://github.com/numpy/numpy/issues/7122

I suggest moving this discussion there.



On 1/26/16, 10:49 AM, "NumPy-Discussion on behalf of Solbrig,Jeremy" 
 
wrote:

>The problem isn’t specifically with _optinfo.  _optinfo losing information is 
>just a symptom of the fact that __array_prepare__, __array_wrap__, and 
>__array_finalize__ do not appear to be working as documented.  So far as I can 
>tell, there is no way to access attributes of subclasses when using 
>mathematical operators so it is impossible to maintain subclasses that contain 
>additional attributes.
>
>
>
>On 1/26/16, 10:45 AM, "NumPy-Discussion on behalf of Sebastian Berg" 
> 
>wrote:
>
>>was changed to something like:
>>
>>masked_result._update_from(result)
>>
>>My guess is almost that this fixed some other bug (but you should
>>probably check git blame to see why it was put in). It might be that
>>_optinfo should be handled more specifically. It seems like a very
>>weird feature to me though when the info is always copied from the left
>>operand...
>___
>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] Inconsistent behavior for ufuncs in numpy v1.10.X

2016-01-26 Thread Charles R Harris 
On Tue, Jan 26, 2016 at 10:45 AM, Sebastian Berg  wrote:

> On Di, 2016-01-26 at 17:27 +, Solbrig,Jeremy wrote:
> > Hello Chuck,
> >
> > I receive the same result with 1.10.4.  I agree that it looks like
> > __array_prepare__, __array_finalize__, and __array_wrap__ have not
> > been changed.  I’m starting to dig into the source again, but
> > focusing on the _MaskedBinaryOperation class to try to understand
> > what is going on there.
> >
>
> Well, there was definitely a change in that code that will cause this,
> i.e. the code block:
>
> if isinstance(b, MaskedArray):
> if isinstance(a, MaskedArray):
> result._update_from(a)
> else:
> result._update_from(b)
> elif isinstance(a, MaskedArray):
> result._update_from(a)
>
> was changed to something like:
>
> masked_result._update_from(result)
>

That looks like it, 3c6b6baba, #3907
. That's old...



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

Re: [Numpy-discussion] Appveyor Testing Changes

2016-01-26 Thread Ralf Gommers 
On Tue, Jan 26, 2016 at 2:13 AM, G Young  wrote:

> Ah, yes, that is true.  That point had completely escaped my mind.  In
> light of this, it seems that it's not worth the while then to completely
> switch over to pip + virtualenv.  It's might be better actually to rewrite
> the current Appveyor tests to use environments so that the test suite can
> be expanded, though I'm not sure how prudent that is given how slow
> Appveyor tests run.
>

At the moment Appveyor is already a bit of a bottleneck - it regularly
hasn't started yet when TravisCI is already done. This can be solved via a
paid account, we should seriously consider that when we have a bit more
experience with it (Appveyor tests have been running for less than a month
I think). But it does mean we should go for a sparse test matrix, and use a
more complete one (all Python versions for example) on TravisCI. In the
near future we'll have to add MingwPy test runs to Appveyor. Beyond that
I'm not sure what needs to be added?

Ralf



>
> Greg
>
> On Tue, Jan 26, 2016 at 12:13 AM, Bryan Van de Ven 
> wrote:
>
>>
>> > On Jan 25, 2016, at 5:21 PM, G Young  wrote:
>> >
>> > With regards to testing numpy, both Conda and Pip + Virtualenv work
>> quite well.  I have used both to install master and run unit tests, and
>> both pass with flying colors.  This chart here illustrates my point nicely
>> as well.
>> >
>> > However, I can't seem to find / access Conda installations for slightly
>> older versions of Python (e.g. Python 3.4).  Perhaps this is not much of an
>> issue now with the next release (1.12) being written only for Python 2.7
>> and Python 3.4 - 5.  However, if we were to wind the clock slightly back to
>> when we were testing 2.6 - 7, 3.2 - 5, I feel Conda falls short in being
>> able to test on a variety of Python distributions given the nature of Conda
>> releases.  Maybe that situation is no longer the case now, but in the long
>> term, it could easily happen again.
>>
>> Why do you need the installers? The whole point of conda is to be able to
>> create environments with whatever configuration you need. Just pick the
>> newest installer and use "conda create" from there:
>>
>> bryan@0199-bryanv (git:streaming) ~/work/bokeh/bokeh $ conda create -n
>> py26 python=2.6
>> Fetching package metadata: ..
>> Solving package specifications: ..
>> Package plan for installation in environment
>> /Users/bryan/anaconda/envs/py26:
>>
>> The following packages will be downloaded:
>>
>> package|build
>> ---|-
>> setuptools-18.0.1  |   py26_0 343 KB
>> pip-7.1.0  |   py26_0 1.4 MB
>> 
>>Total: 1.7 MB
>>
>> The following NEW packages will be INSTALLED:
>>
>> openssl:1.0.1k-1
>> pip:7.1.0-py26_0
>> python: 2.6.9-1
>> readline:   6.2-2
>> setuptools: 18.0.1-py26_0
>> sqlite: 3.9.2-0
>> tk: 8.5.18-0
>> zlib:   1.2.8-0
>>
>> Proceed ([y]/n)?
>>
>> ___
>> 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

[Numpy-discussion] Testing warnings

2016-01-26 Thread Sebastian Berg 
Hi all,

so I have been thinking about this a little more, and I do not think
there is a truly nice solution to the python bug:
http://bugs.python.org/issue4180 (does not create problems for new
pythons).

However, I have been so annoyed by trying to test FutureWarnings or
DeprecationWarnings in the past that I want *some* improvement. You can
do quite a lot by adding some new features, but there are also some
limitations.

I think that we must be able to:

 o Filter out warnings on the global test run level.
 o Find all not explicitly filtered warnings during development easily.
 o We should be able to test any (almost any?) warnings, even those
that would be filtered globally.

The next line of considerations for me is, whether we want:

 o To be able to *print* warnings during test runs? (in release mode)
 o Be able to not repeat filtering of globally filtered warnings when
filtering additional warnings in an individual test?
 o Be able to count warnings, but ignore other warnings (not the global
ones, though).
 o Filter warnings by module? (might be hard to impossible)

And one further option:
 o Could we accept that testing warnings is *only* possible reliable in
Python 3.4+? It would however even mean that we have to fully *skip*
tests that would ensure specific warnings to be given.

The first things can be achieved setting all warnings to errors on the
global level and trying to make the local tests as specific specific as
possible. I could go ahead with it. There will likely be some uglier
points, but it should work. They do not require funnier new hacks.

For all I can see, the second bunch of things requires new features
such as in my current PR. So, I want to know whether we can/want to go
ahead with this kind of idea [1].

For me personally, I cannot accept we do not provide the first points.

The second bunch, I would like some of them (I do not know about
printing warnings in release mode?), and skipping tests on Python 2,
seems to me even worse then ugly hacks.
Getting there is a bit uglier (requires a new context manager for all I
see), an I tend to think it is worth the trouble, but I don't think it
is vital.

In other words, I don't care too much about those points, but I want to
get somewhere because I have been bitten often enough by the annoying
and in my opinion simply unacceptable (on python 2) use of "ignore"
warnings filters in tests. The current state makes finding warnings
given in our own tests almost impossible, in the best case they will
have to be fixed much much later when the change actually occurs, in
the worst case we never find our own real bugs.

So where to go? :)

- Sebastian


[1] I need to fix the module filtering point, the module filtering does
not work reliably currently, I think it can be fixed at least 99.5%,
but it is not too pretty (not that the user should notice).



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Numpy 1.11.0b1 is out

2016-01-26 Thread Charles R Harris 
Hi All,

I'm pleased to announce that Numpy 1.11.0b1
 is now
available on sourceforge. This is a source release as the mingw32 toolchain
is broken. Please test it out and report any errors that you discover.
Hopefully we can do better with 1.11.0 than we did with 1.10.0 ;)

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

Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.11.0b1 is out

2016-01-26 Thread Derek Homeier 
Hi Chuck,

> I'm pleased to announce that Numpy 1.11.0b1 is now available on sourceforge. 
> This is a source release as the mingw32 toolchain is broken. Please test it 
> out and report any errors that you discover. Hopefully we can do better with 
> 1.11.0 than we did with 1.10.0 ;)

the tarball seems to be incomplete, hope that does not bode ill ;-)

  adding 
'build/src.macosx-10.10-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h' to 
sources.
executing numpy/core/code_generators/generate_numpy_api.py
error: [Errno 2] No such file or directory: 
'numpy/core/code_generators/../src/multiarray/arraytypes.c.src'

> tar tvf /sw/src/numpy-1.11.0b1.tar.gz |grep arraytypes
>  
-rw-rw-r-- charris/charris   62563 2016-01-21 20:38 
numpy-1.11.0b1/numpy/core/include/numpy/ndarraytypes.h
-rw-rw-r-- charris/charris 981 2016-01-21 20:38 
numpy-1.11.0b1/numpy/core/src/multiarray/arraytypes.h

FWIW, the maintenance/1.11.x branch (there is no tag for the beta?) builds and 
passes all tests with Python 2.7.11
and 3.5.1 on  Mac OS X 10.10.

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

Re: [Numpy-discussion] Appveyor Testing Changes

2016-01-26 Thread G Young 
Perhaps a pip + virtualenv build as well since that's one way that is
mentioned in the online docs for installing source code.  I can't think of
anything else beyond that and what you suggested for the time being.

Greg

On Tue, Jan 26, 2016 at 6:59 PM, Ralf Gommers 
wrote:

>
>
> On Tue, Jan 26, 2016 at 2:13 AM, G Young  wrote:
>
>> Ah, yes, that is true.  That point had completely escaped my mind.  In
>> light of this, it seems that it's not worth the while then to completely
>> switch over to pip + virtualenv.  It's might be better actually to rewrite
>> the current Appveyor tests to use environments so that the test suite can
>> be expanded, though I'm not sure how prudent that is given how slow
>> Appveyor tests run.
>>
>
> At the moment Appveyor is already a bit of a bottleneck - it regularly
> hasn't started yet when TravisCI is already done. This can be solved via a
> paid account, we should seriously consider that when we have a bit more
> experience with it (Appveyor tests have been running for less than a month
> I think). But it does mean we should go for a sparse test matrix, and use a
> more complete one (all Python versions for example) on TravisCI. In the
> near future we'll have to add MingwPy test runs to Appveyor. Beyond that
> I'm not sure what needs to be added?
>
> Ralf
>
>
>
>>
>> Greg
>>
>> On Tue, Jan 26, 2016 at 12:13 AM, Bryan Van de Ven 
>> wrote:
>>
>>>
>>> > On Jan 25, 2016, at 5:21 PM, G Young  wrote:
>>> >
>>> > With regards to testing numpy, both Conda and Pip + Virtualenv work
>>> quite well.  I have used both to install master and run unit tests, and
>>> both pass with flying colors.  This chart here illustrates my point nicely
>>> as well.
>>> >
>>> > However, I can't seem to find / access Conda installations for
>>> slightly older versions of Python (e.g. Python 3.4).  Perhaps this is not
>>> much of an issue now with the next release (1.12) being written only for
>>> Python 2.7 and Python 3.4 - 5.  However, if we were to wind the clock
>>> slightly back to when we were testing 2.6 - 7, 3.2 - 5, I feel Conda falls
>>> short in being able to test on a variety of Python distributions given the
>>> nature of Conda releases.  Maybe that situation is no longer the case now,
>>> but in the long term, it could easily happen again.
>>>
>>> Why do you need the installers? The whole point of conda is to be able
>>> to create environments with whatever configuration you need. Just pick the
>>> newest installer and use "conda create" from there:
>>>
>>> bryan@0199-bryanv (git:streaming) ~/work/bokeh/bokeh $ conda create -n
>>> py26 python=2.6
>>> Fetching package metadata: ..
>>> Solving package specifications: ..
>>> Package plan for installation in environment
>>> /Users/bryan/anaconda/envs/py26:
>>>
>>> The following packages will be downloaded:
>>>
>>> package|build
>>> ---|-
>>> setuptools-18.0.1  |   py26_0 343 KB
>>> pip-7.1.0  |   py26_0 1.4 MB
>>> 
>>>Total: 1.7 MB
>>>
>>> The following NEW packages will be INSTALLED:
>>>
>>> openssl:1.0.1k-1
>>> pip:7.1.0-py26_0
>>> python: 2.6.9-1
>>> readline:   6.2-2
>>> setuptools: 18.0.1-py26_0
>>> sqlite: 3.9.2-0
>>> tk: 8.5.18-0
>>> zlib:   1.2.8-0
>>>
>>> Proceed ([y]/n)?
>>>
>>> ___
>>> 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
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.11.0b1 is out

2016-01-26 Thread Charles R Harris 
On Tue, Jan 26, 2016 at 4:48 PM, Derek Homeier <
de...@astro.physik.uni-goettingen.de> wrote:

> Hi Chuck,
>
> > I'm pleased to announce that Numpy 1.11.0b1 is now available on
> sourceforge. This is a source release as the mingw32 toolchain is broken.
> Please test it out and report any errors that you discover. Hopefully we
> can do better with 1.11.0 than we did with 1.10.0 ;)
>
> the tarball seems to be incomplete, hope that does not bode ill ;-)
>
>   adding
> 'build/src.macosx-10.10-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h'
> to sources.
> executing numpy/core/code_generators/generate_numpy_api.py
> error: [Errno 2] No such file or directory:
> 'numpy/core/code_generators/../src/multiarray/arraytypes.c.src'
>

Grr, yes indeed, `paver sdist` doesn't do the right thing, none of the
`multiarray/*.c.src` files are included, but it works fine in 1.10.x. The
changes are minimal, the only thing that would seem to matter is the
removal of setupegg.py. Ralf, any ideas.


> > tar tvf /sw/src/numpy-1.11.0b1.tar.gz |grep arraytypes
> -rw-rw-r-- charris/charris   62563 2016-01-21 20:38
> numpy-1.11.0b1/numpy/core/include/numpy/ndarraytypes.h
> -rw-rw-r-- charris/charris 981 2016-01-21 20:38
> numpy-1.11.0b1/numpy/core/src/multiarray/arraytypes.h
>
> FWIW, the maintenance/1.11.x branch (there is no tag for the beta?) builds
> and passes all tests with Python 2.7.11
> and 3.5.1 on  Mac OS X 10.10.
>
>
You probably didn't fetch the tags, if they can't be reached from the
branch head they don't download automatically. Try `git fetch --tags
upstream`

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

Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.11.0b1 is out

2016-01-26 Thread Charles R Harris 
On Tue, Jan 26, 2016 at 6:58 PM, Charles R Harris  wrote:

>
>
> On Tue, Jan 26, 2016 at 4:48 PM, Derek Homeier <
> de...@astro.physik.uni-goettingen.de> wrote:
>
>> Hi Chuck,
>>
>> > I'm pleased to announce that Numpy 1.11.0b1 is now available on
>> sourceforge. This is a source release as the mingw32 toolchain is broken.
>> Please test it out and report any errors that you discover. Hopefully we
>> can do better with 1.11.0 than we did with 1.10.0 ;)
>>
>> the tarball seems to be incomplete, hope that does not bode ill ;-)
>>
>>   adding
>> 'build/src.macosx-10.10-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h'
>> to sources.
>> executing numpy/core/code_generators/generate_numpy_api.py
>> error: [Errno 2] No such file or directory:
>> 'numpy/core/code_generators/../src/multiarray/arraytypes.c.src'
>>
>
> Grr, yes indeed, `paver sdist` doesn't do the right thing, none of the
> `multiarray/*.c.src` files are included, but it works fine in 1.10.x. The
> changes are minimal, the only thing that would seem to matter is the
> removal of setupegg.py. Ralf, any ideas.
>
>
>> > tar tvf /sw/src/numpy-1.11.0b1.tar.gz |grep arraytypes
>> -rw-rw-r-- charris/charris   62563 2016-01-21 20:38
>> numpy-1.11.0b1/numpy/core/include/numpy/ndarraytypes.h
>> -rw-rw-r-- charris/charris 981 2016-01-21 20:38
>> numpy-1.11.0b1/numpy/core/src/multiarray/arraytypes.h
>>
>> FWIW, the maintenance/1.11.x branch (there is no tag for the beta?)
>> builds and passes all tests with Python 2.7.11
>> and 3.5.1 on  Mac OS X 10.10.
>>
>>
> You probably didn't fetch the tags, if they can't be reached from the
> branch head they don't download automatically. Try `git fetch --tags
> upstream`
>
>
setupegg.py doesn't seem to matter...

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

Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.11.0b1 is out

2016-01-26 Thread Charles R Harris 
On Tue, Jan 26, 2016 at 7:13 PM, Charles R Harris  wrote:

>
>
> On Tue, Jan 26, 2016 at 6:58 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Tue, Jan 26, 2016 at 4:48 PM, Derek Homeier <
>> de...@astro.physik.uni-goettingen.de> wrote:
>>
>>> Hi Chuck,
>>>
>>> > I'm pleased to announce that Numpy 1.11.0b1 is now available on
>>> sourceforge. This is a source release as the mingw32 toolchain is broken.
>>> Please test it out and report any errors that you discover. Hopefully we
>>> can do better with 1.11.0 than we did with 1.10.0 ;)
>>>
>>> the tarball seems to be incomplete, hope that does not bode ill ;-)
>>>
>>>   adding
>>> 'build/src.macosx-10.10-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h'
>>> to sources.
>>> executing numpy/core/code_generators/generate_numpy_api.py
>>> error: [Errno 2] No such file or directory:
>>> 'numpy/core/code_generators/../src/multiarray/arraytypes.c.src'
>>>
>>
>> Grr, yes indeed, `paver sdist` doesn't do the right thing, none of the
>> `multiarray/*.c.src` files are included, but it works fine in 1.10.x. The
>> changes are minimal, the only thing that would seem to matter is the
>> removal of setupegg.py. Ralf, any ideas.
>>
>>
>>> > tar tvf /sw/src/numpy-1.11.0b1.tar.gz |grep arraytypes
>>> -rw-rw-r-- charris/charris   62563 2016-01-21 20:38
>>> numpy-1.11.0b1/numpy/core/include/numpy/ndarraytypes.h
>>> -rw-rw-r-- charris/charris 981 2016-01-21 20:38
>>> numpy-1.11.0b1/numpy/core/src/multiarray/arraytypes.h
>>>
>>> FWIW, the maintenance/1.11.x branch (there is no tag for the beta?)
>>> builds and passes all tests with Python 2.7.11
>>> and 3.5.1 on  Mac OS X 10.10.
>>>
>>>
>> You probably didn't fetch the tags, if they can't be reached from the
>> branch head they don't download automatically. Try `git fetch --tags
>> upstream`
>>
>>
> setupegg.py doesn't seem to matter...
>
>
OK, it is the changes in the root setup.py file, probably the switch to
setuptools.

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

Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.11.0b1 is out

2016-01-26 Thread Charles R Harris 
On Tue, Jan 26, 2016 at 7:45 PM, Charles R Harris  wrote:

>
>
> On Tue, Jan 26, 2016 at 7:13 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Tue, Jan 26, 2016 at 6:58 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Jan 26, 2016 at 4:48 PM, Derek Homeier <
>>> de...@astro.physik.uni-goettingen.de> wrote:
>>>
 Hi Chuck,

 > I'm pleased to announce that Numpy 1.11.0b1 is now available on
 sourceforge. This is a source release as the mingw32 toolchain is broken.
 Please test it out and report any errors that you discover. Hopefully we
 can do better with 1.11.0 than we did with 1.10.0 ;)

 the tarball seems to be incomplete, hope that does not bode ill ;-)

   adding
 'build/src.macosx-10.10-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h'
 to sources.
 executing numpy/core/code_generators/generate_numpy_api.py
 error: [Errno 2] No such file or directory:
 'numpy/core/code_generators/../src/multiarray/arraytypes.c.src'

>>>
>>> Grr, yes indeed, `paver sdist` doesn't do the right thing, none of the
>>> `multiarray/*.c.src` files are included, but it works fine in 1.10.x. The
>>> changes are minimal, the only thing that would seem to matter is the
>>> removal of setupegg.py. Ralf, any ideas.
>>>
>>>
 > tar tvf /sw/src/numpy-1.11.0b1.tar.gz |grep arraytypes
 -rw-rw-r-- charris/charris   62563 2016-01-21 20:38
 numpy-1.11.0b1/numpy/core/include/numpy/ndarraytypes.h
 -rw-rw-r-- charris/charris 981 2016-01-21 20:38
 numpy-1.11.0b1/numpy/core/src/multiarray/arraytypes.h

 FWIW, the maintenance/1.11.x branch (there is no tag for the beta?)
 builds and passes all tests with Python 2.7.11
 and 3.5.1 on  Mac OS X 10.10.


>>> You probably didn't fetch the tags, if they can't be reached from the
>>> branch head they don't download automatically. Try `git fetch --tags
>>> upstream`
>>>
>>>
>> setupegg.py doesn't seem to matter...
>>
>>
> OK, it is the changes in the root setup.py file, probably the switch to
> setuptools.
>

Yep, it's setuptools. If I import sdist from distutils instead, everything
works fine.

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