If an object has a __json__ method, use it when encoding

[mitar]

It should return a raw JSON string which will be directly included in the resulting JSON when encoding.

Similar to #130, but it allows an object to return already encoded string which is then included as it is in the output. This allows one to pass embed existing JSON strings inside a larger structure, without a need to deserialize and serialize again.

[mitar]

Fixed Travis CI tests.

[rodrigopr]

+1 for this feature

[snario]

+1

[tupy]

+1

[gabrielpjordao]

+1

[rafaelverger]

+1

[caio-nas]

+1

[andersonba]

+1

[marciovicente]

+1

[helielson]

+1

[tekknolagi]

+1 and bump. @esnme?

[tekknolagi]

@jskorpan

[marcgear]

+1

[Jahaja]

Thanks, Looks good. The only problem I could see with this PR is that it means that ujson.encode can output invalid json and it could be pretty hard to find such a bug. But I guess it's the risk you'll take if you try to optimise using stuff like this.

[mitar]

Yes. I do not think we should try to verify that. This is your responsibility. Luckily, JSON is nicely recursive, so if the output of __json__ is valid JSON, then also the whole result is valid JSON.

[Jahaja]

Agree, thanks again.

[Jahaja]

Hi @mitar, What's the use-case that warranted this particular change? It looks like this is a performance regression.

[mitar]

So that one can have strings with __json__ method. If a string does not have __json__ method, we go by the normal flow, if it has, we use it.

[Jahaja]

So far I did follow. But not why one would need it. What's the actual use-case for that? Furthermore why would only the string type have a __json__ method but not the other types?

[Jahaja]

I'll leaning towards removing this and thus limiting the __json__ functionality to objects.

[mitar]

So the idea is a bit that you can have a magical string, which behaves in one way when used as a string, but another (optimized) when used as a JSON. Specifically, you can have a JSON serialization, which is a string, but also when serialized, it is not converted to a string (so no double encoding), but output directly, because it already contains a proper JSON serialization.

Example use for me is how to properly serialize GeoJSON Django fields. I create a GeoJSON string class, and then returned it as an optimized value. In this way existing codebase which expects strings work well, but when the time for serialization to JSON comes, one can quickly render JSON, because it is already there. Moreover, if you serialize to XML, instead, then the string is used as string, so you get embedded JSON inside XML, which is also good in the case of GeoJSON.

[Jahaja]

Thanks for the explanation. However this is too much of an edge-case to justify the performance penalty as it stands.

[mitar]

OK.

[mitar]

Curious, what was the % of the performance hit in your tests because of that?

[Jahaja]

It was the cause if this one: #223