[Python-Dev] Dropping bytes "support" in json

Mark Hammond skippy.hammond at gmail.com
Sun Apr 12 04:29:24 CEST 2009


On 11/04/2009 6:12 PM, Antoine Pitrou wrote:
> Martin v. Löwis<martin<at>  v.loewis.de>  writes:
>> Not sure whether it would be *significantly* faster, but yes, Bob wrote
>> an accelerator for parsing out of a byte string to make it really fast;
>> IIRC, he claims that it is faster than pickling.
>
> Isn't premature optimization the root of all evil?
>
> Besides, the fact that many values in a typical JSON object will be strings, and
> must be encoded from/decoded to unicode objects in py3k, suggests that
> accepting/outputting unicode as default is the laziest (i.e. the best) choice
> performance-wise.

I don't see it as premature optimization, but rather trying to ensure 
the interface/api best suits the actual use cases.

> But you don't have to trust me: look at the quick numbers I've posted. The py3k
> version (in the str-only incarnation I've proposed) is sometimes actually faster
> than the trunk version:
> http://mail.python.org/pipermail/python-dev/2009-April/088498.html

But if all *actual* use-cases involve moving to and from utf8 encoded 
bytes, I'm not sure that little example is particularly useful.  In 
those use-cases, I'd be surprised if there wasn't significant time and 
space benefits in not asking apps to use an 'intermediate' string object 
before getting the bytes they need, particularly when the payload may be 
a significant size.

Assuming the above is all true, I'd see choosing bytes less as a 
premature optimization and more a design choice which best supports 
actual use.  So to my mind the only real question is whether the above 
*is* true, or if there are common use-cases which don't involve 
utf8-off/on-the-wire...

Cheers,

Mark



More information about the Python-Dev mailing list