[issue13212] json library is decoding/encoding when it should not

Changes by Serhiy Storchaka : -- resolution: -> wont fix stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ ___

[issue13212] json library is decoding/encoding when it should not

Chris Rebert added the comment: 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. -- ___ Python tracker

[issue13212] json library is decoding/encoding when it should not

Chris Rebert added the comment: Okay, so can this issue be closed in light of the existing docs and issue 21514 then? -- ___ Python tracker ___ _

[issue13212] json library is decoding/encoding when it should not

Bob Ippolito added the comment: In other words, I would consider this to be fixed by the documentation change made elsewhere. -- ___ Python tracker ___ _

[issue13212] json library is decoding/encoding when it should not

Bob Ippolito added the comment: 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. > J

[issue13212] json library is decoding/encoding when it should not

Changes by Raymond Hettinger : -- assignee: rhettinger -> bob.ippolito nosy: +bob.ippolito ___ Python tracker ___ ___ Python-bugs-list

[issue13212] json library is decoding/encoding when it should not

Chris Rebert added the comment: 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 >

[issue13212] json library is decoding/encoding when it should not

Chris Rebert added the comment: > 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-co

[issue13212] json library is decoding/encoding when it should not

Éric Araujo added the comment: > 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 bo

[issue13212] json library is decoding/encoding when it should not

Aaron added the comment: 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

[issue13212] json library is decoding/encoding when it should not

Changes by Chris Rebert : -- nosy: +cvrebert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue13212] json library is decoding/encoding when it should not

Petri Lehtinen added the comment: 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())

[issue13212] json library is decoding/encoding when it should not

Tomasz Buchert added the comment: Take a look at http://bugs.python.org/issue14674. A proposed documentation patch specifically discusses this issue. -- ___ Python tracker ___ __

[issue13212] json library is decoding/encoding when it should not

Antoine Pitrou added the comment: > 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. --

[issue13212] json library is decoding/encoding when it should not

Changes by Ezio Melotti : -- priority: normal -> high ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue13212] json library is decoding/encoding when it should not

Raymond Hettinger added the comment: Assigning back to me (the current maintainer of the module). -- assignee: -> rhettinger ___ Python tracker ___

[issue13212] json library is decoding/encoding when it should not

Ezio Melotti added the comment: >> 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 -- __

[issue13212] json library is decoding/encoding when it should not

Éric Araujo added the comment: > 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. -- nosy: +eric.araujo ___ Python tracker

[issue13212] json library is decoding/encoding when it should not

Ezio Melotti added the comment: 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 s

[issue13212] json library is decoding/encoding when it should not

Antoine Pitrou added the comment: 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. -- nosy: +pitrou ___ Python tracker

[issue13212] json library is decoding/encoding when it should not

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue13212] json library is decoding/encoding when it should not

Raymond Hettinger added the comment: 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 aroun

[issue13212] json library is decoding/encoding when it should not

Tomasz Buchert added the comment: 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). --

[issue13212] json library is decoding/encoding when it should not

Ezio Melotti added the comment: 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 d

[issue13212] json library is decoding/encoding when it should not

Raymond Hettinger added the comment: 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. -- nosy: +rhettinger ___ Python tracker

[issue13212] json library is decoding/encoding when it should not

Changes by Florent Xicluna : -- nosy: +flox stage: -> needs patch type: -> behavior versions: -Python 2.6, Python 3.1, Python 3.4 ___ Python tracker ___ __

[issue13212] json library is decoding/encoding when it should not

New submission from Tomasz Buchert : 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