Update:Some Curious User brought to my attention, that a ticket has been opened which, when implemented, will add a setting for a cache prefix. It will also allow other cache key manipulations.Django has implementedKEY_PREFIX in the development version, which currently means, that it will be out in 1.4 iirc.
Django 1.3 has implementedKEY_PREFIX which solves the problem once and for all.

Until recently I’ve been using the file:// django cache, but that has a “problem” when multiple users needs to manipulate the cache (think uid 80 writes a key, that uid 1000 wants to delete).

My problem with the memcached:// django cache provider has been, that it cannot handle being used on a shared memcached instance, because of the danger of key collissions.

While working on a project using PyAMF today, i was about to write a unittest of a service method, when I realized that it would be harder than necessary to make unittests of the service. The cause of this is, that there was no test client wrapper for the django test client for pyamf, which means, that to do a unittest of the gateway, you’ll have to start a django server, and run a unittest elsewhere.

Seeing as how there are a lot of benefits to using djangos own test suite (fixtures and automatic database generation to name a few), i set out to write a little test client for PyAMF to utilize django’s test client, so it would be possible to write a proper test suite.

This turned out great, and is now ticket 508 over at PyAMFs trac. Look at the client.py for the code. At some point, it will be integrated into PyAMF mainline as p.r.c.django.TestClient (or something like that).

At work we yestoday decided to update our internal url structure for our client test sites, issue management systems and such arround a bit. Seeing as we decided on purchasing a genuine signed ssl wildcard certificate, we needed to change our url’s a bit.