RFC: Python3 porting question
nopower at suse.com
Wed Mar 14 12:41:14 UTC 2018
Thank you for the input,
please see https://github.com/samba-team/samba/pull/147
On 13/03/18 18:25, Alexander Bokovoy wrote:
> 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
>>> 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.
>>> 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.
More information about the samba-technical