This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author aalien
Recipients aalien, ezio.melotti, jcea, r.david.murray
Date 2012-07-20.12:41:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1342788120.02.0.253338061325.issue15393@psf.upfronthosting.co.za>
In-reply-to
Content
> you are changing the signature of "decode()" and that would be a compatibility problem

I was changing the signature of raw_decode(), by adding a(n almost) private keyword. I really don't see how that would affect compatibility.

> you are thinking that "json document" includes the possibility of leading whitespace

Yes. While JSON does not have a real standard to follow, I believe that going by the RFC is the best thing to do, and the RFC very clearly states, that objects can be surrounded with whitespace.

decode() depends on the functionality of raw_decode(), and its own parameter _w. I have no idea why _w is a parameter. It is not used anywhere in CPython, and, beginning with an underscore, it shouldn't be used from anywhere else. Still it offers the users a possibility to break the behaviour of decode(). If it's a performance hack, making the variable being initialized only once, then I think it's a very poor one.

Now the patch leaves decode() as it is, and checks for whitespace in raw_decode(), which leads to checking for whitespace twice when using decode().

I think that a more extensive cleanup would be in order.
History
Date User Action Args
2012-07-20 12:42:00aaliensetrecipients: + aalien, jcea, ezio.melotti, r.david.murray
2012-07-20 12:42:00aaliensetmessageid: <1342788120.02.0.253338061325.issue15393@psf.upfronthosting.co.za>
2012-07-20 12:41:59aalienlinkissue15393 messages
2012-07-20 12:41:58aaliencreate