<div dir="ltr"><div dir="ltr">On Fri, Apr 19, 2019 at 4:54 AM Kevin Sheppard <<a href="mailto:kevin.k.sheppard@gmail.com">kevin.k.sheppard@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>> Finally, why do we expose the np.random.gen object? I thought part of the</div>idea with the new API was to avoid global mutable state.<br><div><br></div><div>Module level functions are essential for quick experiments and should be provided.  The only difference here is that the singleton `seed`  and `state` are no longer exposed so that it isn't possible (using the exposed API) to set the seed.</div></div></blockquote><div><br></div><div>It seems like you could set the seed with np.random.gen.brng.seed() ?</div><div><br></div><div>I do agree that module level functions are convenient and should be preserved (without the ability to seed them), but it seems like that would be an argument for exposing aliases to RandomGenerator methods (like what we currently do for RandomState methods), rather the exposing the full RandomGenerator itself.</div></div></div>