[Web-SIG] Time a for JSON parser in the standard library?
jmillikin at gmail.com
Wed Apr 9 21:14:39 CEST 2008
On Wed, Apr 9, 2008 at 10:05 AM, Ian Bicking <ianb at colorstudy.com> wrote:
> I strongly prefer we stick to the conventional names of dump/dumps/load/loads, for consistency with other serialization libraries already in Python.
On Wed, Apr 9, 2008 at 10:27 AM, Benji York <benji at benjiyork.com> wrote:
On Wed, Apr 9, 2008 at 10:28 AM, Duncan McGreggor
<duncan.mcgreggor at gmail.com> wrote:
> +1 for me too.
PEP updated to use dump/dumps/load/loads
On Wed, Apr 9, 2008 at 11:38 AM, Alan Kennedy <pywebsig at xhaus.com> wrote:
> Answer #2: I'm working (i.e. day job) with JSON at the moment: a
> last week with a sample JSON document I gave him to prototype on. I
> wrote the sample by hand (it later became my freemarker template), and
> so inadvertently left in a hard-to-spot dangling comma, from all the
> problem by passing it through a PHP JSON codec on his local Apache. It
> worked, i.e. his problem disappeared, but he didn't know why (the PHP
> lib had eliminated the dangling comma). Which all goes to confirm,
> IMHO, that you should be liberal in what you consume and strict in
> what you produce.
Sounds like a case *for* strict parsing, in my opinion. PHP's loose
parsing made it difficult to figure out why the JSON was invalid. If
trailing comma handling is to try to work around copy-paste errors, -1
> I'm beginning to think that any putative JSON API should permit the
> user to specify which class will be used to instantiate JSON objects.
> If the users can specify their own classes, that might go a long way
> Numbers representing radians to my python server which uses Decimal
> because it works better with my geo-positioning library". Standard
> libraries should provide their own set of default instantiation
> classes, which the user could override.
This is the float v. Decimal thing again -- load(s) might grow a
parameter for that, since it's hard to be both fast and correct. But
what is the use case for overriding the mappings for other JSON types,
like arrays or objects? If given the choice, I'd rather have a very
simple API in the stdlib that can be wrapped or implemented by third
parties if they need something weird, than a large API that is
difficult to implement fully.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: json pep.txt
More information about the Web-SIG