Are users of fastbinary.c expected to use ASCII encoding exclusively? The code generator has the option to force UTF8 encoding/decoding for strings, so one could argue that fastbinary.c should have an analog version that works only on UTF8 encoded strings.
On Sep 2, 2010, at 11:49 PM, David Reiss <dre...@facebook.com> wrote: > We don't actually use the "UTF8" field type. That should probably be > removed entirely. Unfortunately, there is currently no way for the > accelerator module to determine whether the user wants a given value > to be decoded into a unicode object or returned as a str. > > --David > > On 09/02/2010 07:26 PM, Leo Kim wrote: >> Hello, >> >> I didn't see utf8 support in fastbinary.c in thrift-0.4.0, so I hacked >> something in. I'm not a Python C API expert (nor a unicode expert), >> but the attached patch appears to work when sending utf8 encoded >> strings whereas without the patch I'd encounter the >> "UnicodeDecodeError: 'ascii' codec can't decode byte ..." error. >> >> I offer it to this mailing list for review as I'm interested in >> feedback regarding correctness and general interest in this patch. >> >> thx >> leo
