dbus-python-in-C initial implementation available

[John (J5) Palmieri]

On Wed, 2006-09-27 at 15:54 +0100, Simon McVittie wrote:
> I've pushed the C reimplementation of dbus-python into the git repo at
> <http://people.freedesktop.org/~smcv/git/dbus-python/.git/>. All
> comments welcome!
> 
> In particular: J5, would you be happy to release this or something based
> on it as dbus-python 0.8?

I am amazed.  Two changes later and Sugar, the OLPC desktop environment
works (and seemingly faster).  They aren't even big changes.  One was a
bug in the Sugar code and the other was expected. 

The expected one involved dbus_bindings which we knew would change.  In
the old bindings I had to do
dbus.dbus_bindings.bus_name_has_owner(connection, bus_name).  In the new
ones connection.name_had_owner(bus_name).

The bug went like this:

if type(prop) != type({}):
    raise Exception

the fix:

if not isinstance(prop, dict):
    raise Exception

I'm going to play with it somemore and give my final verdict but ya if
all goes well I am happy to have these become 0.80. Kick ass work.

> 
> API docs in <http://people.freedesktop.org/~smcv/temp/dbus-python.epydoc/>
> as before.
> 
> ===============================
> API changes in dbus-python-in-c
> ===============================
> 
> * Byte is a subtype of str rather than of int, which better matches
>   Python's conventions for dealing with byte streams. Its constructor
>   accepts either single-byte strings or integers in the range 0 to 255.
>   It overrides __int__, but unfortunately int() special-cases strings,
>   so int(Byte(1)) raises ValueError and int(Byte('1')) gives 1 rather
>   than the expected ord('1').

We should find a way around this if we can.  A lot of services like
Avahi and bluetooth use byte arrays so we should check against them.

> * In method parameters, method returns from proxy methods, etc.,
>   integers arrive as instances of dbus.Int32 etc., bytes arrive as
>   Byte, and so on, rather than everything being converted to an
>   appropriate built-in Python type. This means you can tell exactly
>   what arguments went over the bus, and their types.

This is fine as long as we can use isinstance and a base type to check
them (i.e. they are derived from some basic Python type).

> * Variants arrive as method parameters, returns from proxy methods, etc.
>   as Variant objects. This is a bit of a big change, but makes things
>   completely unambiguous. To unwrap variants like the old Pyrex
>   implementation did, you can write::
> 
>       while isinstance(myparam, dbus.Variant):
>           myparam = myparam.object
> 
>   This should also work (and do nothing) under the Pyrex implementation.

I'm a little worried about this.  Python is a dynamic language.
Everything is a variant (it was the purpose of variants in the first
place).  If signatures are not specified by the service we assume
variant.  I don't know if strongly typing python here is valuable.  Can
I use myparam as if it were it's contained type?  For instance if the
myparam variant held a dbus.Dictionary would print myparam.keys() work?
More importantly would isinstance(myparam, dict) work?

> * The D-Bus integer types (dbus.Int32, etc.) are properly range-checked.
> 
> * Variants are now immutable "value objects".

> * Variants are somewhat more useful: they can be cast using int(),
>   str(), long(), float(), you can iterate over them with iter() if they
>   contain an iterable, you can compare them with ``==`` and ``!=``,
>   and you can hash them if the underlying object supports it.

Ok, I guess that answers my myparam.keys() issue (or does it?) but the
isinstance question still remains.

> * Array constructor takes arguments (iterable[, signature])
>   rather than (iterable[, type][, signature]); ditto Variant, Dict

The one thing I liked about type was that one didn't have to remember
the D-Bus signature alphabet but type is messy with other constructors
so I think signature only is the correct choice.  In the end one needs
to know a little about D-Bus to be a good citizen.

> * Proxy methods with multiple return values return a tuple rather than
>   a list.

good

> * Calling a proxy method with reply ignored, or with async
>   handlers, returns None

sounds fine

> * The Boolean, String, Double and Struct types are now aliases for the
>   built-in bool, unicode, float and tuple types. Their use is vaguely
>   deprecated.

I would keep them just for clarity of what the bus supports

> * ConnectionError no longer exists (it was never raised)

sounds fine

> * dbus_bindings is now called _dbus_bindings, and is considerably
>   different internally:

should it not be dbus._dbus_bindings?  Hides it even more I think.

>   * connections are private at the libdbus level: shared connections
>     are only shared among Python code

We just recently got this option.  It is the correct way to go.

>   * The MessageIter stuff is now done in C: there's a much simpler
>     Python API, ``Message.append(...)`` where positional arguments are
>     the things to be appended, and the keyword argument ``signature``
>     controls how objects are interpreted

nice

>   * The signature-guessing algorithm used if there is no proper
>     signature is exposed as a static method,
>     ``Message.guess_signature(*args)``

works for me.  No one should use this except internally but there may be
some debugging uses.

>   * Bus is a subclass of Connection rather than being a wrapper object
>     which has-a Connection

+1 

>   * Some relatively internal methods have been renamed starting with
>     an underscore - most Python code shouldn't need to use them, and
>     they expose the full complexity of Messages etc.

Yes we should expose them through public API only when appropriate 

>   * The timeouts in _send_with_reply and in _send_with_reply_and_block
>     are in (possibly fractional) seconds, as is conventional in Python

Sounds good to me.

>   * The specialized Message subclasses have names ending with Message

good

> =========
> Copyright
> =========
> 
> I've tried to work out who wrote what from the CVS and git history, and
> put proper copyright notices on things, after noticing that my C code
> had the first copyright notices in the whole source tree!

Hehe.  We just took teh D-Bus copyright

> Did Seth Nickell write dbus-python independently, or is it owned by an
> employer?

> J5, I assume your bits of it are owned by Red Hat?

Seth wrote them as an employee of Red Hat so the copyright should be
attributed to them.  BTW it should be GPL/Academic Free dual licensed
like D-Bus 
-- 
John (J5) Palmieri <johnp at redhat.com>