>>> json.loads (json.dumps( { 'one': 1, 1: 42, 451.78: "xxx", "1":"one" } ) );
{u'1': 42, u'451.78': u'xxx', u'one': 1}
>>> yaml.load (yaml.dump( { 'one': 1, 1: 42, 451.78: "xxx", "1":"one" } ) );
{'1': 'one', 1: 42, 451.78: 'xxx', 'one': 1}
>>> pickle.loads (pickle.dumps( { 'one': 1, 1: 42, 451.78: "xxx", "1":"one" } ) );
{'1': 'one', 1: 42, 451.78: 'xxx', 'one': 1}
>>> json.loads (json.dumps( { 1: "one", 2: "two", 3: "three"} ) );
{u'1': u'one', u'3': u'three', u'2': u'two'}
So what really are the benefits of converting the DikuMUD file formats to JSON?
There really aren't many, aside from making them easier for humans to read directly. But really, the area files are meant for consumption by the codebase, so this doesn't even register on my list of cares. Yeah, the Diku format is funky, but of all the things I could spend my time trying to innovate on (for the sake of my players), this is about as bottom-of-the-list as it gets.
We as MU* developers tend to gut/rewrite stuff just for giggles. Doing something like this would fall under that.
True for you. Very very not true for me. While I don't use serialized JSON for storage (because I did even more work to store pretty much everything in SQL), I frequently generate JSON formatted data I/O. Use cases include:
* A web OLC that helps make most content creation tasks 100x easier.
* A world map dump that can be read easily by a web-based cross-platform automapper.
* GMCP data packets that can be picked up by multiple custom clients (plus a Mudlet plugin) and displayed differently.
If you are not looking to do anything more with your Dikurivative's world data than you're already doing, then that's your prerogative, and making any changes is naturally pointless. Or, you can re-invent the wheel and write custom &/or hackish stuff in your server and your client enhancements (I've done it myself, so who am I to judge). Just don't say that JSON is "harmful" to a Diku codebase. There's no case to be made for that.