RFC: Python3 porting question

[Alexander Bokovoy]

On ke, 14 maalis 2018, Andrew Bartlett via samba-technical wrote:
> On Tue, 2018-03-13 at 17:59 +0000, Noel Power via samba-technical
> wrote:
> > 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.
> 
> This is the correct answer.
+1.

 
> > 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)
> 
> In this case I agree.
> 
> > 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.
> 
> This seems reasonable.
Exactly.

-- 
/ Alexander Bokovoy