Repository navigation
Don't return implicit optional types by get_type_hints #77314
Description
| BPO | 33133 |
|---|---|
| Nosy | @gvanrossum, @ilevkivskyi |
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 = None
created_at = <Date 2018-03-24.18:16:02.475>
labels = ['3.7', '3.8', 'type-bug', 'library']
title = "Don't return implicit optional types by get_type_hints"
updated_at = <Date 2018-03-25.09:21:10.688>
user = 'https://github.com/ilevkivskyi'bugs.python.org fields:
activity = <Date 2018-03-25.09:21:10.688>
actor = 'levkivskyi'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2018-03-24.18:16:02.475>
creator = 'levkivskyi'
dependencies = []
files = []
hgrepos = []
issue_num = 33133
keywords = []
message_count = 3.0
messages = ['314378', '314395', '314401']
nosy_count = 2.0
nosy_names = ['gvanrossum', 'levkivskyi']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33133'
versions = ['Python 3.7', 'Python 3.8']
Activity
ilevkivskyi commentedon Mar 24, 2018
Currently this code
returns {'x': Optional[int]}. I propose to abandon this behaviour. Although there is not yet a definitive decision about this aspect of PEP-484, see python/typing#275, I think at least at runtime we should not do this.
gvanrossum commentedon Mar 25, 2018
I'm not sure we should change this ahead of a definitive decision. When you use mypy with the option that forbids it, your program will be invalid, and it doesn't really matter what we do at runtime; but that option is not the default yet, and without that option, mypy treats the type as Optional[int].
ilevkivskyi commentedon Mar 25, 2018
OK, let us then keep this issue as a remainder that we need to update the runtime behaviour when the static one changes.
AlexWaygood commentedon Apr 14, 2022
This behaviour was fixed in #30304: