Show HN: Python JSON library in Rust, faster than ujson
1–5 of 5 posts
Re: Show HN: Python JSON library in Rust, faster than ujson
#2This is the kind of thing that Rust can do so well -- export high performance, safe and trustworthy functionality to any language that can bind with native code.
C/C++ does everything but the safe and trustworthy part.
Re: Show HN: Python JSON library in Rust, faster than ujson
#3> It raises TypeError on an unsupported type or a number that is too large.
Why does it raise an error on "a number that is too large"? The JSON spec does not put any limit on the size of numbers. Practically speaking, integers that don't fit in 53 bits won't be preserved when decoded by JavaScript and some other libraries, and integers that don't fit in 64 bits will likely not be preserved by most libraries, but as far as the JSON spec is concerned you can have integers of any size (or floating-point numbers of any precision).
Re: Show HN: Python JSON library in Rust, faster than ujson
#4> It raises TypeError on an unsupported type or a number that is too large. Why does it raise an error on "a number that is too large"? The JSON spec does not put any limit on the size of numbers. Practically speaking, integers that don't fit in 53 bits won't be preserved when decoded by JavaScript and some other libraries, and integers that don't fit in 64 bits will likely not be preserved by most libraries, but as…
JSON doesn't support NaN or infinity, so most JS implementations emit null for NaN, +Inf, -Inf. In Node:
> JSON.stringify({nan: 0/0, inf: 1/0, neginf:-1/0})
'{"nan":null,"inf":null,"neginf":null}'
Re: Show HN: Python JSON library in Rust, faster than ujson
#5> It raises TypeError on an unsupported type or a number that is too large. Why does it raise an error on "a number that is too large"? The JSON spec does not put any limit on the size of numbers. Practically speaking, integers that don't fit in 53 bits won't be preserved when decoded by JavaScript and some other libraries, and integers that don't fit in 64 bits will likely not be preserved by most libraries, but as…
JSON doesn't support NaN or infinity, so most JS implementations emit null for NaN, +Inf, -Inf. In Node: > JSON.stringify({nan: 0/0, inf: 1/0, neginf:-1/0}) '{"nan":null,"inf":null,"neginf":null}' I'm not sure if throwing an exception is better or worse.
Ok, but the line I quoted wasn't about infinity, it was about numbers that were "too large", which I assume means bignums.