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

serhiy-storchaka · 2022-12-09T08:49:11Z

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

…solvable

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.

Doc/library/multiprocessing.rst

AlexWaygood · 2022-12-20T22:15:26Z

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 · 2022-12-18T19:24:59Z

Doc/library/unittest.mock.rst

@@ -890,7 +890,7 @@ object::
    ...
    >>> mock = MagicMock(async_func)
    >>> mock
-    <MagicMock spec='function' id='...'>
+    <MagicMock spec='FunctionType' id='...'>


Why not types.FunctionType?

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

gvanrossum · 2022-12-18T19:28:41Z

Lib/test/test_json/test_fail.py

@@ -100,7 +100,7 @@ def test_non_string_keys_dict(self):
    def test_not_serializable(self):
        import sys
        with self.assertRaisesRegex(TypeError,
-                'Object of type module is not JSON serializable'):
+                'Object of type ModuleType is not JSON serializable'):


Why is this not types.ModuleType?

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

gvanrossum · 2022-12-18T19:32:26Z

Objects/cellobject.c

@@ -35,11 +35,11 @@ cell_new(PyTypeObject *type, PyObject *args, PyObject *kwargs)
    PyObject *return_value = NULL;
    PyObject *obj = NULL;

-    if (!_PyArg_NoKeywords("cell", kwargs)) {
+    if (!_PyArg_NoKeywords("CellType", kwargs)) {


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

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 · 2022-12-21T02:20:36Z

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 · 2022-12-21T05:19:11Z

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:

def f():
    pass

func: 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

import types
func: 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 · 2022-12-21T19:49:35Z

Thanks for the answers, go ahead and merge.

serhiy-storchaka · 2022-12-21T20:53:08Z

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 · 2022-12-21T21:04:54Z

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 · 2022-12-21T22:25:20Z

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 · 2024-11-11T05:18:52Z

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.

pythongh-100129: Make the names of all classes in the types module re…

4f908e8

…solvable

bedevere-bot mentioned this pull request Dec 9, 2022

Change names of builtin types exposed in the types module #100129

Open

bedevere-bot added the awaiting core review label Dec 9, 2022

serhiy-storchaka added 2 commits December 9, 2022 19:31

Add tests.

6cd302c

Add a NEWS entry.

5da1f0b

serhiy-storchaka marked this pull request as ready for review December 9, 2022 17:36

serhiy-storchaka requested review from gvanrossum, Fidget-Spinner, JelleZijlstra, AlexWaygood, iritkatriel and markshannon as code owners December 9, 2022 17:36

Fix doctests.

29ef7e6

serhiy-storchaka requested review from rhettinger and tiran as code owners December 9, 2022 18:07

python deleted a comment from netlify bot Dec 10, 2022

JelleZijlstra reviewed Dec 20, 2022

View reviewed changes

Doc/library/multiprocessing.rst Outdated Show resolved Hide resolved

gvanrossum approved these changes Dec 21, 2022

View reviewed changes

bedevere-bot added awaiting merge and removed awaiting core review labels Dec 21, 2022

serhiy-storchaka added 3 commits December 21, 2022 10:26

Merge branch 'main' into types-qualnames

bb35505

Merge branch 'main' into types-qualnames

fc43f35

Revert changes made in other issue.

fd01d7a

AlexWaygood removed their request for review February 3, 2023 10:12

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

serhiy-storchaka commented Dec 9, 2022 •

edited by bedevere-bot

Loading

JelleZijlstra left a comment

AlexWaygood commented Dec 20, 2022

gvanrossum left a comment

gvanrossum Dec 18, 2022

serhiy-storchaka Dec 21, 2022

gvanrossum Dec 18, 2022

serhiy-storchaka Dec 21, 2022

gvanrossum Dec 18, 2022

serhiy-storchaka Dec 21, 2022

JelleZijlstra commented Dec 21, 2022

gvanrossum commented Dec 21, 2022

gvanrossum commented Dec 21, 2022

serhiy-storchaka commented Dec 21, 2022

markshannon commented Dec 21, 2022

gvanrossum commented Dec 21, 2022

tungol commented Nov 11, 2024

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

Are you sure you want to change the base?

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

Conversation

serhiy-storchaka commented Dec 9, 2022 • edited by bedevere-bot Loading

JelleZijlstra left a comment

Choose a reason for hiding this comment

AlexWaygood commented Dec 20, 2022

gvanrossum left a comment

Choose a reason for hiding this comment

gvanrossum Dec 18, 2022

Choose a reason for hiding this comment

serhiy-storchaka Dec 21, 2022

Choose a reason for hiding this comment

gvanrossum Dec 18, 2022

Choose a reason for hiding this comment

serhiy-storchaka Dec 21, 2022

Choose a reason for hiding this comment

gvanrossum Dec 18, 2022

Choose a reason for hiding this comment

serhiy-storchaka Dec 21, 2022

Choose a reason for hiding this comment

JelleZijlstra commented Dec 21, 2022

gvanrossum commented Dec 21, 2022

gvanrossum commented Dec 21, 2022

serhiy-storchaka commented Dec 21, 2022

markshannon commented Dec 21, 2022

gvanrossum commented Dec 21, 2022

tungol commented Nov 11, 2024

serhiy-storchaka commented Dec 9, 2022 •

edited by bedevere-bot

Loading