<div dir="ltr">> 

Rather than "base RNG", what about calling these classes a "random source"<br>or "random stream"? In particular, I would suggest defining two Python<br>classes:<br>> - np.random.Generator as a less redundant name for what is currently called<br>RandomGenerator<br>> - np.random.Source or np.random.Stream as an abstract base class for what<br>are currently called "base RNGs"<div><br></div><div>Naming is definitely hard.  Simple RNGs are currently called basic RNGs which was inspired by mkl-random. 'source' sounds OK to me, but sort of hides the fact that these are the actual Psuedo RNGs. `stream` has a technical meaning (a single PRNG make produce multiple independent streams) and IMO should be avoided since this might lead to confusion.  Perhaps source_rng (or in docs Source RNG)?</div><div><br></div><div>RandomGenerator is actually RandomTransformer, but I didn't like the latter name. </div><div><br></div><div>> There are also a couple of convenience attributes in the user-facing API<br>that I would suggest refining:<br>>   - The "brng" attribute of RandomGenerator is not a very descriptive name. I<br>would prefer "stream" or "source", or the more explicit "base_rng" if we<br>stick with that term.<br>>   - I don't think we need the "generator" property on base RNG objects. It is<br>fine to require writing np.random.Generator(base) instead. Looking at the<br>implementation, .generator caches the RandomGenerator objects it creates on<br>the base RNG, which creates a reference cycle. Yes, Python can garbage<br>collect reference cycles, but this is still a muddled data model.<br></div><div><br></div><div>The attribute name should match the final (descriptive) name, whatever it is.  In RandomGen I am using the `basic_rng` attribute name, but this could be `source`.  I also use a property so that the attribute can have a docstring attached for use in IPython. I think this is more user-friendly.</div><div><br></div><div>I think dropping the `generator` property on the basic RNGs is reasonable.  It was a convenience but is awkward, and I always understood that it creates a cycle.</div><div><br></div><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><br></div></div>