From ldo at geek-central.gen.nz  Sat May 31 03:56:58 2025
From: ldo at geek-central.gen.nz (Lawrence D'Oliveiro)
Date: Sat, 31 May 2025 15:56:58 +1200
Subject: DBussy Future Compatibility
Message-ID: <20250531155658.14a83b22@theon.geek-central.gen.nz>

Aspects of the Python event-loop API have evolved somewhat since I
first created DBussy, my wrapper for D-Bus
<https://gitlab.com/ldo/dbussy>, <https://bitbucket.org/ldo17/dbussy>.
The general idea now seems to be that normal client apps aren?t supposed
to worry about creating and setting up event loops, and just let all
that happen behind the scenes.

One breaking change (which just raises a deprecation warning for now,
but is planned to become an error in future) is the
asyncio.get_event_loop() call. This returns the ?current? event loop,
creating one if it doesn?t exist. This concept of a ?current? event
loop (as distinct from the ?currently running? event loop) is going to
go away.

There is a call, asyncio.get_running_loop(), added in Python 3.7,
which returns the currently-running loop if there is one, or raises an
error if there isn?t. Also there is asyncio.run(), which takes a
coroutine object as argument, and does all the setup necessary
(including creating a running event loop) to invoke that as the main
application task and run it to completion. Since all Python releases
before 3.9 are now EOL, it makes sense to move to expecting these calls
to be used as appropriate.

As a first step, I will need to update my examples
<https://gitlab.com/ldo/dbussy_examples>,
<https://bitbucket.org/ldo17/dbussy_examples> to use the current best
practices. At some point, I will need to fix the DBussy modules
themselves. The hooks into asyncio start with the attach_asyncio()
calls in the Connection and Server objects (in both modules); currently
these allow you to omit the loop argument, whereupon
asyncio.get_event_loop() is called to attach them to the ?current?
event loop.

That will need to be changed to default to asyncio.get_running_loop()
instead, which means those calls will no longer be valid unless you a)
explicitly specify a loop, or b) are already within some
currently-running task. I expect the latter will be the more common
situation. That means you only create asynchronously-operating
instances of these objects within code that is already running
asynchronously.

Basically, the Python library is going to raise the necessary warnings
to remind you (and me) of the situations needing fixing.

Comments welcome.