RFC: Python3 porting question

[Noel Power]

Thank you for the input,
please see https://github.com/samba-team/samba/pull/147

Noel

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
>> 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.
>