I believe it is exposed in the upcoming 1.19. If you want to try there are wheels for the rc2 release on PyPI.

Thanks for your quick reply. I just tried the above cimport statements with numpy 1.18.5, 1.19.0rc1, and 1.19.0rc2 and received 'numpy/random/Generator.pxd' not found error message. I could verify with the content of numpy/random/__init__.pxd exposes BitGenerator but not Generator (last line).

Numpy/Python version information for the most recent candidate:

1.19.0rc2 3.7.7 (default, May  6 2020, 04:59:01) 
[Clang 4.0.1 (tags/RELEASE_401/final)]

I think that is a documentation mistake. The functions mentioned on the page you reference come from c_distributions.pxd so the line should read something like

Typed versions of many of the SeedSequence and BitGenerator methods and classes and the c_distribution functions ...

I am curious about the use case for the Generator class from Cython,

Yes, that absolutely makes sense.

My understanding is that if one wants to use Generators they could use their Python objects, and it's absolutely valid to use default_rng(). However, it could appeal to certain Cython developers to either type name their Generator or to compile their Generator (via cimport-ing) to quickly access higher level methods out of the box. I'd say typing and the compilation of default_rng() are the two cases I could put my finger on.

Yes, that absolutely makes sense.

My understanding is that if one wants to use Generators they could use their Python objects, and it's absolutely valid to use default_rng(). However, it could appeal to certain Cython developers to either type name their Generator or to compile their Generator (via cimport-ing) to quickly access higher level methods out of the box. I'd say typing and the compilation of default_rng() are the two cases I could put my finger on.

I second this

We are trying to be conservative in adding to the sprawling NumPy API. If a project comes along with a real-world use case we can discuss exposing more, but as of now I think we should turn this into a documentation issue.

Generator doesn't expose anything that is usable in lower-level cython. There is no point in making it part of the C-api.

The components are all there as of 1.19 so you can mix pretty much any custom variant generators you need.

My understanding is that if one wants to use Generators they could use their Python objects, and it's absolutely valid to use default_rng(). However, it could appeal to certain Cython developers to either type name their Generator or to compile their Generator (via cimport-ing) to quickly access higher level methods out of the box. I'd say typing and the compilation of default_rng() are the two cases I could put my finger on.

Every function from Generator is def not cpdef and there aren't really any interesting c-level attributes available that you can't get from the Python Capsule that is exported from any bit generator.