homepage

Hi there!
According to http://www.ietf.org/rfc/rfc4627.txt . The JSON object is either a list or a dictionary with other elements in it. However Python's implementation took liberty to parse also basic types, like integers, strings, floats, etc. For example:
>>> import json
>>> json.loads('42')
42
>>> json.dumps(3.141592)
'3.141592'
It wouldn't be a problem if other implementations would adhere to this behavior, but this is not true. Take Ruby for example:
irb(main):007:0> require 'rubygems';
irb(main):008:0* require 'json';
irb(main):009:0* JSON.parse '42'
JSON::ParserError: 743: unexpected token at '42'
	from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:148:in `parse'
	from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:148:in `parse'
	from (irb):9
	from :0
irb(main):010:0> JSON.generate(3.141592)
JSON::GeneratorError: only generation of JSON objects or arrays allowed
	from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:216:in `generate'
	from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:216:in `generate'
	from (irb):10
	from :0
Also http://jsonlint.com/ considers it an error.
I know this is not very important, but I've ran into this today when trying to parse JSON in Ruby which was produced in Python.
I've made a patch for that, but I still need to fix tests and there are many of them. I first would like to know if it is going to be fixed, then I will complete the patch.
Thanks for Python, anyway!
Tomek

I don't see any way of changing this without breaking lots of code that currently works fine. It may be possible to add a strict-mode (off by default) or to add warnings.

I wonder if there are concrete use cases for loading/dumping basic types.
I see two options here:
1) we decide that load/dump should accept and produce only complete json object and go through a deprecation process, raising warnings first and errors then;
2) we decide that the correct behavior (loading/dumping basic types) is fine and that should be up to the user to check if the document has an array/object at the top level and then just document it (if it's not documented already).

It wouldn't be a problem if 'json' library would be a thing specific to Python. But JSON is used to gule together different technologies and programming languages. I'm afraid that the default behavior should be 1).

I'm thinking that we should offer a strict-option (off by default) and leave it at that. No need to break existing code. AFAICT, the OP is the only one to have had problems with this in-practice (the JSON module or its ancestor simplejson has been around for a long time).
Am marking this as a high priority but want to leave it open for a good while to get more comments before taking any action.

Agreed that a strict parameter would be a good idea to implement this.
Since it's technically a new feature (and not that important), I think only 3.3 should receive it.

I'm not sure adding a strict option is a good idea. HTMLParser got a strict argument and it's causing more problems than it solves. If another problem comes up later we would either have to change the behavior for strict and break code that by then is using strict=True or add yet another really_strict argument.

> HTMLParser got a strict argument and it's causing more problems than it solves.
Funny, I used the strict mode to solve a parsing bug in a personal project.

>> HTMLParser got a strict argument and it's causing more problems than it solves.
> Funny, I used the strict mode to solve a parsing bug in a personal project.
See http://bugs.python.org/issue7311#msg133075 and following messages.r

Assigning back to me (the current maintainer of the module).

> HTMLParser got a strict argument and it's causing more problems than it 
> solves.
Well, HTML is a big can of worms while JSON is a rather clean format. We can hope that adding a strict argument to json wouldn't cause such problems.

Take a look at http://bugs.python.org/issue14674.
A proposed documentation patch specifically discusses this issue.

The strict flag sounds good to me, too. I don't think it should be called "strict" though, as that would imply that we comply with RFC 4627 strictly (which is not true without passing allow_nan=False for dump() or passing a parse_constant function for load()). How about "encode_any" and "decode_any" or "any_value"?
Deprecation doesn't sound good to me. If the feature is already there, it probably has its users and use cases.

I think it's worth pointing out that both Firefox and Chrome support the non-standard JSON that Python supports (serializing and deserializing basic types). I'm guessing that communicating with web browsers is the vast majority of JSON IPC. That is to say, supporting the de-facto standard implemented by web browsers may be better than adhering to the exact specifications of the RFC.
Maybe someone else wants to check what IE, Safari, Opera, and the various phone browsers allow as that might influece the discussion one way or another.

> I don't think it should be called "strict" though, as that would imply that we comply with RFC 4627 strictly
> (which is not true without passing allow_nan=False for dump() or passing a parse_constant function for load())
What if the strict mode implied both of these things?
FWIW, I’m +1 for a doc section about how to achieve strict mode with special arguments and callbacks (if the recent doc patch does not already have that), and +0 on adding it to the code itself.

> FWIW, I’m +1 for a doc section about how to achieve strict mode with special arguments and callbacks (if the recent doc patch does not already have that)
The docs added by that patch do indeed cover this:
http://docs.python.org/2/library/json.html#standard-compliance 

Note that, per the new JSON RFC 7159 (https://tools.ietf.org/html/rfc7159 ), top-level non-collection values are now de-jure permissible in JSON:
> Appendix A. Changes from RFC 4627
> o Changed the definition of "JSON text" so that it can be any JSON
> value, removing the constraint that it be an object or array.

As Chris Rebert mentioned, the JSON standards have adopted this (unsurprising) behavior. Ruby hasn't, and I doubt Crockford has, but I think they're in the minority at this point. JavaScript's own JSON implementation works the same way json/simplejson does.
> JSON.parse(JSON.stringify('yay'))
"yay"
At best, I think it's probably worth a mention in the documentation, but not worth changing any code over.

In other words, I would consider this to be fixed by the documentation change made elsewhere.

Okay, so can this issue be closed in light of the existing docs and issue 21514 then?

Ping!
Seems like this should be closed since the new RFC explicitly legalizes the feature in question and since the docs explicitly warn about the interoperability of the feature.