Lighter Python
By no means am I the first to come up with this, there’s other people who’ve pushed forward the idea that Python needs to go on a diet.
There seems to be a few implementations:
- tinypy, which is a 2008 implementation written in about 100KiB of source code, where it has support for a subset of Python 2.5.
- Diet Python, which is a 2006 cut down version of Python 2.5, with some gaming / GUI-oriented libraries thrown in place of the standard library, coming in at about 3MiB. It also has a handy feature of executing __init__.py on startup if it is in the same directory as python.
- Debian has a python-minimal package, which is standard Python but with a subset of modules needed to make the system boot.
Two of these implementations are quite old, and target Python 2.5. Debian targets Python 2.7.
There are some drawbacks:
- More difficult to install for packages – they need to potentially pull in more modules. easy_install and pip already take care of this, however.
- Multiple competing implementations of trivial functionality.
There’s some benefits to making Python smaller:
- With code coming out of the standard library, it can be updated seperately to the rest of Python.
- Only install what is needed: good for embedded systems.
- Maintaining CPython becomes much easier.
- Non-CPython implementations can use the external Python-only modules in the same way that CPython would without having to maintain their own version.
- Getting code into these modules becomes a lot easier.
- Competing implementations will eventually starve each other out until a good implementation is achieved.
First experiment: no source modifications
Took CPython 2.7 on win32. Removed everything from Lib directory, and put modules back in until Python 2.7 could run in interactive mode and a simple (obfuscated) fizzbuzz implementation.
Ended up with 1.67MiB of Python source files, which went up to 1.98MiB when .pyc were compiled. Compare to the original size of this folder: 26.8MiB (excluding my site-packages), this is a good start.
It left me with these modules:
- __future__
- _abcoll
- _weakrefset
- abc
- codecs (didn’t attempt pruning of codecs, just copied all of them)
- copy_reg
- functools
- genericpath
- linecache
- locale
- ntpath
- os
- re
- runpy
- site
- sre_compile
- sre_constants
- sre_parse
- stat
- sysconfig
- traceback
- types
- UserDict
- warnings
This still has the problem that any compiled in modules are still hanging around, like datetime.
In order to actually remove those as well, you must dive into source modifications.
(Coming up next time.)
Migrating from Wordpress
It’s not often that people are migrating away from Wordpress.
Indeed, many of the “conversion” tools are for getting you on Wordpress!
I’ve started writing a conversion tool to migrate from Wordpress to Tinkerer (the blogging software which I’m using at present).
It’s a bit rough around the edges, but all the other pages are converted directly from Wordpress.
At the moment the major issues I need to work out are:
- Post hierarchy (there is none, at the moment all the static pages are flat).
- Fixing all the links in the site that link to either other pages or other posts.
The majority of the content should be back again.