Alexandru Ardelean <ardeleana...@gmail.com> added the comment: > Thanks for you detailed explanation. I kinda agree that it makes sense for > small, embedded systems like OpenWRT to reduce the size of binaries. After > all storage and memory are precious on these systems.
So, OpenWrt is not as tiny as it used to be. A large part is due to the Linux kernel increasing in default size. But other libs do a small increase as well (with each new revision). I think a new micro-OpenWrt (or similar project) would be required in some future to support the devices with less than 4 MB of flash and less than 32 MB of RAM. OpenWrt last supported the 4/32 combination in 2018 (with the 18.06 release). (But that's another topic I for when I retire maybe :p ) I think where users still install Python is where they have at least 64/128 MB of persistent storage/flash memory. I am still surprised about the desire of users to install Python on such devices (even after doing this for ~7 years of [co-]maintaining it it on OpenWrt). The Turris devices/routers (are one example that) use a lot of CPython for some userspace stuff. > PEP 644 favors usability over flexibility. 3rd party library developers can > now rely on the presence of hashlib features. Before 3.10 they could not be > sure that a Python build had certain features. Ack. > A downstream patch in OpenWRT makes sense. I've started down that path. But guess what... I hit LibreSSL (on the host build) :P Now I have a bigger job (than I thought) to update to 3.10 But that's fine. These events are rare, and I do enjoy to fix them (when I can). > By the way, you might be interested in --with-builtin-hashlib-hashes > configure flag. It lets you disable builtin modules like _md5 and _sha3. The > shared libraries are large. If you disable the builtin blake2 module, then > certain features like MAC and tree hashing are not working. I would not add too many flags in the Python build (on our side). For now we have some ways to "modularize" a Python installation. It's basically a hack-job of splitting Core-Python libraries into separate packages. That's when someone really wants to do a minimal installation of Python, and add only 2-3 libraries on top. Essentially, we build Python with all defaults possible, then some libs (.so & .py files) get packaged together (like ssl.py and _ssl.so from python). The more immediate benefits (in this example) are that you can avoid installing OpenSSL libs on your device, but have some Python. I know... crazy stuff, but people seem to do it. I do admit some Python fans and developers would cringe at this but ¯\_(ツ)_/¯ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45627> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
