get_type_hints regression for 3.9 and 3.10

[isidentical]

BPO	41613
Nosy	@gvanrossum, @ambv, @ilevkivskyi, @isidentical
Files	typing_fail.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2020-10-01.23:31:29.158>
created_at = <Date 2020-08-22.09:30:02.503>
labels = ['invalid', 'library', '3.9', '3.10']
title = 'get_type_hints regression for 3.9 and 3.10'
updated_at = <Date 2020-10-01.23:31:29.155>
user = 'https://github.com/isidentical'

bugs.python.org fields:

activity = <Date 2020-10-01.23:31:29.155>
actor = 'BTaskaya'
assignee = 'none'
closed = True
closed_date = <Date 2020-10-01.23:31:29.158>
closer = 'BTaskaya'
components = ['Library (Lib)']
creation = <Date 2020-08-22.09:30:02.503>
creator = 'BTaskaya'
dependencies = []
files = ['49421']
hgrepos = []
issue_num = 41613
keywords = []
message_count = 4.0
messages = ['375791', '375792', '375802', '377789']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'lukasz.langa', 'levkivskyi', 'BTaskaya']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue41613'
versions = ['Python 3.9', 'Python 3.10']

[isidentical]

The attached script works perfectly fine under Python 3.8, but it crashes in 3.9/3.10.

$ ./py38/python typing_fail.py (3.8.5+)
{'a': <class 'int'>, 'b': <class 'int'>}
$ ./py39/python typing_fail.py (3.9.0rc1+)
[SNIP]
TypeError: 'NoneType' object is not subscriptable
$ ./cpython/python typing_fail.py (3.10.0a0)
[SNIP]
TypeError: 'NoneType' object is not subscriptable

[isidentical]

This looks like a problem with the __globals__ of the NamedTuple.__new__

[gvanrossum]

Not nice to snip the traceback.

[isidentical]

Commit 3ff51d4 set the __builtins__ to None in namedtuple's creation, but the problem is that it is causing harm when the point came to the point of getting type hints on typing.NamedTuple.__new__ (we had a test about it), I'm changing that test (in the PR 20434) to work directly with the namedtuple itself instead of __new__ (since the annotations get proxied).