Documentation: some node_location() examples

[sdolenc]

I recently referenced jsoncfg's node_location() in an answer on stackoverflow

https://stackoverflow.com/questions/55684780/get-line-number-while-parsing-a-json-file/63621669#63621669

I noticed there aren't many invocations of node_location() in the current documentation. I'm hoping we could copy my answer from stackoverflow (or variation) into the jsoncfg's documentation. I think it'll help illustrate the power of node_location() and how it can be used to print the location of any key or value in a json file. Thoughts?

[pasztorpisti]

Hi

Thanks for raising this issue.

If someone starts using json-cfg as a generic json parser then the description of node_location() is quite clear and easy to find in the documentation. People would probably search for "line" and "column" and find what they need.

The real question is the following: Does anybody want to use json-cfg as a general purpose json parser? I think the answer is no because:

• json-cfg isn't optimized: it's slow pure python without native C/C++ modules
• It has optional support for non-standard json extensions (trailing commas, comments, ...) that might be a tempting but bad idea in case of general purpose json data

In theory it would be possible to extract a general purpose json-parser library from json-cfg and rewrite it in C/C++ and then create a native json parser python module based on the C/C++ json library (and then rewrite json-cfg to use that native json parser python module) but does the world need another optimized JSON parser with some extra features?

I haven't performed the above refactor because I didn't believe it would worth the time. This is why the slow json-cfg package advertises itself as a config parser and has some identifier names that contain "cfg" or "Config". Loading a few config files with a slow json-cfg parser (typically at application startup) isn't a huge issue and the improved error reporting feature is worth the performance hit especially in case of large config files. Using the current slow json-cfg is a bad idea in case of processing high volumes of json data.

I witnessed few philosophical debates about the viability of json as a config format. IMO most popular formats have some cons and pros. In practice there are quite a few apps using json as the config format and they can be quite annoying without a library like json-cfg. This is why I wrote this package to ease the pain.

[sdolenc]

I agree no further documentation changes are necessary.

Thanks for the additional context and thought-process behind json-cfg. I completely agree that one of the best scenarios for json-cfg is parsing configuration files. I've used it for parsing Azure Resource Manager (ARM) templates json. It worked perfectly. Thanks for the great package 👍

[pasztorpisti]

The raised issue is completely valid. It would sometimes be very useful to have line+column info in fast general-purpose json parsers.

I should either refactor this lib at some point (by extracting a generic json parser and optimizing it) or put something into the documentation about the potentially slow performance of the current implementation.

I'm glad that the package was good/fast enough to help you and your project.

[schosterbarak]

is there a way to get the end line of an element (if it a dict printed over a few lines for example)?

[pasztorpisti]

@schosterbarak the end line isn't stored by this implementation