This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author methane
Recipients corona10, methane, serhiy.storchaka
Date 2020-10-30.08:32:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1604046723.06.0.0830563263964.issue42202@roundup.psfhosted.org>
In-reply-to
Content
> 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 pair of sequences (('x', 'z', 'return'), ('int', 'float', 'Hoge')). It would be better to save a dict directly in pyc files, but it needs changing the marshal protocol.

Yes, but it is bit larger than my single tuple idea in most cases.
Since most annotations are not used by runtime, we don't need to create a dict until `func.__annotation__` is read.

> Also, it makes sense to make annotations attribute of the code object, so avoid the overhead at function creation time.

I am not sure this is the best option because there are many code object without annotation.

> I have a dream to split the pyc file into several files or sections and save docstrings and annotations (and maybe line numbers) separately from the main code. They should be loaded by demand, when you read __doc__ or __annotation__. Most code does not use them at run time, so we can save memory and loading time. It can also help with internationalization.

I have same dream.
History
Date User Action Args
2020-10-30 08:32:03methanesetrecipients: + methane, serhiy.storchaka, corona10
2020-10-30 08:32:03methanesetmessageid: <1604046723.06.0.0830563263964.issue42202@roundup.psfhosted.org>
2020-10-30 08:32:03methanelinkissue42202 messages
2020-10-30 08:32:03methanecreate