making apps, making webs.

I've done some quick benchmarks for the unreleased python3.2 on the unreleased cherrypy webserver for python 3. Also with the unreleased python2.7. Here are the results... python3.1 Client Thread Report (1000 requests, 14 byte response body, 10 server threads): threads | Completed | Failed | req/sec | msec/req | KB/sec | 25 | 1000.0 | 0.0 | 533.32 | 1.875 | 93.75 | 50 | 1000.0 | 0.0 | 525.86 | 1.902 | 92.69 | 100 | 1000.0 | 0.0 | 522.96 | 1.912 | 92.1 | 200 | 1000.0 | 0.0 | 523.83 | 1.909 | 92.25 | 400 | 1000.0 | 0.0 | 506.92 | 1.973 | 89.27 | Average | 1000.0 | 0.0 | 522.578 | 1.9142 | 92.012 | python3.2 Client Thread Report (1000 requests, 14 byte response body, 10 server threads): threads | Completed | Failed | req/sec | msec/req | KB/sec | 25 | 1000.0 | 0.0 | 555.72 | 1.799 | 97.78 | 50 | 1000.0 | 0.0 | 558.86 | 1.789 | 98.52 | 100 | 1000.0 | 0.0 | 552.87 | 1.809

Invent with python 'Teach yourself how to program by making computer games!' is a free book now in its second edition. It is released under the creative commons licence Attribution-Noncommercial-Share Alike 3.0 United States - and the author just asks for a donation if you liked reading it. The book takes the fun approach of teaching programming through making games... the way many of us learnt(and are still learning) to program. As a bonus it uses python 3 - which pygame has supported for a while. Congratulations to Albert Sweigart for finishing his second edition of the book.

Integrated modules are nice, but so are modular packages. How can we have both? That is, keep all things for a module(or sub package) in one directory, but also have a nice integrated system built on top of that? Often for one package I will have a file layout like so: /setup.py /[package_name] /[package_name]/[package_module].py /[package_name]/tests/[package_module]_test.py /[package_name]/examples/[package_module].py /[package_name]/docs/[package_module].py Then each module has its tests, docs, and examples all mixed in the one directory. This is nice if you want to have all of the tests together, and all of the docs, and examples together. However then all of the modules are mixed in together. Meaning it is harder to separate them, and keep one module in its own directory. Having everything for one thing together is nicer for developers I think. Using namespace packages through setuptools distribute is one way. There is a draft pep around to put namespace packages into python

Using a hash with a salt is one way of validating urls. With it you can tell that it is quite likely the url was generated by someone with a secret. That is, generated by someone authorised to make that url. This post describes using this technique with the hmac python module applied to urls(and object method calls). Generating thumbnail urls is a good example. If you have a url which can generate a thumbnail of an image at a specified size that is pretty cool. Except then you can have someone generating images at all sorts of other weird sizes by exploiting the width, and height parameters (eg making 100,000 pixel wide thumbnails). Or perhaps you want to limit it to a certain set of images. You could always code in your thumb nail generating routine which variables are valid... but this has problems. First it makes your routine less flexible. Separating authorisation is always a nice idea. Another way (with HMAC like using pywebsite.signed_url) is to generate the urls and add

In Switzerland. Had fun visiting an old friend and his new girl friend. Lots of snow came whilst we're here which was fun. However, the planes didn't like it, and they got cancelled. So going back to London today instead(if the planes work).

The unladen swallow project comments on the global interpreter lock and suggests long term dropping reference counting in favour of GC. http://code.google.com/p/unladen-swallow/wiki/ProjectPlan#Global_Interpreter_Lock . They are also now favouring an incremental GIL removal from python. However, confusing getting rid of the GIL, with requiring using garbage collection is wrong. This mini-essay will explain why reference counting is good for python, and why you do not need to get rid of it for multiple CPU systems. Then there will be descriptions of other improvements to python for multiple CPU systems that can be made. Reference counting has a number of advantages over various GC schemes see http://en.wikipedia.org/wiki/Reference_counting#Advantages_and_disadvantages . As a python programmer, optimizing for the programmer is what is most important... and reference counting makes it easier for the programmer. It makes programs much more deterministic, meaning that reference counti

