Added text/plain decode handling for explicitly set content type

[wkral]

• The old version of the client handled this out of the box
• Added a test to ensure it works

Edit: Updating the heading to make the change more clear

[shuhaowu]

See #234

[wkral]

This isn't quite the same issue, in my use case the content type is explicitly set to text/plain in the store operation but when getting the object, there is an exception:

TypeError: No decoder for content type "text/plain"

This doesn't happen in the current version on pypi. There is a fairly simple workaround of setting a custom decoder when you configure the client but it seems the client should be able to handle plain text.

[seancribbs]

Devil's advocate: Why unicode() and not str()? Shouldn't it be charset-dependent?

[wkral]

@shuhaowu I didn't know about that, thanks for the tip.

[wkral]

@seancribbs So I did a little more digging and discovered it makes no difference if it's unicode or string. My initial thinking was that unicode would be able to handle all the string cases as well as the unicode cases where as string would not be able to handle unicode data. I was actually going for something that was essentially a no-op.

I discovered the client can't handle unicode data as a plain string currently. It seems from reading the new_binary deprecation doc the client expects an already encoded byte stream passed to encoded_data argument. So for a unicode string in plain text format you would expect the client to be used in the following format?

data = u"some unicode data: \u00c6"
obj = bucket.new('foo', encoded_data=data.encode('utf-8'),
                 content_type='text/plain')
obj.store()

If that's the case I'll change the code, to just use str as a decoder without an encoder at all since an data.encode('ascii') is already tried in the bucket.new method. That will solve my simple use case of ascii string in and ascii string out without a TypeError like the 1.5.2 client.

I tried adding a test case with the utf-8 encoded data in the form above and found that it errors in Python's httplib when using the RiakHttpTransport. Then I tried with unicode data in a dict using the standard application/json and it also fails in the same way. It seems the test suite doesn't use any unicode data in the message body anywhere else. I know I have data in my application that uses unicode with the client but it's always been over pbc. I guess that's a different bug. Unfortunately it seems like that might be linked to this python bug so I don't know if there is a simple fix while still using httplib: http://bugs.python.org/issue11898

[shuhaowu]

Just remember, unicode is removed in py3k

[seancribbs]

I'm satisfied with this change unless there are additional objections.

[seancribbs]

Ah, but here's a problem... you have a decoder but not an encoder. I'm of the mind to change this API significantly, but in the meantime can you add the encoder too?

[seancribbs]

Thanks @wkral!