In Python Maint, we sat down and we came up with several ideas how to minimize the filesystem footprint of Python. Unfortunately, the result is horribly long, sorry about that.
Did you calculate file sizes including rounding up by the
"filesystem block size" (statvfs f_bsize)?
What was the f_bsize of the file system you collected stats on?
The work to stop needing libpython is going to drop the number of files by 1
for the min install.
Can you link some of the .so's from stdlib into the main python image?
If all stdlib .so are linked into the main python and you have .zip for the
.py/.pyc files you can get python down to a handful of files.
Python app making software often exploits a trick that you can concatenate
the .zip on the end of the python image. I'm guessing that would break too many
of the constraints.
I'm not sure how you would do it but what if you created a SquashFS image
for python to lose the f_bsize overhead and use its compression?
Today python has 2 optimised file types. But the python devs have been talking
about ways to implement more optimisations and cache those results as well.
I'll failed to track down the discussion on python dev. I recall wanting to
reduce the file size by storing line number data for traceback outside of
the .pyc.
Barry