Add to_json function, that would eventually output json

[offlinehacker]

As we already know result from serializer resemble json, but not really(every element has eventually string type). I think a function is needed that would serialize a data and output json, because that's what you need in REST services.

@plamut is working on json schema in #112, but there's not even a proper function that would output json. I would do it, but i don't know what's the proper way, because serializer does not give me type information, so output from it is not very usefull. As far as i understand a parallel implementation(to serializtion) would be needed, but wouldn't it be just simpler for serializer to output json and preserve type information this way, or are there any other issues i'm not aware of?

[mcdonc]

See https://github.com/plamut/colander/tree/json_support_iss112 for an initial stab by @plamut

[mcdonc]

Oops, no, sorry, that's wrong.. that branch deals with json schemas, not json data.

[offlinehacker]

Yep, that's the catch :)

Do you have any suggestions how to implement json data output? I have enumerated a couple of options above.

On Tue, Aug 20, 2013 at 4:56 PM, Chris McDonough notifications@github.comwrote:

Oops, no, sorry, that's wrong.. that branch deals with json schemas, not json data.

— Reply to this email directly or view it on GitHubhttps://github.com/Pylons/colander/issues/133#issuecomment-22950864 .

[hathawsh]

See my comment attached to #80. In my own project I've added NativeInteger and NativeBoolean classes that do what you want. Whereas Integer converts a str to an int and back, NativeInteger simply converts everything to an int both ways. I'd like feedback on the idea before I create a patch for colander. Are you interested, @offlinehacker and @mcdonc?

[offlinehacker]

Sounds interesting, but what about just having to_json function that would handle that without extra types(extra types reduces compatibility with deform for example). I would implement it by having paralel implementation (that would basicly just convert to correct type). At the same time there are some pyramid types that are not json serializable and we would simply not serialize them, but just raise a warning or exception.

On Thu, Aug 22, 2013 at 11:08 PM, Shane Hathaway notifications@github.comwrote:

See my comment attached to #80https://github.com/Pylons/colander/issues/80. In my own project I've added NativeInteger and NativeBoolean classes that do what you want. Whereas Integer converts a str to an int and back, NativeInteger simply converts everything to an int both ways. I'd like feedback on the idea before I create a patch for colander. Are you interested, @offlinehacker https://github.com/offlinehacker and @mcdonchttps://github.com/mcdonc ?

— Reply to this email directly or view it on GitHubhttps://github.com/Pylons/colander/issues/133#issuecomment-23126024 .

[leorochael]

Keep in mind that Javascript (from where json came from, and with whom json is frequently used for communication) doesn't actually have proper integers, and you could silently lose information in the event of a roundtrip of a json structure through Javascript:

http://cdivilly.wordpress.com/2012/04/11/json-javascript-large-64-bit-integers/

[jimbru]

Just curious, has anyone made any progress on this? It's a feature I'd love to see. @hathawsh If you have a patch (even if it's hacky), I'd find it useful.

[mmerickel]

We've discussed modifying the serialization format of colander to use json inherently in a major version update (colander 2). I'm not shooting down this ticket outright, but I'm fairly certain that the to_json mechanism has less of a chance of getting accepted than fundamentally fixing colander's annoying string-based format. That being said, I've talked to @mcdonc several times about changing to json and he's been amenable to the idea as long as deform2 gets updated to work with it.

[jimbru]

Thanks for the response, @mmerickel. Just to put it out there, adding to_json might be a good intermediate solution. It could solve this issue (for users that care) in a relatively short term without completely changing the serialization format for the library as a whole. Regardless, I may take a crack at a json mode for my personal use. As it turns out, there aren't a lot of alternative Python json validators.

[mmerickel]

The colander "pace of development" isn't exactly staggering, so I'd think that making your own custom types (like NativeInteger which serializes to an int instead of str) for your project has a better chance of helping you out. Either way the colander api would be using appstructs and cstructs, so you'd still have to actually serialize the cstruct to json.

[sirex]

+1 for to_json or anything, that preserve primitive types, serializable to json.