Alex Waygood

And, I see that the test cases I added fail with pyright...

I got stubtest working, with a few hacks. If we're happy with the hacks, I can ask the pyright maintainers to look at why the test cases I added might...

> I would prefer if we copy the distutils stubs into setuptools. From what I understand, they are different from stdlib's distutils at this point anyway, and may evolve further....

`setuptools._distutils` does not use an import hack, and never has done, but the plain `distutils` package that's installed into your environment as part of `pip install setuptools` still does.

Not `from setuptools import distutils`, just plain `import distutils`. `pip install`ing `setuptools` into your environment also installs a `distutils` package into your environment that is standalone to `setuptools`. And yes,...

@srittau, this is the behaviour I'm trying to reflect in this PR: ```pytb (fresh-venv) C:\Users\alexw\coding>python -VV Python 3.12.0 (tags/v3.12.0:0fb18b0, Oct 2 2023, 13:03:39) [MSC v.1935 64 bit (AMD64)] (fresh-venv) C:\Users\alexw\coding>python...

@erictraut, the VERSIONS file only gives type checkers information regarding the stdlib stubs (this is why the file is in our `stdlib/` directory). I don't think pyright should be inferring...

> I'm not sure what you mean by "provided by the third-party `setuptools` distribution. I've tried installing the latest `setuptools` from pypi, and I don't see any `distutils` package installed...

Huh, I see that this seems to be fixed on the latest version of pyright; all CI is now passing on this PR. I wonder what changed, and when. Sorry...

I think the only thing still blocking this PR is the question of whether we're happy with the hacks I'm introducing to `stubtest_third_party.py` in order to get stubtest to still...