Writing for the latest python version is just simply... fun. Even the name 'python 3000' or py3k is amusing. It's been a joy over the last week plugging away at a few personal website and game projects using the latest python version. Over the last year I've been involved in upgrading existing code to the latest versions of python... but not really in writing it JUST for the latest versions. No need to consider backwards compatibility problems... older pythons be damned when programming for fun! I'm able to take advantage of the latest python features in deep architectural ways. To fiddle around with the new deep magic python internals. But the new deep magic parts aren't the best bits though... it's all the elegant little improvements that make a difference. It is of great delight finding python 3 compatible modules. It turns out that the modules available for python 3 are often of quite good quality - and well maintained. There's not all that

The sqlite and pickle modules that come with python are quite useful. So lets mix them together and see what comes out. SQLITE Vs PICKLE pywebsite.sqlitepickle is a little module I just made which combines sqlite and pickle for persistence. Useful since it works with python3, and both pickle and sqlite are included with pythons (including pypy). Import the module. >>> from pywebsite import sqlitepickle An in memory db. >>> db = sqlitepickle.SQLPickle() >>> db.save('key', 'value') >>> db.get('key') 'value' Can also save to a file. So we first get a temp file name. >>> import tempfile >>> f = tempfile.NamedTemporaryFile() >>> fname = f.name >>> db = sqlitepickle.SQLPickle(fname) >>> db.save('key', 'value') >>> db.get('key') 'value' >>> db.close() The issues with this are that sqlite does not like sharing conn

Play cards. They're like business cards, but take 30 minutes to make five. Also, they are for handing out to people you want to play with, rather than to people you want to do business with. Well it could be used for both... but I think the normal style business card is a bit boring to give to friends. Made some of these the other day. Based on an earlier version I designed a few years ago. They're about the size of a finger, but unfold to show other details (eg, email, website, etc). --

Here is an example buildout project that uses numpy: https://launchpad.net/numpybuildout/ If you have bazaar, you can check it out like so: cd /tmp/ bzr branch lp:numpybuildout cd numpybuildout/trunk/ To use distribute instead of setuptools use the -d flag of bootstrap.py. python bootstrap.py -d ./bin/buildout ./bin/py >>> import numpy >>> numpy.__file__ '/tmp/numpybuildout/trunk/eggs/numpy-1.4.0-py2.6-linux-i686.egg/numpy/__init__.pyc' There you have it, a simple project that can download and build numpy off of the python package index and install it in it's own private directory for use. update: It was broken for python2.6 and numpy 1.3. However it works again with numpy 1.4

gvim in ubuntu karmic koala is really annoying. It prints out a bunch of gtk warnings each time you call it. However thanks to someone making a patch, you can clean it up. It seems that the fix isn't going to come out until the next ubuntu. ** (gvim:13354): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:13354): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:13354): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:13354): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:13354): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed Very annoying to see that every time you edit a file. https://bugs.launchpad.net/ubuntu/+source/vim/+bug/402188 So instead of switching to arch linux, or gentoo linux... or one of the other developer centric distros t

Arrived back in London a few days ago, after a month living in Berlin. I really enjoyed Berlin, and thought about staying there for longer... but in the end decided against it for now. Would really like to visit in the summer, when it's apparently quite a different place! Some pictures from Berlin Finding the bustle and life on the streets of London quite refreshing. I think I'll be based in London for the next six months or so at this point(probably longer). Going to the london python dojo again on the 10th. This is an interesting format for a get together. People take turns pair programming with a projector, whilst the rest of the people in the room offer comments. This time there's going to be a few short interactive presentations too. It was nice meeting python people from around London last time. Fry-it are the hosts, who offer their office, pizza(+salad) and beer(+wine) for everyone at each dojo.