If you request an operation to be run it will be run.  It would be incorrect to assume otherwise.  However if you want to be explicit about it all you have to do is connect to the NameOwnerChanged signal to see when the service gets and releases the name and then call the NameHasOwner method of the bus to check if the name was already acquired before the app was started.  To do this in the bindings would mean overhead for all applications when this is clearly an edge case.

Ah this is a bug in some sense.  The summary is wrong.  In my opinion we should late bind object on first call or if explictly asked to do so.  Most D-Bus proxies work this way and I think it should be the default.  Simon and I have had some good spirited arguments over this.  It goes to the heart of whether or not we wish the bindings to act like python objects (where the proxy's init instantiates the actual object) or take on the behavior of the lowlevel library which is to only send a messages when a method is called.  Of course the lowlevel library has no real concept of objects so for better or worse that is what is expected and most binding follow that tradition.

In any case the first suggestion still stands and the issue with early binding has to do more with performance and sync calls.

I'm not convinced this is exactly the same issue that J5 and I have discussed, actually. I'll consider what to do about this later.

The two things you might want to do with that object are: call its methods, and listen for its signals.

If you want to call its methods, as soon as you call a method the service will be launched anyway.

If you want to listen to its signals, you can do that with dbus.Bus.add_signal_receiver() instead, like so:

session_bus = dbus.Bus()
session_bus.add_signal_receiver(track_changed_cb, signal_name='TrackChanged', dbus_interface='org.gnome.HypotheticalMediaPlayer', named_service='org.gnome.HypotheticalMediaPlayer', path='/org/gnome/HypotheticalMediaPlayer')

(In practice you probably want to ignore the named_service and the path and just listen for org.gnome.HypotheticalMediaPlayer::TrackChanged, in this case.)

The tutorial ought to be recommending add_signal_receiver() as a way to listen for things happening, really, as this avoids unwanted activation. I'll clone this bug.

It's debatable whether we should be activating objects as a side-effect of making proxies for them, or on the first method call. The reason we do so is that we introspect them, which gives the proxy the method signatures and so on. If we were to delay introspection until the first method call, the implementation could get ugly; we may also need to introspect in future in order to get lists of signals and methods, which would be a rather astonishing reason to activate the service.

Fixed in git: the tutorial now describes add_signal_receiver before proxies' connect_to_signal, and notes that you shouldn't use proxies if all you want to do is listen to signals. I believe the creation of a proxy should be allowed to trigger introspection, as it usually does now.