from __future__ import annotations breaks profiler's handling of dataclasses

[wilcoxjay]

BPO	44414
Nosy	@JelleZijlstra, @wilcoxjay

^{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 2021-06-13.21:20:30.284>
labels = ['type-bug', 'library', '3.9']
title = "from __future__ import annotations breaks profiler's handling of dataclasses"
updated_at = <Date 2021-06-14.04:51:07.905>
user = 'https://github.com/wilcoxjay'

bugs.python.org fields:

activity = <Date 2021-06-14.04:51:07.905>
actor = 'JelleZijlstra'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-06-13.21:20:30.284>
creator = 'wilcoxjay'
dependencies = []
files = []
hgrepos = []
issue_num = 44414
keywords = []
message_count = 1.0
messages = ['395762']
nosy_count = 2.0
nosy_names = ['JelleZijlstra', 'wilcoxjay']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue44414'
versions = ['Python 3.9']

Linked PRs

• gh-88580: Run profile scripts in __main__ namespace #155600

[wilcoxjay]

This program behaves differently when run under the profiler (either profile or cProfile) versus when run normally.

from __future__ import annotations  # ***
import dataclasses

@dataclasses.dataclass
class C:
    x: dataclasses.InitVar[int]

    def __post_init__(self, x):
        print(f'hello {x}')

C(0)

Save this as foo.py. Then

python foo.py

prints

hello 0

but

python -m profile foo.py

results in the traceback

Traceback (most recent call last):
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 610, in <module>
    main()
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 599, in main
    runctx(code, globs, None, options.outfile, options.sort)
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 99, in runctx
    return _Utils(Profile).runctx(statement, globals, locals, filename, sort)
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 62, in runctx
    prof.runctx(statement, globals, locals)
  File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 422, in runctx
    exec(cmd, globals, locals)
  File "foo.py", line 11, in <module>
    C(0)
  File "<string>", line 4, in __init__
TypeError: __post_init__() missing 1 required positional argument: 'x'

A similar traceback occurs if using -m cProfile instead of -m profile.

No such traceback occurs if the from future import __annotations__ is removed from the file.

Possibly related to bpo-39442.

[iritkatriel]

CC @ericvsmith @carljm is this something in dataclasses?

[JelleZijlstra]

I think this is related to the code in dataclasses._init_type (around

cpython/Lib/dataclasses.py

Line 746 in 9a2f2f4

if not module_name:

) that looks at sys.modules to figure out whether something is an InitVar. C.__module__ is __main__ whether or not the module is run through the profiler, but if the profiler is used, sys.modules["__main__"] isn't the module defining the dataclass.

I'm not sure what the right solution is. The dataclasses code feels fragile, but it may be the best we can do in the presence of stringified annotations.

[ericvsmith]

Agreed on the dataclasses approach being fragile with regard to stringized annotations. But we've not come up with a better approach.

I realize stringized annotations will be around forever, but I'm hoping that if PEP 649 gets finished and merged that we won't care about these cases so much.