Title: json module: it is not possible to override 'true', 'false' values during encoding bool
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: bob.ippolito Nosy List: Marian Horban 2, bob.ippolito, rhettinger, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2017-04-20 10:04 by Marian Horban 2, last changed 2017-04-21 05:10 by serhiy.storchaka. This issue is now closed.

File name Uploaded Description Edit
json_improvement.patch Marian Horban 2, 2017-04-20 10:04 review
Messages (4)
msg291959 - (view) Author: Marian Horban (Marian Horban 2) Date: 2017-04-20 10:04
It is not possible to override 'true', 'false' values during encoding bool.
For example if I want to dump dict like:
    {"key": True}
and result must be not 
    {"key": true}
but let's say
    {"key": "TRUE"}
It is really hard to force json.dumps function to do it.

I understand that improving of json encoder performance causes this inflexible implementation.
Perfect solution for extending/overriding json module would be move nested functions
into class JSONEncoder as static methods.
But it could make performance a bit worse.

So if we cannot afford it I would propose to move function _make_iterencode to JSONEncoder as a static method.
This change will not degrade performance.
But it will be possible to override this method in SPECIFIC user's Encoder.
msg292004 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-04-21 03:09
Sorry, I think this is unnecessary feature creep.  The goal of the JSON module is to generate valid JSON for some semantically equivalent Python.  Wanting to turn *True* into the string "True" isn't in the spirit of the module and certainly not worth all the proposed code churn.  If this is really what you need (a somewhat exotic need at that), then I would recommend writing a recursive tree walker that replaces *True* nodes with "True" prior to outside of the JSON module.
msg292006 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-04-21 04:41
I concur with Raymond.
msg292007 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2017-04-21 04:48
Agreed, this does seem unnecessary. The library has been in active use for over a decade, and this is the first time I've seen this request. I would recommend preprocessing the data that you're going to encode if you have a need for this.
Date User Action Args
2017-04-21 05:10:09serhiy.storchakasetresolution: rejected
2017-04-21 04:48:10bob.ippolitosetstatus: open -> closed

messages: + msg292007
stage: resolved
2017-04-21 04:41:24serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg292006
2017-04-21 03:09:21rhettingersetversions: + Python 3.7, - Python 2.7
nosy: + rhettinger, bob.ippolito

messages: + msg292004

assignee: bob.ippolito
2017-04-20 10:04:06Marian Horban 2create