[Chicago] Help wanted: Python/JS Reflection library

Pete pfein at pobox.com
Thu Apr 5 02:41:15 CEST 2007

On Wednesday April 4 2007 6:40 pm, Ian Bicking wrote:

Heh.  I just addressed this on the other list.  Sorry for the cross-post....

> Well, the object models of JSON, Javascript, and Python don't actually
> match up.  Of course you can't actually share objects anyway, since JSON
> is a document and Javascript and Python will each have their own
> distinct copies of the object.  And "class" can't really be shared
> either, since class implies methods, and methods imply code, and there

The goal here is *not* to produce JSON for arbitrary client libraries (or 
plain-old Javascript-sans-library).  The goal is to produce something:
 * human readable/editable
 * with just enough metadata to allow a library in another language 
(Javascript or other) to construct an instance, *assuming it already has a 
corresponding class definition*
 * is still valid JSON

Maybe an example will help.  My code currently produces JSON that looks much 

  "__class__": "Foo",
  "color": "red",
  "size": 42,
  "quux": {
    "__class__": "Bar",
    "drink": "whiskey"
  "when": {
    "__class__": "datetime.date",
    "day": 4,
    "month": 4,
    "year": 2007

This is done entirely via introspection/piggybacking on existing serialization 
methods - there's no explicit support from Foo or Bar required.  The idea is 
that some library in language L can take this data structure, which consists 
solely of JSON datatypes,  and build a corresponding data structure in its 
native types/user-defined classes. And vice versa.

This isn't code shipping - I'm assuming the same person writes the code on 
both ends.  If you forget to define a Foo in L, that's your bug, not 
mine. ;-)  It's nothing more than a convention for getting object-oriented 
data across language boundaries.  Maybe I'll call it Esperanto.[0]

> Messages can work, which is what JSON is typically used for.  Messages

'Message reflection' might a better term than 'object reflection'.  The idea 
is to provide some helpers that let you load up the message into an existing 
class definition.  It's no more featureful than a bunch of functions that 
operate on plain-old JSON data structure.  Just adds some sugar.

> binary version might be bencode (http://en.wikipedia.org/wiki/Bencode),

Looks like a binary JSON. Neat.

> wire.  I think these questions make RPC systems hard to work with.

-1 RPC.  Maintaining state across the wire is a generally bad idea.


[0] - I'm not actually gonna call it Esperanto.  Grunt-point may be a better 

Peter Fein   ||   773-575-0694   ||   pfein at pobox.com
http://www.pobox.com/~pfein/   ||   PGP: 0xCCF6AE6B
irc: pfein at freenode.net   ||   jabber: peter.fein at gmail.com

More information about the Chicago mailing list