Question about a general tempting plan

Kostia Balytskyi ikostia at
Wed Mar 2 09:58:14 EST 2016

A follow-up question about it.
Why did we implement custom json serializer instead of using something
like `json.dumps`? I see that our formatter has to support incremental
supply of data (e.g. flows like "(1) get first object data (2) print first
object data (3) get second object data (4) print second object data"
instead of "(1) get all objects data (2) print all objects data"). But
this could still be implemented with `json.dumps` at least on the second
level (topmost list we process manually, second level is processed by a
I guess, what I'm interested here is: would people object if I try to
reimplement it the way I described? I want it to support more than one
level of included lists/objects, like this:
#this works
    opts['template'] = "{l1 % '{l2 % \'{l3}\'}'}\n"
    obj = {'l1': [{'l2': [{'l3': 'v'}]}]}
    fm = ui.formatter('tf', opts)

    # this fails
    opts['template'] = 'json'
    obj = {'l1': [{'l2': [{'l3': 'v'}]}]}
    fm = ui.formatter('tf', opts)


On 3/1/16, 7:19 PM, "timeless.bmo1 at on behalf of timeless"
<timeless.bmo1 at on behalf of timeless at> wrote:

>On Tue, Mar 1, 2016 at 8:51 AM, Yuya Nishihara <yuya at> wrote:
>> On Mon, 29 Feb 2016 18:40:13 -0500, timeless wrote:
>>> Please note that temporarily the json format is intentionally
>>> because we (=me) are trying to unify the names of identifiers.
>> Is the JSON log format still experimental?
>> I know the other -T options are experimental, but I haven't thought
>>"log -Tjson"
>> was.
>Yes, absolutely. It's intentionally undocumented because of
>inconsistencies and because the act of documenting it would
>flash-freeze any future inconsistencies.
>I sent a patch a while ago to document it, and it was rightly rejected
>for this reason... I'm actually not sure how we'll avoid the
>flash-freeze problem.

More information about the Mercurial-devel mailing list