4.7.0: new implementation of TypedDict breaks pypy-3.7 and pypy-3.8 about typing_extensions

[JelleZijlstra]

This looks like a bug in pypy: it doesn't properly support __mro_entries__.

% python3.8
Python 3.8.16 (default, Dec 26 2022, 20:36:56) 
[Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(): pass
... 
>>> f.__mro_entries__ = lambda _: (int,)
>>> class x(f): pass
... 
>>> x.__bases__
(<class 'int'>,)
>>> 
% ~/.pyenv/versions/pypy3.8-7.3.11/bin/python
Python 3.8.16 (a9dbdca6fc3286b0addd2240f11d97d8e8de187a, Dec 29 2022, 11:45:30)
[PyPy 7.3.11 with GCC Apple LLVM 13.1.6 (clang-1316.0.21.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>> def f(): pass
>>>> f.__mro_entries__ = lambda _: (int,)
>>>> class x(f): pass
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: metaclass found to be 'function', but calling <class 'function'> with args ('x', (<function f at 0x0000000148314ca0>,), ...) raised "'internal-code' object expected, got 'str' instead"

Meanwhile, on pypy3.9-7.3.11 this works fine. I reported https://foss.heptapod.net/pypy/pypy/-/issues/3958.

As a workaround, we could go back to the previous implementation of TypedDict on pypy3.7/8 and cut a bugfix release.

[AlexWaygood]

Ah, looks like even PyPy-3.8 is broken: https://github.com/python/typing_extensions/actions/runs/5421296757/jobs/9856554127

[A5rocks]

Hi, I've encountered this too! Only on pypy 3.7 here cause turns out pylint subclasses typing_extensions.TypedDict when python version <3.8! https://github.com/python-trio/trio/actions/runs/5405876855/jobs/9822036832#step:5:1587 (I'm going to pin typing_extensions to below the current version just until we get out our final release that supports 3.7, so this isn't a major problem for us.)

[AlexWaygood]

As a workaround, we could go back to the previous implementation of TypedDict on pypy3.7/8 and cut a bugfix release.

If it was just broken on PyPy-3.7, I wouldn't worry about it, but since this also breaks PyPy-3.8, I think this might be a good idea as a stopgap solution, even though I definitely feel like the bug is on PyPy's side ://

[AlexWaygood]

#262 is a compatibility shim that isn't too invasive for us, and fixes tests on PyPy <3.9