Use a full unicode layer in preferences.py#45
Conversation
There was a problem hiding this comment.
I think that if we get a str from the Python side, we should assume it to be ASCII, not UTF-8. We should not be throwing around UTF-8-encoded str objects in our Python code.
There was a problem hiding this comment.
Thinking about my initial use case a bit more, what I was trying to solve was the unicode object coming from the UI (or other sources) and that had to be serialized to the preferences. I agree that the assumption of utf-8 encoded string is not good.. I'll remove that.
|
@rkern's comments are appropriate, as always. In addition, can you add this PR reference to this line in |
|
@rkern @corranwebster PR updated based on your comments. Does that look better? |
|
LGTM. There is a difference in behaviour in that now a |
|
thanks @corranwebster. Merging. |
Use a full unicode layer in preferences.py
PR #41 was changing the behaviour of the Preference class by not converting object to str anymore. This caused a clear problem when getting preferences from a file as the same call to retrieve a preference could either return a specific type or a unicode object as read by ConfigObj in the file.
This PR changes the behaviour again and gets back to the original design of Preferences which standardizes on str objects. When setting an object in the Preference class it is automatically converted to a unicode object (defaulting to utf-8 encoded strings as input), the unicode object is then properly serialized as utff-8 str by ConfigObj when saving the prefence to a file. When loading the preference in the preference helper, the object is nicely converted back to its target type, with
Stras a special case where the unicode object is encoded to a utf-8 str)This PR fixes the broken test suite.
@corranwebster Can you review? @rkern this changes a bit what we talked about in #41 but is probably the least painful implementation before switching to a better storage like yaml.
Fixes the failures described in #44.