from __future__ import *

Kailash and Friends Kailash Kher Kaipa

simplejson is a simple, fast, complete, correct and extensible JSON (RFC 4627) encoder/decoder for Python 2.3+. It is pure Python code with no dependencies.

simplejson 1.9 is a minor update:

• Rewrote test suite with unittest and doctest (no more nosetest dependency)
• Better PEP 7 and PEP 8 source compliance
• Removed simplejson.jsonfilter demo module
• Misc. bug fixes

There is one backwards incompatible changes in this release:

• simplejson.jsonfilter is no longer included

I had the privilege last night of going to Google's Campfire One where the Google App Engine was launched, which is basically a service that I've been secretly hoping that Google would release for the past three years. App Engine is going to change everything -- as soon as they come up with a pricing model, anyway. I'm sure whatever it is will be more than competitive with Amazon's offerings, which isn't really worth any price given that they can't keep it fully operational. Yesterday was the perfect day for EC2 to fall over again, they might as well shut it off altogether once Google gets this service into production ;)

So why does Google App Engine change everything? I don't have a lot of time to spend here but a few key points:

• Single sign-on for Google users. Everyone with a gmail account is already registered for your service. You have no idea how cool this actually is :)
• BIGTABLE. My god. I would've spent in excess of $100k to have access to this part of Google's infrastructure and saved money. Scaling SQL databases sucks. If you have the kind of access patterns that we do, databases designed for OLTP are simply not suitable and it's a real pain to try and make it work. The fact that schema is managed directly in the code and that schema upgrades look awfully painless is a huge extra bonus.
• Works locally, deploys globally
• Python and WSGI!
• No more going to the data center, provisioning bandwidth from telcos, etc.
• Payment is surely coming. No more PayPal or Verisign or whatever.

In the same way that Google Apps (and Mac OS X) have enabled people to run without IT departments, Google App Engine is going to let them go big without an ops department. With the current imposed limits I can't prove this theory at Mochi Media, since everything we do is beyond the scale of their current quotas, but maybe I'll allocate some of my "infinite spare time" to ditch this Wordpress crap and try it out for my blog while they sort that out :)

The minus is that this project is actually probably pretty horrible for open source. Yahoo and the rest of the Hadoop team have their work cut out in making that stack competitive with this. If they don't, Google is going to own scale for a while. While MySQL and PostgreSQL still have some years left in them as people learn how to write scalable apps, I can't see that model lasting very long now that you don't have to be in Google's employ to use better solutions to the data problem.

simplejson is a simple, fast, complete, correct and extensible JSON (RFC 4627) encoder/decoder for Python 2.3+. It is pure Python code with no dependencies.

simplejson 1.8.1 is a major update:

• Optional C extension for accelerating the decoding of JSON strings
• Command line interface for pretty-printing JSON (via python -msimplejson)
• Decoding of integers and floats is now extensible (e.g. to use Decimal) via parse_int, parse_float options.
• Subversion and issue tracker moved to google code: http://code.google.com/p/simplejson/
• Misc. bug fixes

There is one incompatible change:

• "/" is no longer escaped, so if you're embedding JSON directly in HTML you'll want to use .replace("/", "\\/") to prevent a close-tag attack. Sorry, but the in-HTML use case just isn't worth the bloat in everyone else's documents.

simplejson is a simple, fast, complete, correct and extensible JSON (RFC 4627) encoder/decoder for Python 2.3+. It is pure Python code with no dependencies.

simplejson 1.7 is a minor update that improves encoding performance with an optional C extension to speed up str/unicode encoding (by 10-150x or so), which yields an overall speed boost of 2x+ (JSON is string-heavy). Additionally 1.7 adds support for encoding unicode code points outside the BMP to UTF-16 surrogate code pairs (specified by the Strings section of RFC 4627).

simplejson is a simple, fast, complete, correct and extensible JSON encoder/decoder for Python 2.3+. It is pure Python code with no dependencies.

simplejson 1.6 is a minor update that improves str support for encoding. Previous versions of simplejson integrated strings directly into the output stream, this version ensures they're of a particular encoding (default is UTF-8) so that the output stream is valid. See the documentation for more information.

simplejson is a simple, fast, complete, correct and extensible JSON encoder/decoder for Python 2.3+. It is pure Python code with no dependencies.

simplejson 1.5 is a major update that provides better Python 2.5 and Windows compatibility, and two new features that control encoding (indent for pretty-printing, and separators for generating optimally compact JSON). See the documentation for more information.

MochiAds is finally out the door! There's a pretty good summary of what we're doing on TechCrunch.

For the technically inclined, the UI for MochiAds is built with Pylons, Genshi and SQLAlchemy. The secret sauce is a combination of Python and Erlang code, and we've got Nginx as the gatekeeper. I've got nothing but good things to say about this whole stack. Erlang's module reloading, concurrency oriented programming model, and pattern matching has really been a dream.

For Flash game developers, we support ActionScript 1, ActionScript 2, and MTASC. Flash movies must be published in Flash 6 or later. Currently we support two ad formats: preloaders and interstitial ads. Either way it's just one line of code to toss in the movie.

