Shrink mypy whitelist for 'util.nodes' module

[danieleades]

No description provided.

[AA-Turner]

This is a breaking change; consumers of the API do not expect errors here.

More generally, Sphinx has not been very good at delineating public vs private API in the past and as such extensions, themes, etc often use APIs that are not documented as public. I would like to clean this up, but it takes time and deprecations.

A

[danieleades]

This is a breaking change; consumers of the API do not expect errors here.

More generally, Sphinx has not been very good at delineating public vs private API in the past and as such extensions, themes, etc often use APIs that are not documented as public. I would like to clean this up, but it takes time and deprecations.

A

Thanks for the input. That's what I've been trying to figure out- since the None case is already not handled, I'm thinking this would already be an exception if it was encountered. I was guessing that maybe returning None was just a hack to keep mypy happy (prior to the introduction of "strict optional"), but not actually a viable path

As for the demarcation of public and private objects- it would be good to introduce "__all__" to each module to make that clear. In my experience, linter support for "__all__" is patchy, but improving.

[AA-Turner]

Having looked at GitHub's code search, it appears these utility function are not used outwith Sphinx itself.

A

[danieleades]

More generally, Sphinx has not been very good at delineating public vs private API in the past and as such extensions, themes, etc often use APIs that are not documented as public. I would like to clean this up, but it takes time and deprecations.

one way to start making inroads on this is to add to the mypy config-

no_implicit_reexport = true

That should help straighten out some of the spaghetti

[gaborbernat]

This seem to introduced a bug here #11091