This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients Jon.Oberheide, alex, christian.heimes, fijall, georg.brandl, hynek, loewis, ncoghlan, petri.lehtinen, pitrou, python-dev, serhiy.storchaka
Date 2012-06-22.10:09:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340359749.6.0.855359121667.issue15061@psf.upfronthosting.co.za>
In-reply-to
Content
> The error will be if code works for developer from ASCII word, and then
> on the other side of ocean it will no longer work with non-ASCII
> strings. You are expected to be familiar with such issues. In any case,
> the obvious (and simplest, and fastest) way to check that a string is
> ASCII-only is try to encoded it to ASCII.

No, the fastest way is to check the kind attribute of the unicode object in C code. That doesn't involve any additional conversion or Python function call. The function is deliberately limited.

The ASCII fallback is very useful as most people will store hex encoded bytes of their passphrases in their databases. With ASCII support you can do timingsafe_compare(hex_from_db, hmac.hexdigest()).


Maciej:
http://pastebin.com/ZAAjSkJh

The C function is one order of magnitude faster and the spread is one order smaller. 1e-07 is within the noise level on my idle computer. A busy server will have a higher noise level.
History
Date User Action Args
2012-06-22 10:09:10christian.heimessetrecipients: + christian.heimes, loewis, georg.brandl, ncoghlan, pitrou, alex, fijall, python-dev, petri.lehtinen, hynek, serhiy.storchaka, Jon.Oberheide
2012-06-22 10:09:09christian.heimessetmessageid: <1340359749.6.0.855359121667.issue15061@psf.upfronthosting.co.za>
2012-06-22 10:09:09christian.heimeslinkissue15061 messages
2012-06-22 10:09:08christian.heimescreate