On 08.05.2021 23:55, Gregory P. Smith wrote: > Who non-hypothetically cares about a 22% pyc file size increase? I don't > think > we should be concerned. I'm in favor of always writing them and the 20% size > increase that results in. If pyc size is an issue that should be its own > separate enhancement PEP. When it comes to pyc files there is more data we > may > want to store in the future for performance reasons - I don't see them > shrinking > without an independent effort. > > Caring about additional data retained in memory at runtime makes more sense to > me as ram cost is much greater than storage cost and is paid repeatedly per > process. Storing an additional reference to None on code objects where a > column > information table is perfectly fine. That can be a -X style interpreter > startup > option. It isn't something that needs to impacted by the pyc files. Pass > that > option to the interpreter, and it just discards column info tables on code > objects after loading them or compiling them. If people want to optimize for > a > shared pyc situation with memory mapping techniques, that is also something > that > should be a separate enhancement PEP and not involved here. People writing > code > to use the column information should always check it for None first, that'd be > something we document with the new feature.
I do care about both the increase in PYC size as well as the increase in memory usage. When using Python in containers both are relevant and so I'd like an option to switch this whole mechanism off that's independent from optimization settings. This idea is more about debugging during development and doesn't really have much to do with optimization used for production use of Python, so a separate flag or perhaps use of -v would the more intuitive approach. Alternative idea: Create a new file format which supports enhanced debugging. This would include the source code in a indexed format, the AST and mappings between byte code, AST node, lines and columns. Python would then only use and load this file when it needs to print a traceback - much like it does today with the source code. The advantage is that you can add even more useful information for debugging while not making the default code distribution format take more memory (both disk and RAM). BTW: For better readability, I'd also not output the ^^^^ lines for every stack level in the traceback, but just the last one, since it's usually clear where the call to the next stack level happens in the upper ones. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 09 2021) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.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/VF3OFSOJIS2PDCGJM2UCELKDHUWYM2HR/ Code of Conduct: http://python.org/psf/codeofconduct/