The really Big Deal is that Flash game developers can make money off of their work throughout the entire lifespan of the project, especially if it spreads virally. It's no longer a bad thing if a portal "steals" the game without paying a licensing fee, the developer still gets paid!

I was benchmarking egeoip today, which is my from-scratch Erlang geolocation library. It uses the MaxMind GeoLite City database, which has implementations in a bunch of other languages so it's great to compare with. The results were rather surprising to me, because I hadn't previously done any benchmarking of Erlang performance.

The test environment is a MacBook Pro 2ghz, Mac OS X 10.4.7, Erlang R11B-1 w/ HiPE enabled, Python 2.4.3 (using their GeoIP Python API, which is written in C). I do have other processes running (namely iTunes), but the benchmark is fair because the background load is consistent throughout the tests.

Erlang, BEAM:

~13k geolocations/sec

Python/C:

~18k geolocations/sec

Erlang, HiPE:

~44k geolocations/sec

As you can see, Erlang holds it own against Python w/ C extensions, and it can mop the floor with it when using the HiPE compiler. Erlang clearly kicks some serious ass at working with binaries, both in syntax and performance. The only work I had to do to make it faster was c(egeoip, [native]).

Note that I've only been using Erlang for a few weeks and have not done any profiling or performance tuning at all beyond what I assumed would be the fastest way given the documentation I had read.

The slides from my MochiKit Intro talk at The Ajax Experience 2006 are up:

http://svn.mochikit.com/presentations/2006/ajax_experience/slides.html

They were built with a slightly modified s5 (so that I could toggle an interactive mode with ctrl-i to demonstrate MochiKit inline without advancing the slides), using the docutils rst2s5 tool.

The reStructuredText source, build scripts, etc. are all in the repository here:

http://svn.mochikit.com/presentations/2006/ajax_experience/

It's been a pretty long haul getting Python to do the right thing on Mac OS X with regard to Universal Binaries. The dust is settling, and it's about time to start publicizing the results.

In order to compile extensions with Universal MacPython, you absolutely must have the latest version of Xcode installed. When you install it, make absolutely sure that you Customize the installation and install the Mac OS X 10.4 Universal SDK. Universal MacPython requires this SDK to be installed, as it instructs the compiler and linker to use this specific SDK. There is a hook that will remove these special flags, but ONLY for legacy Mac OS X 10.3.9 users. Mac OS X 10.3.9 users should still be able to compile extensions, but the resultant binaries will be PPC only and shouldn't be distributed (as they will not work on Intel).

Besides the obvious endian fixes and distutils/configure hackery, Universal MacPython includes many usability enhancements over previous distributions of Python for Mac OS X:

• IDLE, the Python IDE, should now ship with Mac keybindings and menus by default
• Placing binaries in /usr/local/bin is now optional
• The bin directory from the framework is now (by default) automatically added first to your PATH environment variable. This means that when you open a new terminal session and type python, you will get Universal Python 2.4.3. Yes, it's ugly to do this, but it's a necessary evil. PATH related issues are by far the most frequent source of confusion on pythonmac-sig (between Python itself and distutils-installed scripts), and this is the solution. darwinports does something quite similar.
• pythonw is now an executable, instead of a shell script, so it may be used directly in a hash-bang line for a shell script (#!).
• Users no longer need to know or care about pythonw. python and pythonw are the same binary, which simply does an execve to a Python executable inside of a "fake" application bundle to placate the WindowServer. Yes, this introduces a tiny little bit of overhead when invoking python due to the extra syscall, but it is again a necessary evil to work around a design flaw in Mac OS X.
• Includes a working bsddb, readline, and curses.
• Known compatible with Mac OS X 10.3.9 and later, without any patching necessary on Mac OS X 10.4.

The latest Universal Python source code is currently a fork of Python 2.4.3, and currently resides outside of the official Python subversion repository. For those interested in the source, it is here:

• http://svn.pythonmac.org/python24/python24-fat/

The latest binary release of Universal Python is currently available in the Universal Python 2.4 section of pythonmac.org packages! There is/was an older Universal Python build available somewhere on python.org but it is NOT what you should be using (it's built without compiler optimization and is roughly 50% slower on either architecture!):

• http://pythonmac.org/packages/py24-fat

PyObjC and py2app users with Universal MacPython should install PyObjC from SVN trunk (which will net you a universal-ready py2app). There is currently no tagged release of either project that is suitable for this build of Python, but we hope to fix that soon:

• http://svn.red-bean.com/pyobjc/trunk/pyobjc/
• http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint/

pythonmac.org packages has been split into two sections, one for universal packages, and one for legacy builds of Python. Currently there aren't many universal packages ready (largely because I don't have an Intel machine yet, so I can only test on PPC). The legacy packages for Python 2.4 are still compatible with Universal MacPython, however, they are NOT compatible with Intel.

Most packages should compile just fine, and setuptools/easy_install are already Universal MacPython aware. However, packages that depend on external libraries will not compile correctly of the dependent libraries aren't also Universal. This means that MySQL bindings, wxPython, and a few other popular packages are not yet readily available. This issue will resolve itself at some point due to the demand, but it's not resolved yet. There's a list of desired packages and their status at the UniversalPackages node on the pythonmac.org wiki.