Skip to content

Don't return implicit optional types by get_type_hints #77314

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ilevkivskyi opened this issue Mar 24, 2018 · 4 comments
Closed

Don't return implicit optional types by get_type_hints #77314

ilevkivskyi opened this issue Mar 24, 2018 · 4 comments
Labels
3.7 (EOL) end of life 3.8 (EOL) end of life stdlib Python modules in the Lib dir topic-typing type-bug An unexpected behavior, bug, or error

Comments

@ilevkivskyi
Copy link
Member

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']
@ilevkivskyi
Copy link
Member Author

Currently this code

def f(x: int = None):
    pass

get_type_hints(f)

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.

@ilevkivskyi ilevkivskyi added 3.7 (EOL) end of life 3.8 (EOL) end of life stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Mar 24, 2018
@gvanrossum
Copy link
Member

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
Copy link
Member Author

OK, let us then keep this issue as a remainder that we need to update the runtime behaviour when the static one changes.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
@AlexWaygood
Copy link
Member

This behaviour was fixed in #30304:

C:\Users\alexw\coding\cpython>python
Running Debug|x64 interpreter...
Python 3.11.0a7+ (main, Apr 14 2022, 10:41:31) [MSC v.1931 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(x: int = None):
...     pass
...
>>> from typing import get_type_hints
>>> get_type_hints(f)
{'x': <class 'int'>}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
3.7 (EOL) end of life 3.8 (EOL) end of life stdlib Python modules in the Lib dir topic-typing type-bug An unexpected behavior, bug, or error
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gvanrossum @ilevkivskyi @AlexWaygood