On Sat, Jun 2, 2018 at 12:06 PM Robert Kern <robert.k...@gmail.com> wrote:
> We propose first freezing ``RandomState`` as it is and developing a new RNG > subsystem alongside it. This allows anyone who has been relying on our old > stream-compatibility guarantee to have plenty of time to migrate. > ``RandomState`` will be considered deprecated, but with a long deprecation > cycle, at least a few years. Deprecation warnings will start silent but > become > increasingly noisy over time. Bugs in the current state of the code will > *not* > be fixed if fixing them would impact the stream. However, if changes in > the > rest of ``numpy`` would break something in the ``RandomState`` code, we > will > fix ``RandomState`` to continue working (for example, some change in the > C API). No new features will be added to ``RandomState``. Users should > migrate to the new subsystem as they are able to. > Robert, thanks for this proposal. I think it makes a lot of sense and will help maintain the long-term viability of numpy.random. The main clarification I would like to see addressed is what "freezing RandomState" means for top level functions in numpy.random. I think we could safely swap out the underlying implementation if numpy.random.seed() is not explicitly called, but how would we handle cases where a seed is explicitly set? You and I both agree that this is an anti-pattern for numpy.random, but certainly there is plenty of code that relies on the stability of random numbers when seeds are set by np.random.seed(). Similar to the case for RandomState, we would presumably need to start issuing warnings when seed() is explicitly called, which begs the question of what (if anything) we propose to replace seed() with. I suppose this will be your next NEP :).
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
