[issue4785] json.JSONDecoder() strict argument undocumented and potentially confusing

Georg Brandl added the comment: Thanks, applied in r85543 and r85544. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue4785] json.JSONDecoder() strict argument undocumented and potentially confusing

Changes by Tal Einat : -- versions: +Python 2.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue4785] json.JSONDecoder() strict argument undocumented and potentially confusing

Tal Einat added the comment: Similar patch against trunk; same changes as for the py3k branch. -- Added file: http://bugs.python.org/file17561/json_docs_trunk.diff ___ Python tracker ___

[issue4785] json.JSONDecoder() strict argument undocumented and potentially confusing

Tal Einat added the comment: Documentation patch attached against py3k branch. Changes are: * Added to documentation of JSONDecoder: If *strict* is ``False`` (``True`` is the default), then control characters will be allowed inside strings. Control characters in this context are those with

[issue4785] json.JSONDecoder() strict argument undocumented and potentially confusing

Tal Einat added the comment: This goes down into _json.scanstring. Looking at the C code for scanstring_unicode, strict=False allows control characters inside strings: "if strict is zero then literal control characters are allowed". From the code itself (current py3k head, r81032), it seems t

[issue4785] json.JSONDecoder() strict argument undocumented and potentially confusing

Tal Einat added the comment: This goes down into _json.scanstring. Looking at the C code for scanstring_unicode, the strict parameter allow control characters inside strings: "if strict is zero then literal control characters are allowed". From the code itself (current py3k head, r81032), it

[issue4785] json.JSONDecoder() strict argument undocumented and potentially confusing

New submission from David M. Beazley : The strict parameter to JSONDecoder() is undocumented and is confusing because someone might assume it has something to do with the encoding parameter or the general handling of parsing errors (which it doesn't). As far as I can determine by reading the s