8000 DEP: Deprecate random_integers by gfyoung · Pull Request #6931 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

DEP: Deprecate random_integers #6931

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.

Sign up for GitHub

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 1 commit into from
Jan 10, 2016
Merged

DEP: Deprecate random_integers #6931

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 11 additions & 3 deletions doc/release/1.11.0-notes.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -184,15 +184,23 @@ that will not be backward compatible.

Invalid arguments for array ordering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is currently possible to pass in arguments for the ```order```
parameter in methods like ```array.flatten``` or ```array.ravel```
It is currently possible to pass in arguments for the ``order``
parameter in methods like ``array.flatten`` or ``array.ravel``
that were not one of the following: 'C', 'F', 'A', 'K' (note that
all of these possible values are unicode- and case-insensitive).
Such behaviour will not be allowed in future releases.

Random number generator in the ``testing`` namespace
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Python standard library random number generator was previously exposed in the
``testing`` namespace as ``testing.rand``. Using this generator is not
recommended and it will be removed in a future release. Use generators from
``numpy.random`` namespace instead.

Random integer generation on a closed interval
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In accordance with the Python C API, which gives preference to the half-open
interval over the closed one, ``np.random.random_integers`` is being
deprecated in favor of calling ``np.random.randint``, which has been
enhanced with the ``dtype`` parameter as described under "New Features".
However, ``np.random.random_integers`` will not be removed anytime soon.
12 changes: 12 additions & 0 deletions numpy/random/mtrand/mtrand.pyx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1683,6 +1683,10 @@ cdef class RandomState:
type translates to the C long type used by Python 2 for "short"
integers and its precision is platform dependent.

This function has been deprecated. Use randint instead.

.. deprecated:: 1.11.0

Parameters
----------
low : int
Expand Down Expand Up @@ -1748,9 +1752,17 @@ cdef class RandomState:

"""
if high is None:
warnings.warn(("This function is deprecated. Please call "
"randint(1, {low} + 1) instead".format(low=low)),
DeprecationWarning)
high = low
low = 1

else:
warnings.warn(("This function is deprecated. Please call "
"randint({low}, {high} + 1) instead".format(
low=low, high=high)), DeprecationWarning)

return self.randint(low, high + 1, size=size, dtype='l')


Expand Down
16 changes: 16 additions & 0 deletions numpy/random/tests/test_random.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,8 @@
from numpy import random
from numpy.compat import asbytes
import sys
import warnings


class TestSeed(TestCase):
def test_scalar(self):
Expand Down Expand Up @@ -255,6 +257,20 @@ def test_random_integers_max_int(self):
desired = np.iinfo('l').max
np.testing.assert_equal(actual, desired)

def test_random_integers_deprecated(self):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because Deprecation warnings are error for development testing and only raised once from a giving location by default, some care needs to be taken here. There is a _DeprecationTestCase in numpy/core/tests/test_deprecations.py that can be used as a base class and perhaps should be moved into numpy.testing, another, somewhat simpler option is

        with warnings.catch_warnings():
            warnings.simplefilter("error", DeprecationWarning)
            assert_raises(DeprecationWarning, ...)

@seberg Thoughts about moving the _DeprecationTestCase?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@charris : Could you clarify your comment? There seems to be a mixture of suggestions for this actual PR and suggestions of a greater infrastructural change. Should I move my test into test_deprecations.py as a derived class of _DeprecationTestCase?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, one is a more invasive change than the other. Quick and dirty is the simple option, the move is somewhat more complicated, but maybe provides functionality other spots would like. The idea isn't to move these tests, but rather put _DeprecationTestCase, without the underscore, someplace where you can get at it. Let's wait a bit and see if we get a second opinion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm -0 on adding _DeprecationTestCase to the public API, because it feels a bit underbaked (assert_deprecated's calling convention is super complicated!), so probably we shouldn't set it in stone as-is.

No objections to refactoring our test suite to have more useful internal tools though. Or maybe assert_warns should be clever enough to set up the warning context properly, if it isn't already.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like quick and dirty for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@charris : "quick and dirty" = move test into test_deprecations.py or that with warnings.catch_warnings() block? Both seem to fit the criterion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q&D would be least work, e.g., with the catch_warnings environment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have this new thing that clears the warning registry? It might go far enough. It is definetely half backed, it was backed by me getting desperate with avoid warning registry corruption.

If you do an assert_warns with "always" in the catch_warnings context, and then an assert_raises when putting DeprecationWarning to "error" you have it I think. I think we also have some new stuff (forgot where), which attempts to clear the warning registry.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, clearing the registry is a good safety measure to ensure that the warning is alway enabled despite previous errors/bad code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only that you have to know where the error originates from to do that, which makes it a bit annoying. Actually, did we ever consider setting the warning to "always" for all warnings in the tests? That could decrease the probability of running in those kind of issues.... Next time I will run into it, which as far as I see is as soon as I want to waste more time on oindex related deprecations, hehe.

with warnings.catch_warnings():
warnings.simplefilter("error", DeprecationWarning)

# DeprecationWarning raised with high == None
assert_raises(DeprecationWarning,
np.random.random_integers,
np.iinfo('l').max)

# DeprecationWarning raised with high != None
assert_raises(DeprecationWarning,
np.random.random_integers,
np.iinfo('l').max, np.iinfo('l').max)

def test_random_sample(self):
np.random.seed(self.seed)
actual = np.random.random_sample((3, 2))
Expand Down
0