On 2021-01-11, Łukasz Langa wrote: > The stringification process which your PEP describes as costly > only happens during compilation of a .py file to .pyc. Since > pip-installing pre-compiles modules for the user at installation > time, there is very little runtime penalty for a fully annotated > application.
It should be possible to make Larry's approach cheap as well. I have an old experiment stashed away[1] where I made the code object for functions to be lazily created. I.e. when a module is first loaded, functions are not fully loaded until they are first executed. My goal was to reduce startup time. It didn't show a significant gain so I didn't pursue it further. In my experiment, I deferred the unmarshal of the code object. However, it occurs to me you could go a bit further and have the function object be mostly skeletal until someone runs it or tries to inspect it. The skeleton would really be nothing but a file offset (or memory offset, if using mmap) into the .pyc file. Of course this would be some work to implement but then all Python functions would benefit and likely Python startup time would be reduced. I think memory use would be reduced too since typically you import a lot of modules but only use some of the functions in them. I like the idea of Larry's PEP. I understand why the string-based annotations was done (I use the __future__ import for my own code). Using eval() is ugly though and Larry's idea seems like a nice way to remove the need to call eval(). [1] https://github.com/nascheme/cpython/commits/lazy_codeobject _______________________________________________ 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/64DP2LFFRA5NO53PN3G46YZ7V3OD3RT2/ Code of Conduct: http://python.org/psf/codeofconduct/
