[Python-Dev] Dropping bytes "support" in json
Mark Hammond
skippy.hammond at gmail.com
Sat Apr 11 06:36:00 CEST 2009
[Dropping email sig]
On 11/04/2009 1:06 PM, "Martin v. Löwis" wrote:
> However, I really think that this question cannot be answered by
> reading the RFC. It should be answered by verifying how people use
> the json library in 2.x.
In the absence of anything more formal, here are 2 anecdotes:
* The python-twitter package seems to:
- Use dumps() mainly to get string objects. It uses it both for
__str__, and for an API called 'AsJsonString' - the intent of this seems
to be to provide strings for the consumer of the twitter API - its not
clear how such consumers would use them. Note that this API doesn't
seem to need to 'write' json objects, else I suspect they would then be
expecting dumps to return bytes to put on the wire. They expect loads
to accept the bytes they are reading directly off the wire.
* couchdb's wrappers use these functions purely as bytes - they are
either decoding an application/json object from the bits they read, or
they are encoding it to use directly in the body of a request (or even
directly in the URL of the request!)
I find myself conflicted. On one hand I believe the most common use of
json will be to exchange data with something inherently byte-based. On
the other hand though, json itself seems to be naturally "stringy" and
the most natural interface for a casual user would be strings.
I'm personally leaning slightly towards strings, putting the burden on
bytes-users of json to explicitly use the appropriate encoding, even in
cases where it *must* be utf8. On the other hand, I'm too lazy to dig
back through this large thread, but I seem to recall a suggestion that
using bytes would be significantly faster. If that is true, I'd be
happy to settle for bytes as I believe the most common *actual* use of
json will be via things like the twitter and couch libraries - and may
even be a key bottleneck for such libraries - so people will not be
directly exposed to its interface...
Mark
Cheers,
Mark
More information about the Python-Dev
mailing list