gh-100129: Make the names of all classes in the types module resolvable

[serhiy-storchaka]

• Issue: Change names of builtin types exposed in the types module #100129

[JelleZijlstra]

I like how this change makes the builtin types more consistent and easy to resolve. However, I have two concerns:

• When the new type names appear in error messages, they make the errors harder to understand for new users. This is especially important with core types like module, function, and None.
• We'll surely break some external tools that rely on the names of these classes.

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.

[AlexWaygood]

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.

[gvanrossum]

I have a few nits -- feel free to address or ignore those.

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).

[gvanrossum]

Why not types.FunctionType?

[serhiy-storchaka]

Because the MagicMock repr contains only spec_class.__name__, not the fully qualified name.

[gvanrossum]

Why is this not types.ModuleType?

[serhiy-storchaka]

The same as above. It outputs type(obj).__name__.

[gvanrossum]

It's debatable whether this should have the types. prefix -- what do we do in other similar situations?

[serhiy-storchaka]

Only short name is used in almost all of other similar situations (over 50 uses of this function, around 1700 uses of all PyArg_* functions). The only known exceptions are array.array, sqlite3.Connection, type.__new__, and deque.rotate.

[JelleZijlstra]

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.

[gvanrossum]

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:

deff():
passfunc: function=f

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

importtypesfunc: types.FunctionType=f

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". :-)

[gvanrossum]

Thanks for the answers, go ahead and merge.

[serhiy-storchaka]

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?

[markshannon]

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.

[gvanrossum]

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.

[tungol]

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.

[github-actions]

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

[read-the-docs-community]

Documentation build overview

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

🔍 Preview build

8 files changed · ± 8 modified

±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