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 <la...@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-le...@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/ZAPCP4MFDOF34E3G2TWAVY7JUQRHDOOB/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki <songofaca...@gmail.com>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/NVVLCBI3I75C5N67BP7TJJ2JX2LT6OP6/
Code of Conduct: http://python.org/psf/codeofconduct/
