Just an idea: do not save co_name and co_firstlineno in code object for function annotations. When creating a function object from a code object, they can be copied from annotated function. I think co_name and co_firstlineno are preventing code object is shared in compile time. We can share only co_names and co_consts for now. If we can share the entire code object, it will reduce pyc file size and unmarshal time (e.g. part of import time). On Tue, Apr 20, 2021 at 6:15 AM Larry Hastings <larry@hastings.org> wrote:
On 4/19/21 1:37 PM, Ethan Furman wrote:
On 4/19/21 10:51 AM, Larry Hastings wrote:
Something analogous /could/ happen in the PEP 649 branch but currently doesn't. When running Inada Noki's benchmark, there are a total of nine possible annotations code objects. Except, each function generated by the benchmark has a unique name, and I incorporate that name into the name given to the code object (f"{function_name}.__co_annotations__"). Since each function name is different, each code object name is different, so each code object /hash/ is different, and since they aren't /exact/ duplicates they are never consolidated.
I hate anonymous functions, so the name is very important to me. The primary code base I work on does have hundreds of methods with the same signature -- unfortunately, many of the also have the same name (four levels of super() calls is not unusual, and all to the same read/write/create parent methods from read/write/create child methods). In such a case would the name make a meaningful difference?
Or maybe the name can be store when running in debug mode, and not stored with -O ?
I think it needs to have a name. But if it made a difference, perhaps it could use f"{function_name}.__co_annotations__" normally, and simply "__co_annotations__" with -O.
Note also that this is the name of the annotations code object, although I think the annotations function object reuses the name too. Anyway, under normal circumstances, the Python programmer would have no reason to interact directly with the annotations code/function object, so it's not likely it will affect them one way or another. The only time they would see it would be, say, if the calculation of an annotation threw an exception, in which case it seems like seeing f"{function_name}.__co_annotations__" in the traceback might be a helpful clue in diagnosing the problem.
I'd want to see some real numbers before considering changes here. If it has a measurable and beneficial effect on real-world code, okay! let's change it! But my suspicion is that it doesn't really matter.
Cheers,
/arry
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZAPCP4MF... Code of Conduct: http://python.org/psf/codeofconduct/
-- Inada Naoki <songofacandy@gmail.com>