Hi, Here are the last open issues for 1.7, there are 9 of them: https://github.com/numpy/numpy/issues?milestone=3&sort=updated&state=open
From these, 3 are very simple PRs that I just posted. Let's polish these, get them in.
I propose to release rc2 after that and if all is ok, do the final release. Some of the issues are not fully addressed, but I don't think we should be holding the release any longer. Let me know if that is ok with you. My apologies for a delay on my side  my son was just born 2 weeks ago and I had to submit an important article, with the deadline yesterday. Things are settled now and I now have time to get this done. Ondrej
On Mon, Feb 4, 2013 at 7:04 AM, Ondřej Čertík <ondrej.certik@gmail.com>wrote:
Hi,
Here are the last open issues for 1.7, there are 9 of them:
https://github.com/numpy/numpy/issues?milestone=3&sort=updated&state=open
From these, 3 are very simple PRs that I just posted. Let's polish these, get them in.
I propose to release rc2 after that and if all is ok, do the final release. Some of the issues are not fully addressed, but I don't think we should be holding the release any longer. Let me know if that is ok with you.
I'm OK with that. None of the issues are hard blockers.
My apologies for a delay on my side  my son was just born 2 weeks ago
Congrats, Ondrej! Ralf
and I had to submit an important article, with the deadline yesterday. Things are settled now and I now have time to get this done.
Ondrej _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On 2/4/13 12:04 AM, Ondřej Čertík wrote:
Hi,
Here are the last open issues for 1.7, there are 9 of them:
https://github.com/numpy/numpy/issues?milestone=3&sort=updated&state=open
Here's something we noticed while working on getting 1.7rc1 into Sage with one of our doctests. With numpy 1.5.1 (we skipped 1.6.x because of backwards compatibility issues...): import numpy as np print np.array([None, None]).any() prints False, but with 1.7.rc1, we get None. For comparison, in Python 2.6.1 and 3.3.0:
any([None,None]) False print None or None None
Was this change between 1.5.1 and 1.7 intentional? Thanks, Jason
On Tue, Feb 5, 2013 at 10:23 PM, Jason Grout <jasonsage@creativetrax.com>wrote:
On 2/4/13 12:04 AM, Ondřej Čertík wrote:
Hi,
Here are the last open issues for 1.7, there are 9 of them:
https://github.com/numpy/numpy/issues?milestone=3&sort=updated&state=open
Here's something we noticed while working on getting 1.7rc1 into Sage with one of our doctests. With numpy 1.5.1 (we skipped 1.6.x because of backwards compatibility issues...):
import numpy as np print np.array([None, None]).any()
prints False, but with 1.7.rc1, we get None.
For comparison, in Python 2.6.1 and 3.3.0:
any([None,None]) False print None or None None
Was this change between 1.5.1 and 1.7 intentional?
Probably not, but maybe yes. I'd guess the cause is lines 26012603 of ufunc_object.c if (PyArray_ISOBJECT(arr) && PyArray_SIZE(arr) != 0) { assign_identity = NULL; } The variable assign_identity is a function pointer, so some new functions are probably needed that return python integers 0 and 1 when PyUFunc_Zero and PyUFunc_One turn up. I don't know what all the consequences of that change would be and it may not be quite so simple. Clearly that code isn't well tested. Chuck
On Tue, Feb 5, 2013 at 11:14 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Tue, Feb 5, 2013 at 10:23 PM, Jason Grout <jasonsage@creativetrax.com>wrote:
On 2/4/13 12:04 AM, Ondřej Čertík wrote:
Hi,
Here are the last open issues for 1.7, there are 9 of them:
https://github.com/numpy/numpy/issues?milestone=3&sort=updated&state=open
Here's something we noticed while working on getting 1.7rc1 into Sage with one of our doctests. With numpy 1.5.1 (we skipped 1.6.x because of backwards compatibility issues...):
import numpy as np print np.array([None, None]).any()
prints False, but with 1.7.rc1, we get None.
For comparison, in Python 2.6.1 and 3.3.0:
any([None,None]) False print None or None None
Was this change between 1.5.1 and 1.7 intentional?
Probably not, but maybe yes. I'd guess the cause is lines 26012603 of ufunc_object.c
if (PyArray_ISOBJECT(arr) && PyArray_SIZE(arr) != 0) { assign_identity = NULL; }
The variable assign_identity is a function pointer, so some new functions are probably needed that return python integers 0 and 1 when PyUFunc_Zero and PyUFunc_One turn up. I don't know what all the consequences of that change would be and it may not be quite so simple. Clearly that code isn't well tested.
Oh, and you do realize Python is insane here. None really shouldn't *have* a logical value, which I suppos
0 or None 1 or None 1 print None or None None
If ndarray.any is equivalent to logical_or.reduce there is no way to make all those work. We will need to special case some things. In fact, in 1.5 logical_or was not defined for object dtypes, so any must have been special cased and the change that has come about is from implementing logical_or for objects and using a reduction. So in 1.5
a = np.array([None, None], dtype='O') np.logical_or(a,a) Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: logical_or a = np.array([1, 1]) np.logical_or(a,a) array([ True, True], dtype=bool)
While in 1.7 In [1]: a = array([None, None]) In [2]: logical_or(a, a) Out[2]: array([None, None], dtype=object) In [3]: logical_or(a, 0) Out[3]: array([0, 0], dtype=object) In [4]: logical_or(a, 1) Out[4]: array([1, 1], dtype=object) Which agrees with python in two out of three. Not bad for dealing with insane inconsistency. And it looks like the changes suggested in the previous post will fix the problem if we decide to do so. Chuck
On 2/6/13 12:46 AM, Charles R Harris wrote:
if we decide to do so
I should mention that we don't really depend on either behavior (we probably should have a better doctest testing for an array of None values anyway), but we noticed the oddity and thought we ought to mention it. So it doesn't matter to us which way the decision goes. Thanks, Jason
On Tue, Feb 5, 2013 at 11:50 PM, Jason Grout <jasonsage@creativetrax.com>wrote:
On 2/6/13 12:46 AM, Charles R Harris wrote:
if we decide to do so
I should mention that we don't really depend on either behavior (we probably should have a better doctest testing for an array of None values anyway), but we noticed the oddity and thought we ought to mention it. So it doesn't matter to us which way the decision goes.
More Python craziness In [6]: print None or 0 0 In [7]: print 0 or None None Numpy any is consistent with python when considered as logical_or.reduce In [13]: print array([0, None]).any() None In [14]: print array([None, 0]).any() 0 This appears to be an __ror__, __or__ inconsistency in python. Note that None possesses neither of those operators. Chuck
On 02/06/2013 08:41 AM, Charles R Harris wrote:
On Tue, Feb 5, 2013 at 11:50 PM, Jason Grout <jasonsage@creativetrax.com <mailto:jasonsage@creativetrax.com>> wrote:
On 2/6/13 12:46 AM, Charles R Harris wrote: > if we decide to do so
I should mention that we don't really depend on either behavior (we probably should have a better doctest testing for an array of None values anyway), but we noticed the oddity and thought we ought to mention it. So it doesn't matter to us which way the decision goes.
More Python craziness
In [6]: print None or 0 0
In [7]: print 0 or None None
To me this seems natural and is just how Python works? I think the rule for "or" is simply "evaluate __nonzero__ of left operand, if it is False, return right operand". The reason is so that you can use it like this: x = get_foo() or get_bar() # if get_foo() returns None # use result of get_bar or def f(x=None): x = x or create_default_x() ... I guess that after the "a if expr else b" was introduced this has become less common. Dag Sverre
Numpy any is consistent with python when considered as logical_or.reduce
In [13]: print array([0, None]).any() None
In [14]: print array([None, 0]).any() 0
This appears to be an __ror__, __or__ inconsistency in python. Note that None possesses neither of those operators.
Chuck
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Wed, 20130206 at 10:18 +0100, Dag Sverre Seljebotn wrote:
On 02/06/2013 08:41 AM, Charles R Harris wrote:
On Tue, Feb 5, 2013 at 11:50 PM, Jason Grout <jasonsage@creativetrax.com <mailto:jasonsage@creativetrax.com>> wrote:
On 2/6/13 12:46 AM, Charles R Harris wrote: > if we decide to do so
I should mention that we don't really depend on either behavior (we probably should have a better doctest testing for an array of None values anyway), but we noticed the oddity and thought we ought to mention it. So it doesn't matter to us which way the decision goes.
More Python craziness
In [6]: print None or 0 0
In [7]: print 0 or None None
To me this seems natural and is just how Python works? I think the rule for "or" is simply "evaluate __nonzero__ of left operand, if it is False, return right operand".
The reason is so that you can use it like this:
Yes, but any() and all() functions in python return forcibly a bool as one would expect. So probably logical_and.reduce and all should simply not be the same thing, at least for objects. Though it is a bit weird that objects do something different from other types, so maybe it would be OK to say that numpy just differs from python here, since I am not sure if you can easily change it for the other types. Regards, Sebastian
x = get_foo() or get_bar() # if get_foo() returns None # use result of get_bar
or
def f(x=None): x = x or create_default_x() ...
I guess that after the "a if expr else b" was introduced this has become less common.
Dag Sverre
Numpy any is consistent with python when considered as logical_or.reduce
In [13]: print array([0, None]).any() None
In [14]: print array([None, 0]).any() 0
This appears to be an __ror__, __or__ inconsistency in python. Note that None possesses neither of those operators.
Chuck
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Wed, Feb 6, 2013 at 4:18 AM, Dag Sverre Seljebotn < d.s.seljebotn@astro.uio.no> wrote:
On 02/06/2013 08:41 AM, Charles R Harris wrote:
On Tue, Feb 5, 2013 at 11:50 PM, Jason Grout <jasonsage@creativetrax.com <mailto:jasonsage@creativetrax.com>>
wrote:
On 2/6/13 12:46 AM, Charles R Harris wrote: > if we decide to do so
I should mention that we don't really depend on either behavior (we probably should have a better doctest testing for an array of None values anyway), but we noticed the oddity and thought we ought to mention it. So it doesn't matter to us which way the decision goes.
More Python craziness
In [6]: print None or 0 0
In [7]: print 0 or None None
To me this seems natural and is just how Python works? I think the rule for "or" is simply "evaluate __nonzero__ of left operand, if it is False, return right operand".
The reason is so that you can use it like this:
x = get_foo() or get_bar() # if get_foo() returns None # use result of get_bar
or
def f(x=None): x = x or create_default_x() ...
And what if the user passes in a zero or an empty string or an empty list, or if the return value from get_foo() is a perfectly valid zero? This is one of the very few things I have disagreed with PEP8, and Python in general about. I can understand implicit casting of numbers to booleans in order to attract the C/C++ crowd (but I don't have to like it), but what was so hard about "x is not None" or "len(x) == 0"? I like my languages explicit. Less magic, more WYSIWYM. Cheers! Ben Root
On 6 February 2013 08:41, Charles R Harris <charlesr.harris@gmail.com> wrote:
More Python craziness
In [6]: print None or 0 0
In [7]: print 0 or None None
Just for clarifying this behaviour: In [1]: print None or 0 0 In [2]: print 0 or None None In [3]: val = 0 or None In [4]: print val None
participants (8)

Benjamin Root

Charles R Harris

Dag Sverre Seljebotn

Daπid

Jason Grout

Ondřej Čertík

Ralf Gommers

Sebastian Berg