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/ZAPCP4MFDOF34E3G2TWAVY7JUQRHDOOB/
Code of Conduct: http://python.org/psf/codeofconduct/