Re: [PATCH] Remove the encode/decode calls in DummyResponse.write()/getvalue() and take a more optimistic approach

Aahz <[email protected]> Thu, 15 Oct 2009 09:01:56 -0700
Newsgroups gmane.comp.python.cheetah
Organization The Cat & Dragon
Message-ID <[email protected]>
On Thu, Oct 15, 2009, [email protected] wrote:
> On Thu, 15 Oct 2009, Aahz wrote:
>> On Wed, Oct 14, 2009, R. Tyler Ballance wrote:
>>>
>>> +        try:
>>> +            return chunk.decode('utf-8', 'strict')
>>> +        except UnicodeDecodeError:
>>> +            try:
>>> +                return chunk.decode('latin-1', 'strict')
>>> +            except UnicodeDecodeError:
>>> +                return chunk.decode('ascii', 'ignore')
>>> +        except AttributeError:
>>> +            return unicode(chunk)
>>> +        return chunk
>> 
>> Why is it safe to just return unicode() after AttributeError without
>> another try/except?  Maybe you want to do unicode(chunk, errors='ignore')?
> 
> Fair point, I think the errors='ignore' kwarg is a good suggestion but I
> did consider the unicode() call safe since "chunk" object in this case
> is almost certainly an non-string type.

Consider this:

[')(*&^#%@)(*&)(*& BAD UNICODE DATA #@%*&^#@$*&^#@$']

However, I think it's reasonable to just do a "best guess" using ignore
for these types.
-- 
Aahz ([email protected])           <*>         http://www.pythoncraft.com/

"To me vi is Zen.  To use vi is to practice zen.  Every command is a
koan.  Profound to the user, unintelligible to the uninitiated.  You
discover truth everytime you use it."  [email protected]

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference