[Python-Dev] Re: How to customize CPython to a minimal set
On 7/20/20 10:30 AM, Huang, Yang wrote: > > Hi, all > > There is a request to run python in a Linux-based embedded resource > constrained system with sqlite3 support. > > So many features are not required, like posixmodule, signalmodule, hashtable > ... > But seems there are some dependencies among the > Modules/Parser/Python/Objects/Programs... > > Is there a way to tailor CPython 3 to a minimal set with sqlite3 (the less > syscalls the better) ? > Is it possible to do that? CPython comes with the promise of all batteries included, however sometimes it feels like a complete power plant. For packaging purposes, most Linux distros make the decision to ship CPython as a set of runtime packages, and a set of packages used for development (and building C extensions). Breaking that down for the Debian/Ubuntu packages comes down to these sizes (unpacked, uncompressed, on x86_64): minimal: 5516K debian/libpython3.9-minimal 5856K debian/python3.9-minimal stdlib: 8528K debian/libpython3.9-stdlib 624Kdebian/python3.9 development: 19468K debian/libpython3.9-dev 25804K debian/libpython3.9-testsuite 1232K debian/python3-distutils 668Kdebian/python3-lib2to3 548Kdebian/python3.9-dev extra modules: 1648K debian/idle-python3.9 5208K debian/python3.9-examples 132Kdebian/python3-gdbm 844Kdebian/python3-tk What you don't see from the sizes, are the extra dependencies which add to the size, e.g. the X stack for tk, or readline/curses/crypto for stdlib. The "minimal" set may sound nice, however it's not used in practice, because the set is not well defined, and it's difficult to keep the minimal set as a self-contained set of stdlib modules, and the minimal usually keeps growing, never shrinks. It looks like this "minimal" set is even too much for your purposed, so you would have to scale down this set even further. Matthias ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/OZY63O24XP535PQYBAYNFXRF5S3PDV3E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.
On 22Jul2020 1319, Mark Shannon wrote: On 21/07/2020 9:46 pm, Gregory P. Smith wrote: Q: Why can't we have the information about the entire span of lines rather than consider a definition to be a "line"? Pretty much every profiler, coverage tool, and debugger ever expects lines to be natural numbers, not ranges of numbers. A lot of tooling would need to be changed. As someone who worked on apparently the only debugger that expects _character_ ranges, rather than a simple line number, I would love to keep full mapping information somewhere. We experimented with some stack analysis to see if we could tell the difference between being inside the list comprehension vs. outside the comprehension, or which of the nested comprehension is currently running. But it turned out to be too much trouble. An alternative to lnotab that includes the full line/column range for the expression, presumably taken from a particular type of node in the AST, would be great. But I think omitting even line ranges at this stage would be a missed opportunity, since we're breaking non-Python debuggers anyway. Cheers, Steve ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/MKX3TW2DCQ5XCOWP2C4XBREENQKFIFH3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.
In theory, this table could be stored somewhere other than the code object, so that it doesn't actually get paged in or occupy cache unless tracing is on. Whether that saves enough to be worth the extra indirections when tracing is on, I have no intention of volunteering to measure. I will note that in the past, taking out docstrings (not even just moving them to a dict of [code:docstring] -- just taking them out completely) has been considered worthwhile. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/HEXSSC35MFWFKFRK6TO4N5SBJDTZAZOS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.
I think this example should be in the PEP. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/Z6TNMC7HKRQHQMEDHXKM2PAAKE233KUO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.
> In theory, this table could be stored somewhere other than the code object, so that it doesn't actually get paged in or occupy cache unless tracing is on. As some of us mentioned before, that will hurt the ecosystem of profilers and debugger tools considerably On Thu, 23 Jul 2020 at 18:08, Jim J. Jewett wrote: > In theory, this table could be stored somewhere other than the code > object, so that it doesn't actually get paged in or occupy cache unless > tracing is on. Whether that saves enough to be worth the extra > indirections when tracing is on, I have no intention of volunteering to > measure. I will note that in the past, taking out docstrings (not even > just moving them to a dict of [code:docstring] -- just taking them out > completely) has been considered worthwhile. > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/HEXSSC35MFWFKFRK6TO4N5SBJDTZAZOS/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/HQ6DYNN4D5TKB6VIW4GN4QSGQWPVTP5V/ Code of Conduct: http://python.org/psf/codeofconduct/
