Comment 62 for bug 893091

> >(UTF8String and ByteArray should be bytes subclasses, though.)
>
> Should UTF8String be removed for Python 3? I agree about ByteArrays.

So, the point of UTF8String was more efficient interaction with libraries that (at the C level) are always always UTF-8 - like GLib, libxml2, expat etc. - and represent this as a str-that-is-UTF-8 in their Python 2 bindings.

If such libraries would never use bytes in Python 3 anyway, then yes, UTF8String (and the accompanying utf8_strings option) should cease to exist, or be stubs that just raise an exception, in a Python 3 build.

> Note too that I'm planning on keeping the current long/int hierarchy when
> compiled against Python 2. It's only under Python 3 that things will be a
> little different (as minimally so as possible).

Sounds good. Presumably in Python 3, everything "int-ish" would be a subclass of the new int that is equivalent to the old long.

> I guess I'm looking for guidance here as to whether that goal is compatible
> with your plans for upstream. Ideally, your answer would be "yes" :)

Yeah, let's try it. The alternative is basically "it's deprecated, use something else"...

> bzr can interoperate with git with some limitations (e.g. no submodules or
> colocated branches, neither of which I think are in the dbus-python git).

FYI, there are branches other than "master" in dbus-python.git (e.g. see the web interface <http://cgit.freedesktop.org/dbus/dbus-python> for the list), although "master" is the only branch from which releases are made.

"py3k" is J5's partially-working port to Python 3 (as referred to above), which you might find useful.

"purity" is an experiment in using libdbus less, to avoid some of the worse parts of its C API.

The rest are all merged, I think.