- Change Summary:
-
Fix the one place I seem to have misplaced the u ('u..'). Grepping indicates that I didn't make other mistakes.
Audit all strings in djblets and convert to __future__.unicode_literals
Review Request #4944 — Created Nov. 12, 2013 and submitted
Audit all strings in djblets and convert to
__future__.unicode_literals
This change represents an audit of all of the strings in the djblets codebase.
Where the strings were actually binary data (specifically with our treatment of
settings.EMAIL_HOST_USER
andsettings.EMAIL_HOST_PASSWORD
, and anything passed
intosha1()
ormd5()
), I've made it use thebytes
type. Otherwise, these are
nowunicode
objects by virtue of importingunicode_literals
from__future__
.There's also a bunch of fixes to our handling of cache keys, especially those
for large data, much more consistent. We always keep the cache key as a unicode
object and create derivative keys (like the chunk keys for large data) with
that. At the last moment, before callingcache.get()
orcache.set()
, we pass
that tomake_cache_key
, which will shorten it if necessary using md5, and then
encode to utf-8 (since not all cache backends support the unicode object as
keys).
- Verified my assumptions about treatment of
unicode
vs.str
ingetattr
,
hasattr
,delattr
,__getattr__
,__hasattr__
,__delattr__
,hash
, regular
expressions, and memcache keys. - Ran djblets unit tests
- Ran Review Board unit tests
- Change Summary:
-
Add unicode_literals, undo the "u" prefixes, and fix a few bugs I found in the handling of strings in the large-data caching.
- Summary:
-
Go through and clarify types of all strings in djblets.Audit all strings in djblets and convert to __future__.unicode_literals
- Description:
-
~ Go through and clarify types of all strings in djblets.
~ Audit all strings in djblets and convert to
__future__.unicode_literals
This change represents an audit of all of the strings in the djblets codebase.
Where the strings were actually binary data (specifically with our treatment of ~ settings.EMAIL_HOST_USER
andsettings.EMAIL_HOST_PASSWORD
, and anything that~ gets passed into sha1()
ormd5()
), I've made it use thebytes
type. Otherwise,~ I've changed all of the "text" strings to be unicode
literals instead ofstr
.~ settings.EMAIL_HOST_USER
andsettings.EMAIL_HOST_PASSWORD
, and anything passed~ into sha1()
ormd5()
), I've made it use thebytes
type. Otherwise, these are~ now unicode
objects by virtue of importingunicode_literals
from__future__
.~ In a future change, I'll import
unicode_literals
from__future__
in every file~ and remove the u
prefix. This change was a necessary intermediate step to make~ sure I looked at every single string and made a decision about it. ~ There's also a bunch of fixes to our handling of cache keys, especially those
~ for large data, much more consistent. We always keep the cache key as a unicode ~ object and create derivative keys (like the chunk keys for large data) with + that. At the last moment, before calling cache.get()
orcache.set()
, we pass+ that to make_cache_key
, which will shorten it if necessary using md5, and then+ encode to utf-8 (since not all cache backends support the unicode object as + keys).