On Sun, Jun 10, 2018 at 8:10 PM Ralf Gommers <ralf.gomm...@gmail.com> wrote:
> On Sun, Jun 10, 2018 at 5:57 PM, Robert Kern <robert.k...@gmail.com> > wrote: > >> > Conclusion: the current proposal will cause work for the vast majority >> of libraries that depends on numpy. The total amount of that work will >> certainly not be counted in person-days/weeks, and more likely in years >> than months. So I'm not convinced yet that the current proposal is the best >> way forward. >> > >> The mere usage of np.random.seed() doesn't imply that these packages >> actually require stream-compatibility. Some might, for sure, like where >> they are used in the unit tests, but that's not what you counted. At best, >> these numbers just mean that we can't eliminate np.random.seed() in a new >> system right away. >> > > Well, mere usage has been called an antipattern (also on your behalf), > plus for scipy over half of the usages do give test failures (Warren's > quick test). So I'd say that counting usages is a decent proxy for the work > that has to be done. > Let me suggest another possible concession for backwards compatibility. We should make a dedicated module, e.g., "numpy.random.stable" that contains functions implemented as methods on StableRandom. These functions should include "seed", which is too pervasive to justify removing. Transitioning to the new module should be as simple as mechanistically replacing all uses of "numpy.random" with "numpy.random.stable". This module would add virtually no maintenance overhead, because the implementations would be entirely contained on StableRandom, and would simply involve creating a single top-level StableRandom object (like what is currently done in numpy.random).
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
