Repository health decreased by 0.01% when pulling 7822b24 on gordonjm:master into ef030ec on softlayer:master.

• 1 new problem was found (including 0 errors and 0 code smells).
• No problems were fixed.

Coverage decreased (-0.02%) to 85.75% when pulling 7822b24 on gordonjm:master into ef030ec on softlayer:master.

I eliminated "interpreter_version" in favor of "sys.version_info[0]" to get to the local variables limit.

Code quality remained the same when pulling dc524a3 on gordonjm:master into ef030ec on softlayer:master.

Coverage decreased (-0.02%) to 85.75% when pulling dc524a3 on gordonjm:master into ef030ec on softlayer:master.

Are we sure that it works this way with Python 3? From a library standpoint with no knowledge of the server's API endpoints I don't know how it would ever assume that an arbitrary parameter needs to be base64 encoded without using a user specifying the xmlrpc_client.Binary type or making assumptions (which is what this PR is making). Any other endpoint that takes an object that has a "data" key is assumed to be base64, which has the following problems:

• Objects with a 'data' attribute may have a type other than base64
• Attributes of the base64 type aren't always named 'data'

To me, it seems like the user should give the base64 argument the base64ed value. This should work today with no code change to the library required and fits more in line with SLDN documentation. When it says it expects a base64 encoded value, you should give it a base64 encoded value. Example:

attachedFile = { 'data': base64.b64encode(filecontents), 'filename': 'image.png'}
result = client['Ticket'].addAttachedFile(attachedFile, id=ticket_id)

or potentially use a xmlrpc.Binary value:

attachedFile = { 'data': xmlrpc.Binary(filecontents), 'filename': 'image.png'}
result = client['Ticket'].addAttachedFile(attachedFile, id=ticket_id)

or as a SoftLayer-client type (so that other transports like REST will be able to support this):

attachedFile = { 'data': softlayer.Base64(filecontents), 'filename': 'image.png'}
result = client['Ticket'].addAttachedFile(attachedFile, id=ticket_id)

The difference in the encoding between Python 2 and 3 can be verified using the client in the associated issue. One thing I noticed with explicit base64 encoding (passing filecontents to base64.b64encode) is that Python 3 appears to encode the already encoded data before sending the request. However, all is well in Python 2 and 3 when filecontents is passed to xmlrpc.Binary. Given the good points you've made I feel that this pull request should be killed. The way forward appears to be for the end-user to explicitly perform base64 encoding, or form a binary object via xmlrpc.Binary.