Skip to content

1.7.x backport #472

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Oct 1, 2012
Merged

1.7.x backport #472

merged 10 commits into from
Oct 1, 2012

Conversation

certik
Copy link
Contributor

@certik certik commented Sep 30, 2012

This backports issues
#420
#451
#440
#449

seberg and others added 7 commits September 30, 2012 13:53
1) New function assert_no_warnings
2) Make assert_warns and assert_no_warnings pass through the
   function's return value on success, so that it can be checked as
   well.
In numpy 1.6 and earlier, if you do
  np.add(int_arr, float_arr, out=int_arr)
or
  int_arr += float_arr
then the result will be silently truncated to integer values. This
often produces bugs, because it's easy to accidentally end up with an
integer array and not realize it.

Therefore, there seems to be consensus that we should switch to using
same_kind casting by default for in-place ufunc operations. However,
just switching this (as was done initially during the 1.7 development
cycle) breaks a lot of code, which is rude and violates our
deprecation policy.

This commit instead adds a special temporary casting rule which acts
like "unsafe", but also checks whether each operation would be allowed
under "same_kind" rules and issues a DeprecationWarning if not.

It also moves NPY_DEFAULT_ASSIGN_CASTING into the formal API instead
of leaving it as a #define. This way we can change it later, and any
code which references it and is compiled against this version of numpy
will automatically switch to whatever we change it too. This avoids
the situation where we want to remove the temporary magic value we're
using to create DeprecationWarnings now, but can't because it would be
an ABI break.
@njsmith
Copy link
Member

njsmith commented Sep 30, 2012

Test failures are real -- you seem to have missed an import somewhere.

@njsmith
Copy link
Member

njsmith commented Sep 30, 2012

The list of issues being backported looks good to me too, though.

@certik
Copy link
Contributor Author

certik commented Sep 30, 2012

I see, I had to manually fix some conflicts in "BUG: allow any axis for np.concatenate for 1D" and I missed this import. I rebased the fix into this commit, so let's see what happens now.

@certik
Copy link
Contributor Author

certik commented Oct 1, 2012

Ok, another thing I forgot. I just pushed in a patch fixing it, and if it works, I'll rebase it once again.

@certik
Copy link
Contributor Author

certik commented Oct 1, 2012

Ok, works. Let me rebase it.

Previous numpies allowed the user to pass any integer as axis argument
to np.concatenate, when the input arrays were 1D.  At some point we
tightened up on this, raising an error for axis values other than 0.
This raises a FutureWarning for axis numbers != 0, but allows them, for
backwards compatibility.

Conflicts:

	numpy/core/tests/test_shape_base.py
Use of PyErr_WarnEx causing failure for Python 2.4.
From review by Nathaniel - thanks.
certik added a commit that referenced this pull request Oct 1, 2012
@certik certik merged commit 86fbf95 into numpy:maintenance/1.7.x Oct 1, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants