[issue42202] Optimize function annotation

Change by Pablo Galindo Salgado : -- nosy: -pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue42202] Optimize function annotation

Dennis Sweeney added the comment: I believe this change accidentally affected the API of PyFunction_GetAnnotations: previously it would only return dict or NULL, now it can also return a tuple. See bpo-46236 -- nosy: +Dennis Sweeney ___ Python tra

[issue42202] Optimize function annotation

Pablo Galindo Salgado added the comment: New changeset 8747c1f233fc1a3dd5ee3d8e163317f28b4d7568 by Pablo Galindo in branch 'master': Improve the description of the improvements in bpo-42202 (GH-24738) https://github.com/python/cpython/commit/8747c1f233fc1a3dd5ee3d8e163317f28b4d7568

[issue42202] Optimize function annotation

Change by Pablo Galindo Salgado : -- nosy: +pablogsal nosy_count: 7.0 -> 8.0 pull_requests: +23509 pull_request: https://github.com/python/cpython/pull/24738 ___ Python tracker ___

[issue42202] Optimize function annotation

Change by Inada Naoki : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___ P

[issue42202] Optimize function annotation

Inada Naoki added the comment: New changeset 7301979b23406220510dd2c7934a21b41b647119 by Yurii Karabas in branch 'master': bpo-42202: Store func annotations as a tuple (GH-23316) https://github.com/python/cpython/commit/7301979b23406220510dd2c7934a21b41b647119 -- __

[issue42202] Optimize function annotation

Change by Inada Naoki : -- nosy: +lukasz.langa ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue42202] Optimize function annotation

Yurii Karabas <1998uri...@gmail.com> added the comment: > func.__annotations__ = ('x', 'int', 'z', 'float', 'return', 'Hoge') is much > better because: Inada, I totally agree with you. Sorry, I didn't realize all pitfalls with extra field to codeobject. New implementation with annotations r

[issue42202] Optimize function annotation

Inada Naoki added the comment: I don't like co_annotations. * It changes PyCode_NewXXX() API. * Many functions don't have annotations. Adding annotation to code object makes code object fatter even if the function doesn't have annotation. * Code object is immutable & hashable. Adding annota

[issue42202] Optimize function annotation

Yurii Karabas <1998uri...@gmail.com> added the comment: I have run tests with different types of function declaration. A function declaration with annotations is more than 2 times faster with the co_annotatins feature. If function doesn't have annotations time almost same as without co_annot

[issue42202] Optimize function annotation

Serhiy Storchaka added the comment: If you want to measure import time, use python -m timeit -s "from sys import modules; modules_copy = modules.copy()" "import black; modules.clear(); modules.update(modules_copy)" But I would be surprised to see significant difference in this case. What

[issue42202] Optimize function annotation

Jakub Stasiak added the comment: Yurii, I don't believe that benchmark measures what you need to measure (once imported module is kept imported forever until unloaded, so successive imports are no-ops). See how the side effects of importing bbb only happen once: % cat bbb.py import time t

[issue42202] Optimize function annotation

Yurii Karabas <1998uri...@gmail.com> added the comment: I have just implemented `co_annotations` field for `CodeObject`. I wrote a simple benchmark to measure the time required to import black module (I took black because it contains a log of annotations). Benchmark simply run `python -m timei

[issue42202] Optimize function annotation

Mark Shannon added the comment: For top level functions (functions created once) this isn't going to make any real difference. There might be a small speedup for function creation, but it isn't going to be measurable. For nested functions with annotations, where many functions are created fr

[issue42202] Optimize function annotation

Inada Naoki added the comment: > Yes, but the code for creating a dict can be simpler. In any case we will > better see what format is better when try to write a code. Note that many annotations are not accessed. RAM usage of annotation information is important than how easy to create dict.

[issue42202] Optimize function annotation

Change by Jakub Stasiak : -- nosy: +jstasiak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue42202] Optimize function annotation

Change by Yurii Karabas <1998uri...@gmail.com>: -- keywords: +patch nosy: +uriyyo nosy_count: 3.0 -> 4.0 pull_requests: +22207 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23316 ___ Python tracker

[issue42202] Optimize function annotation

Serhiy Storchaka added the comment: > Yes, but it is bit larger than my single tuple idea in most cases. Yes, but the code for creating a dict can be simpler. In any case we will better see what format is better when try to write a code. > I am not sure this is the best option because there

[issue42202] Optimize function annotation

Inada Naoki added the comment: > Are annotations now always known at compile time? Yes, because `from __future__ import annotations` is enabled by default from Python 3.10. > As for representation, it can also be a sequence of pairs (('x', 'int'), > ('z', 'float'), ('return', 'Hoge')) or a

[issue42202] Optimize function annotation

Change by Dong-hee Na : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue42202] Optimize function annotation

Dong-hee Na added the comment: @serhiy race condition sorry ;) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue42202] Optimize function annotation

Dong-hee Na added the comment: I like the 1st option which uses a tuple -- nosy: +corona10 -serhiy.storchaka ___ Python tracker ___ ___

[issue42202] Optimize function annotation

Serhiy Storchaka added the comment: Are annotations now always known at compile time? As for representation, it can also be a sequence of pairs (('x', 'int'), ('z', 'float'), ('return', 'Hoge')) or a pair of sequences (('x', 'z', 'return'), ('int', 'float', 'Hoge')). It would be better to sa

[issue42202] Optimize function annotation

New submission from Inada Naoki : Look this example: code: ``` # code def foo(x: int, /, y, *, z: float) -> Hoge: pass # dis 2 12 LOAD_CONST 2 ('int') 14 LOAD_CONST 3 ('float') 16 LOAD_CONST 4 ('Hoge')