stubtest: don't enforce `@disjoint_base` by default until PEP 800 is accepted

[jorenham]

When running stubtest from the master branch on scipy-stubs (31 errors) and the numpy stubs from numtype (195 errors) there are a bunch of new errors about missing @disjoint_base, for example:

error: numpy.random.RandomState is a disjoint base at runtime, but isn't marked with @disjoint_base in the stub
Stub: in file src/numpy-stubs/random/__init__.pyi:77
<TypeInfo numpy.random.mtrand.RandomState>
Runtime:
<class 'numpy.random.mtrand.RandomState'>

I think it's a good check, but I'm a bit hesitant to add it before PEP 800 is accepted. Because if it were to be rejected, and typing_extensions.disjoint_base were to be removed, then I'm sure you can see how that could cause a bunch of problems.

[jorenham]

cc @JelleZijlstra

[JelleZijlstra]

We could add a flag to stubtest to disable the disjoint_base check.

[jorenham]

Nice; that would help, thanks. Personally I'd make it opt-in until it's accepted, but this is also fine I suppose.

[AlexWaygood]

FWIW we basically never remove things from typing_extensions, even if a PEP is rejected (or if the PEP is never in fact written -- there are some fun Easter eggs in there that have been there for many years at this point :-)

That said, I can totally see your point of view and would be fine with adding a stubtest flag to disable the @disjoint_base check

[jorenham]

FWIW we basically never remove things from typing_extensions, even if a PEP is rejected (or if the PEP is never in fact written -- there are some fun Easter eggs in there that have been there for many years at this point :-)

Lol yea I see that typing_extensions.IntVar is still there. Github search shows 0 results for it, so out of curiosity; why are you keeping it?

[JelleZijlstra]

It's really annoying if people put an upper bound on their typing-extensions dependency, so I don't want to give people any reason to do so.

[JelleZijlstra]

Plus it's totally in use.

[jorenham]

It's really annoying if people put an upper bound on their typing-extensions dependency, so I don't want to give people any reason to do so.

I certainly appreciate that, because I also don't upper-bound it.

And there's of course also typeshed to consider, where it's usually not even possible to specify which version you want to use.

I suppose that typing_extensions can also be considered as the museum of Python typing then :)

[JelleZijlstra]

Back on topic, are you interested in contributing a PR to control whether disjoint_base is checked or not? I don't care much whether it's on or off by default, as long as it's on for typeshed.

[jorenham]

Back on topic, are you interested in contributing a PR to control whether disjoint_base is checked or not? I don't care much whether it's on or off by default, as long as it's on for typeshed.

sure, sounds fun

[jorenham]

Back on topic, are you interested in contributing a PR to control whether disjoint_base is checked or not? I don't care much whether it's on or off by default, as long as it's on for typeshed.

sure, sounds fun

#19740