I think the case for changing is strongest for the various descriptor types, where it's otherwise difficult right now to map a type to the entry in the types module, and weakest for core builtins like module, function, and NoneType.

Agreed. I'm broadly supportive of this change, but the change to None in particular makes me feel pretty queasy.

I'd like @JelleZijlstra or another typeshed/mypy dev to have a quick look here to see whether changing a few names like function, ellipsis would cause any issues for static type checkers (though I doubt it).

Fully static type checkers like mypy never look at the runtime type objects so it shouldn't matter. Tools like stubtest or my pyanalyze typechecker might need to adapt a little but that's pretty easy.

Fully static type checkers like mypy never look at the runtime type objects so it shouldn't matter. Tools like stubtest or my pyanalyze typechecker might need to adapt a little but that's pretty easy.

I was thinking about it slightly differently. Typeshed defines classes builtins.function and builtins.ellipsis (and maybe others). Those were always a typeshed-only fiction, but mypy does recognize it -- e.g. this program shows no errors:

There was some precedent for this when type(f) would return <class 'function'> at runtime. But the new regime would suggest that instead the variable func above should be typed as

which currently produces an error in mypy.

(In a sense, this PR finally resolves a problem that mypy experienced from its creation: what is the name of the type of a function object. Grepping shows dozens of occurrences of builtins.function in the mypy source code.)

I agree that we shouldn't stop this PR because it exposes mypy's "lie". :-)

Thanks for the answers, go ahead and merge.

What do you think about omitting the "types." prefix like the "builtins." prefix and, in some cases, the "__main__." prefix, in error messages and type reprs?

This is going to break things. Changing the names NoneType, the type of generators and functions is going to break someone's code. Maybe they shouldn't be relying on those names and those are acceptable breakages, but I think we should take a bit more care here.

There are a lot of changes to the tests. If this change breaks our tests, it is reasonable to assume it will break other people's tests.

I'm happy to retract my approval in favor of more discussion -- maybe we should do that on Discourse though, where we can get the view of more people whose code actually will break. I agree that the amount of change needed in our own tests doesn't bode well.

Just to note: the new-in-3.13 types.CapsuleType / PyCapsule is not included in the current state of this MR, and should also be updated if this gets picked up again.

This PR is stale because it has been open for 30 days with no activity.

Documentation build overview

📚 cpython-previews | 🛠️ Build #32994241 | 📁 Comparing f74b4b2 against main (038495d)

  🔍 Preview build  

± Modified

• howto/argparse.html
• library/doctest.html
• library/functools.html
• library/multiprocessing.shared_memory.html
• library/re.html
• library/typing.html
• library/unittest.mock.html
• whatsnew/changelog.html