[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 rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - wont fix stage: needs patch - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: rhettinger - bob.ippolito nosy: +bob.ippolito ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.
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.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13212
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 value, removing the constraint that it be an object or array. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-compliance -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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. -- nosy: +hac.man ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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()). 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. -- nosy: +petri.lehtinen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Éric Araujo mer...@netwok.org 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 rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Ezio Melotti ezio.melo...@gmail.com 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 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Raymond Hettinger raymond.hettin...@gmail.com added the comment: Assigning back to me (the current maintainer of the module). -- assignee: - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Changes by Ezio Melotti ezio.melo...@gmail.com: -- priority: normal - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Antoine Pitrou pit...@free.fr 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Ezio Melotti ezio.melo...@gmail.com 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 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). -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Tomasz Buchert thin...@gmail.com 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). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Raymond Hettinger raymond.hettin...@gmail.com 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 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. -- assignee: - rhettinger priority: normal - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Antoine Pitrou pit...@free.fr 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 rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Ezio Melotti ezio.melo...@gmail.com 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 strict=True or add yet another really_strict argument. -- assignee: rhettinger - priority: high - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
New submission from Tomasz Buchert thin...@gmail.com:
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
--
components: Library (Lib)
messages: 145847
nosy: thinred
priority: normal
severity: normal
status: open
title: json library is decoding/encoding when it should not
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13212
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Changes by Florent Xicluna florent.xicl...@gmail.com: -- nosy: +flox stage: - needs patch type: - behavior versions: -Python 2.6, Python 3.1, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Raymond Hettinger raymond.hettin...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
