Unify client lifecycle management across sync/async and single/batch operations

[dev-dsp]

There's an inconsistency in how user-supplied httpx clients are handled depending on which method you call. The README even documents this for queries(), but I think this deserves a second look.

The whole point of allowing client injection is giving users control over connection pooling, auth, timeouts, and lifecycle. When the library accepts a client but then closes it, that contract falls apart.

This results in

• Connection pooling becoming useless for batch operations. If I want to run several queries() calls against the same endpoint, I can't reuse connections - which is exactly the scenario where pooling would help most.
• Users having to remember which methods are "safe" with a shared client and which will kill it.
• Blocking some reasonable patterns - say, a long-running service that keeps a client pool, and dispatches queries through sparqlx. Right now you have to defensively recreate clients or avoid queries()/updates() entirely.

ClientManager already does the right thing in context() and acontext() - it knows whether a client is auto-managed or user-supplied and acts accordingly. That's the correct design. The issue is that SPARQLWrapper.__exit__ and __aexit__ sidestep this and close unconditionally. Then queries()/updates() use async with on a SPARQLWrapper internally, triggering that unconditional close.

Some possible approaches:

1. Have __exit__/__aexit__ delegate to ClientManager rather than calling close directly, since the manager already has the ownership logic
2. Have queries()/updates() use ClientManager.acontext() directly instead of going through SPARQLWrapper's context protocol since thhey only need the async client anyway.
3. Some combination of the above.

[lu-pl]

Thanks @dev-dsp, I shall have a closer look at this.

Generally, queries and updates are simply convenience methods with very limited scope, they are sync wrappers around async code for use cases where one only wishes to run several queries asynchronously and be done. If one wishes to use connection pooling for a single call to queries or updates one can do so by passing an httpx.AsyncClient. As the README states, for anything beyond that, one should use the async interface directly.

The methods that are "unsafe" in that regard are queries and updates, so only the two sync wrappers around async code.

The limitation you mention seems necessary to me, because queries and updates need an httpx.AsyncClient internally and there is no way to close an httpx.AsyncClient from synchronous code. So if you use a sync/async wrapper and the internal async client remains open when an httpx.AsyncClient is provided explicitely, then you need to write async code just to close that aclient.

Another limitation of queries and updates is that they create an event loop and therefore cannot be used in async contexts. There might be a way to check if an event loop is already running and tap into an existing event loop, but this would be relatively complicated and the implications would have to be considered carefully.

Again, queries and udpates are just convenience methods with limited scope and applicability, for any application with more advanced async + client sharing needs, one should use the async API directly. I just thought that for library users that are not comfortable with asyncio or just want to run multiple queries asynchronously, those methods would be good to have.

[dev-dsp]

What I think is the fundamental issue: the methods currently accept a user-provided aclient but then violate the implied contract by closing it. If we can't honor the lifecycle contract, we shouldn't be using the user's client at all.

How about:
In queries() and updates(), instead of passing self._client_manager.aclient to the internal SPARQLWrapper, pass aclient_config:

def queries(self, ...):
    query_component = SPARQLWrapper(
        sparql_endpoint=self.sparql_endpoint,
        aclient_config=self._client_manager._aclient_config
    )
    # ...

This gives you:

1. User-provided clients are never touched - if someone passed aclient=my_client, it's completely ignored by queries(), so no surprise closures
2. User config is still honored - if they set aclient_config={"timeout": 30}, the internal client inherits those settings
3. Clear ownership semantics: queries()/updates() always create their own client, own it, and close it
4. Connection pooling within a single call still works - the internal client handles all the concurrent requests

The tradeoff is that queries() won't share connections with a user-provided aclient. But honestly, if someone needs that level of control, the async API is the right tool. These convenience methods work best when they stay simple.

This also omits the whole question of "which methods are safe with shared clients" - the answer becomes clean: single operations (query, aquery, etc.) can share clients, batch operations (queries, updates) always use their own.

Does that seem reasonable to you @lu-pl?