On Dec 01, 2011, at 03:56 PM, <email address hidden> wrote:

>https://bugs.freedesktop.org/show_bug.cgi?id=26420
>
>--- Comment #52 from Simon McVittie <email address hidden> 2011-12-01 07:56:43 PST ---
>(In reply to comment #51)
>> - I did original make the various ascii-string types as bytes subclasses, and
>> while I was able to get test-standalone working, the cross-tests have had
>> various difficult to track down failures.
>
>"difficult to track down" - yes, this is why dbus-python isn't the answer :-P
>The type-guessing stuff is really subtle and can basically never work
>"properly"; the best it's ever going to get is "not too astonishing most of
>the time".

Actually, the type guessing stuff works fine afaict.  The bytes/unicode
problem comes in callback dispatching because of all the checks against
object_path, interface, method name, etc.  E.g. because in Python 3 b'foo' !=
'foo' all the dispatch code has to coerce everything to the same type, or
callbacks won't get called.  You also have tricky issues with bus names,
e.g. bus_name[:1] == ':' can't work when the bus name is a bytes.

The thorny problem is that in the cross-tests, the signal callbacks don't get
called.  The matching code is difficult to debug, so fixing one problem takes
a long time and doesn't help much with the next problem.  The code's gotten
pretty ugly, which is why I'm coming around to your view that signatures,
object paths, etc. should be unicodes.  I'm not 100% there yet because I want
to see if that results in cleaner internal code without undue porting burdens
on user code.

>> I'm going to do another branch where
>> they are str/unicode subclasses and see if that makes things better. 
>> Conceptually, to me they want to be bytes subclasses (for many of the reasons
>> John originally pointed out), but practically speaking, it may be easier and
>> less disruptive to users to make them strings.
>
>I still think Signature and ObjectPath want to be (Unicode) strings that
>happen to be constrained to ASCII, for the same reasons that Python
>identifiers are (Unicode) strings.

Yep, I'm going to try that approach next.

>(UTF8String and ByteArray should be bytes subclasses, though.)

Should UTF8String be removed for Python 3?  I agree about ByteArrays.

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

>> I'm really not interested in
>> Python 2 < 2.6 or Python 3 < 3.2.  I'd like to know though whether Simon is
>> philosophically opposed to integrating Python 3 support into upstream or not.
>
>I'm not philosophically opposed to Python 3 stuff getting merged, but it
>needs a maintainer I can trust to get it right, who isn't me. If you're
>volunteering, help is appreciated.

Well, let's see if I can get the test suite passing first (see bug 43303), but
if I can, I'm willing to help maintain the Python 3 stuff.

>I *am* philosophically opposed to an API with the same flaws and
>backwards-compat baggage as dbus-python's being the recommended way to get on
>D-Bus (we'd be better off with something resembling GDBus/GVariant, I think),
>but perhaps the Qt world doesn't have anything better yet, so...

AFAICT, they don't.  My goal with this work is to maintain as close to
backward compatible API as possible for Python 3, since that would be easiest
for users porting existing applications to Python 3.  I don't see much of an
advantage to porting dbus-python to Python 3 *and* radically changing the API
because then users might as well switch to GDBus and work with the KDE and
Gnome communities to improve their toolkit-specific versions.  (What about
non-UI dbus applications?)

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" :).  If
not, then I have to decide whether to abandon my work or fork upstream,
neither of which are very appealing to me.

>> I've got an experimental branch in bzr.
>> lp:~barry/python-dbus/py3
>
>Like other fd.o projects, dbus-python is maintained in git. If bzr can interop
>with git these days, great, but I'd really appreciate a git remote I can look
>at if possible. Or just a series of unified diffs, git-format-patch style...
>(the launchpad web interface has that somewhere, right?)

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).  In
any case, I'll make all my work available to you via git or unified diffs.

Cheers.