ENH: prevent access to default BitGenerator

[mattip]

In continuation of the discussion in #13635, this PR (which will need a rebase once #13163 goes in) disables access to the bit_generator while still enabling pickling. The error message takes the name from the actual BitGenerator used, so if we change our default recommendation it will automatically change as well.

>>> rg = np.random.Generator()
>>> rg.bit_generator
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "generator.pyx", line 140, in 
      numpy.random.generator.Generator.bit_generator.__get__ 
      AttributeError: cannot access default bit_generator, instatiate with a
      BitGenerator instance (we recommend Xoshiro256)

[mattip]

@rkern, @bashtage any thoughts on removing access to the attributes of the default BitGenerator?

[bashtage]

Downside: it can be hard to do some types of experiments. For example

g = np.random.Generator()
state = g.bit_generator.state
<run code, have bugs>
g.bit_generator.state = state
<run code, bugs fixed>

This is probably a little contrived since it isn't that hard to replace line 1 with

g = Generator(PCG64())

and then it all works. This said, if I really want Generator(DefaultBitGenerator()) (for any DefaultBitGenerator), then is there much reward to asking the users to go through an extra step?

What I'm searching for is the upside of preventing users from reseeding a generator they created, or from getting or setting the state.

I'm all for preventing users form reseeding any single Generator instance, but this is a user created generator.

I suppose the upside is that it would be easier to swap out the default since no one could claim to have a state that needs to go into a specific bit generator.

The biggest downside is that the API depends on the function call. This probably breaks {invariance|homomorphism|somethign else} principle.

[mattip]

the upside is that it would be easier to swap out the default since no one could claim to have a state that needs to go into a specific bit generator

Exposing these methods ties us to a deprecation cycle when changing the default, since not only will the bitstream change (which is OK, given that we carefully considered before changing the defaullt), but code that depends on storing and restoring state will fail.

[mattip]

It would be nice to resolve this PR, either decide it has added value in limiting the API or that it breaks too many use patterns and should be closed.

[rkern]

I'd just close this PR.

[mattip]

No votes for keeping it? OK, closing then. Hopefully users will not adopt the use pattern Generator().bit_generator, rather only Generator(Xoshiro256()).bit_generator