Changing `xcp.xmlunwrap` API to use `unicode` (py3:`str`) instead of `str` (py3:`bytes`)

[ydirson]

Context: "WIP python3: fix xmlunwrap and its test to align with the use of bytes" commit in #17 (current shortcut:
ydirson@d709c94).

This stems from functions getText() and getStrAttribute() calling str.encode() on the data they return, and this contaminates getMapAttribute(), whose keys must be the same type. Likely this causes no issue only because this module only ever manipulates pure-ASCII data in its xml files, which did not seem to warrant unicode usage. The commit referenced above shows how this becomes awkward in python3, having to manypulate byte objects.

Just removing the .encode() calls and switching the module to unicode_literals would make it clean, be would likely impact all client code making use of those 3 functions, which would have to be updated in lockstep. The only client modules identified for now are:

• https://github.com/xenserver/host-installer
• xcp.repository (internal, so not an issue)

Suggested course of action: make this change in a separate branch, in parallel to required host-installer changes, prior to merging #17 so the latter can be updated accordingly.

[rosslagerwall]

If this is changed to return unicode in Python 2, then xcp.repository.Repository will have a bunch of unicode attributes (due to the way it uses self.__dict__) and I'm not sure users of that (e.g. prepare_host_upgrade.py) would handle them correctly.

I think it would be safer to do something like this:

if type(rc).__name__ == 'unicode':
    rc = rc.encode()

That way, the return values will be str for Python 2 and not break clients and they will be str for Python 3 and behave sensibly.

It is a bit ugly but there are only two instances where it is needed and it can be dropped once Python 2 support is dropped completely.

[ydirson]

Maybe less ugly would be to call encode() only on python2, but in both cases it will require to do ugly hacks in unit tests too.

The more I'm thinking about it, the more appealing the idea of forking a xmlunwrap2 module with proper typing (and maybe rewrite xmlunwrap as a reapper around xmlunwrap2, only installed for python2)

[bernhardkaindl]

@ydirson wrote:

Maybe less ugly would be to call encode() only on python2, but in both cases it will require to do ugly hacks in unit tests too.

Yes, I've done that in Commit ecc8c1f, merged with #27, so in the 1st PR that I worked on.

At of this PR, thanks to @ydirson starting with the test-driven method of adding tests in 2022, before making changes, his test already covered this change, so it is tested to not have changed the Python2 API:

https://github.com/xenserver/python-libs/blob/master/tests/test_xmlunwrap.py#L20