The latest release of PyEnchant now contains an experimental binary distribution for OSX, as both an mpkg installer and a python egg. In theory, users on OSX 10.4 or later should be able to just drop pyenchant-1.6.3-py2.6-macosx-10.4-universal.egg somewhere on sys.path and be up and running and spellchecking with ease.
If you're a Mac user, please try it out and let me know if anything doesn't work the way you expect.
The experience of building this was quite interesting, and more than a little painful, because I wanted to build a proper universal library that could be used on almost any Mac out there. The gory details can be found in pyenchant-bdist-osx-sources-1.6.3.tar.gz; this post is a quick set of notes that might help others get started.
Fortunately for me, the familiar build toolchain of "./configure; make; make install" is pretty much intact on OSX. The only real trickery is getting the resulting library to work on systems other than your own. I hit two major stumbling blocks in this regard:
- how to build fat binaries that still work on older versions of OSX?
- how to make the libraries relocatable, so they can be installed at any location?
This may all be old news to seasoned OSX veterans, but hopefully these notes can help out other expat linux users like me.
Compiling RPython Programs
Inspired by a recent discussion on Reddit about a Python-to-C++ compiler called Shed Skin, I decided to write up my own experiences on compiling (a restricted subset of) Python to a stand-alone executable. My tool of choice is the translation toolchain from the PyPy project – a project, by the way, that every Python programmer should take a look at.
Take this very exciting (EDIT: and needlessly inefficient) python script, which we'll assume is in a file "factors.py":
def factors(n): """Calculate all the factors of n.""" for i in xrange(2,n / 2): if n % i == 0: return [i] + factors(n / i) return [n] def main(argv): n = int(argv[1]) print "factors of", n, "are", factors(n) if __name__ == "__main__": import sys main(sys.argv)
We can of course run this from the command-line using the python interpreter, but gosh that's boring:
$> python factors.py 987654321 factors of 987654321 are [3, 3, 17, 17, 379721]
Instead, let's compile it into a stand-alone executable! Grab the latest source tarball from the PyPy downloads page and unzip it in your work directory:
I've just spent a few days trying to improve the performance of a frozen Python app - specifically, the time it takes to start up and present a login window. Most of the improvements were down to good old-fashioned writing of better code, but I also put together a couple of tricks to help shave off even more milliseconds. They both target one of the major sources of slowness when starting up a Python app: imports.
Import processing is an area where an app written in Python is at a big disadvantage compared to compiled languages such as C or Java. In a such languages the equivalent of an "import" statement is usually a compile-time directive that sucks in code from another file, and its impact on startup time is negligible. In Python, the import statement is a run-time directive that goes looking for the named module, compiles the source file if necessary, loads the compiled code into memory, executes the code in a new namespace, and finally returns the resulting module object. Clearly the fewer imports you can do at application startup, the better.
Lazy Imports
I first learned how important lazy imports can be from Andrew Bennetts, who works for Canonical on the Bazaar version control system. Most Python-related conferences in Australia feature Andrew giving a presentation on performance (most recently it was at PyCon AU with Making your python code fast) and he always mentions the lazy import mechanism used by Bazaar.
Updates to jquery.xmlns.js
I've finally gotten around to updating my XML namespace selector module for jQuery. The new version fixes a few typo-related bugs and brings compatibility with the recently-released jQuery version 1.4.
Grab the source file here: jquery.xmlns.js.
Comments now via Disqus
After too many trips to the admin interface to delete spammy comments, I've finally given in and outsourced the comments on this blog. They're now hosted by disqus and I'm hoping this will help keep the spam down. Please email if you encounter any problems with the new interface
Why disqus over the alternatives such as Intense Debate? No deep functional or philosophical reason – I just happen to know disqus is a python/django shop, so in some small way supporting them is like supporting the whole python community :-)