RFC: Python3 porting question

[Noel Power]

Previously I posted a patch for python3 port for the smb module. During
some real life testing I came across an issue. I'd like to get some
input on how to address this.

pysmb has amongst others the methods loadfile & savefile

both take and return strings as per the documentation in the module itself

        "loadfile(path) -> file contents as a string"
        "savefile(path, str) Write string str to file."

of course in python2 this api works fine, byte content is adequately
received and returned regardless of whether the content really is string
or not. In other words binary content is handled fine with iiuc the
exception of embedded NULLs when passing a string to the savefile method.

In python3 with the stricter string class the default behaviour is to
try and return strings (decoded from the byte content as utf8) and this
doesn't work well when dealing with data that cannot be decoded (similar
limitation when writing to a file). Reading/writing only bytes that can
be encoded/decoded as utf8 seems rather limiting

we could
1) Change the api for 'smb' for python3 so that loadfile & savefile deal
with bytes only. This of course has some implications for client code if
it wants to be python2/python3 compatible.
2) Change the api for savefile to allow strings or bytes to be accepted
and allow loadfile to fallback to returning bytes if it fails to decode
a string value.

My preference is for 1 (because it is cleaner and unambiguous)

I think regardless of above we should change the python2 'savefile' to
accept 's#' instead of 's' when parsing the arguments as currently the
api is not symetrical in that you can read content that you cannot write.

Thoughts?

Thanks
Noel