LDB python3 strings

Noel Power nopower at suse.com
Tue May 8 18:25:42 UTC 2018


On 02/05/18 22:38, William Brown wrote:
> On Wed, 2018-05-02 at 13:01 +0100, Noel Power via samba-technical
> wrote:
[...]
> This is a really annoying one to solve. In the lib389 code instead of
> putting 'decode' everywhere, we actually added some wrappers onto our
> object management code that allowed you to get a type in the manner you
> expect.
>
> get_utf8
> get_bytes
> get_int
Like Andrew said wrt. adding 'decode', this will  mean changing alot of
code. My main concern is loosing the distinction between text and binary
types in whatever changes to the api we provide.
Also we are not just porting code to python3 we are porting the code to
be python2/python3 compatible and this makes things a little trickier.

>
[...]
> So instead, you could change this to:
>
> res[0].get_utf8('samaccountname')[0]
Andrew if the api was to change to provide (by default) utf8 strings for
   res[0]["samAccountName"][0]

then by that I assume by that you mean that
in python2
   res[0]["samAccountName"][0] will now return 'unicode'
in python3
  res[0]["samAccountName"][0] will return 'str'
 
if so then I was thinking of something along the lines of providing a
'.raw' accessor might be more appropriate for example

  res[0].raw('blah')[0]

where 'raw' would give access to type 'str' in python2 (like the old
api) and in python3 would return 'bytes' like it does currently.

This approach provides some sort of distinction between binary/text data
in both python2/python3 with hopefully minimal changes. It should
prepare any python2 code appropriately. Of course it will break some
things (unfortunately including some commits of mine recently pushed to
master) but that is unfortunately unavoidable. I'd be hopeful that the
true usage of 'binary' attribute values is quite limited so this change
should only require modifications to access the 'raw' attibutes in just
a few places and that in the long term this way is a better choice.

So, I think this is sortof where you were going ?, however... I'd really
like to be sure that such a change to the api that we will have to live
with is appropriate. Do others with experience in this area of this core
api agree with such a change or see any problems? I don't feel I know
enough about the ldb usage but I'm happy to do the change if this is
felt to be the right way to go. In anycase I am going to trying to
implement something like the above to see what kind of fallout there
will be in the code.


Noel



More information about the samba-technical mailing list