[python] structured concurrency & trio?

[thearchitector]

I'd love for python GLIDE to support the Trio async runtime. I started porting it over, but have run into some fairly fundamental complications resulting from the fact that the current python wrapper is pretty firmly rooted in unstructured concurrency (free-floating tasks, no strict cleanups or closures, etc.)

That is to say, I'm wondering what the general attitude toward breaking API changes is. I'm a pretty firm believer in structured concurrency and the benefits it provides in terms of state and error management, and would gladly do the work to migrate the client to it, but it would naturally result in a pretty drastic change in how the client can be used. Namely, and uncompromisingly, from:

client = await GlideClient.create(...)
...
await client.close()

to this, and all the downstream structural changes it implies in users' codebases:

async with GlideClient(...) as client:
    ...

As more and more libraries adopt an async-agnostic approach with AnyIO (FastAPI, Starlette, httpx, etc.), I'd be a bit bummed for this library to not be compatible with that trend.

[avifenesh]

Hi @thearchitector :)
I was in the middle of answering you on the Valkey conversation you opened.
Got too long, so I took a break ;)

To be fair I'm not a python professional and I'll wait for additional and better input from the other in the team.

But a few points -
I went to read about trio and anyio, and it seems like a correct way of working, and an interesting project.

But I'm not sure everyone here will be familiar with those, especially considering that each team member has proficiency with a bunch of languages, but not with all.
We still try to make decisions as a team, and break or not to break is clearly a question for the whole wide team regardless of which area in the project.

I think it would be very beneficial if you can bring more information, pros and cons, adoption, users needs, how it was handled in other projects etc.
The discussion will be much more to the topic, than a generic one about breaking changes.

Besides that, few general points.

At the moment, python sync is under development. So there's a current major work on python, and i think that further changes will need to be slowed down for a bit.

The general rule is to not break compatibility.
We sometimes will overload an API for the correctness of it, but will avoid removing the old one for a while, until it's safe to do so.
We are going to introduce a breaking change in the next major, but it is a result of having no choice but to do so, and we are waiting for a major for it.

I would ask, that as part of the information we would love to see, to have an idea if such change can be overloaded, or to be optional, as opposed to complete rewrite.

Our priorities are strongly derived from community input.
We didn't get this request until now, and that affects the importance of it. If data on usage and adoption exist it would be very beneficial.

[thearchitector]

I think it would be very beneficial if you can bring more information, pros and cons, adoption, users needs, how it was handled in other projects etc.... I would ask, that as part of the information we would love to see, to have an idea if such change can be overloaded, or to be optional, as opposed to complete rewrite.... We didn't get this request until now, and that affects the importance of it.

All of this makes sense. While I can definitely provide more color as to my personal opinions and experiences with using the basic approach AnyIO and Trio take, transparently, I acknowledge the changes required would be sufficient enough to require input from, and discussion with, a fair number of other people with varying degrees of experience and opinion.

Disclaimer given, from my perspective, it's a lot more conceptual than anything else. I found the design principles outlined by Trio, and the structural concurrency argument made by its primary author in this PyCon talk @ 14:51, particularly convincing. For the most part, I think a lot of the arguments boil down to determinism: being able to assume certain things always happen without engineering a complex system to make it so. It's a more "modern" way of dealing with unhappy paths.

For some context, with the (comparatively) small amount of time I've spent looking at the Python lib here, here are a few examples:

• Server-side exceptions: There's a single GlideClient, which spawns background tasks responsible for sending requests and waiting for results. When there are closure exceptions, it's the responsibility of the tasks to pass around those exceptions to parent/child tasks to ensure the client doesn't ignore them. From a control-flow POV, and code maintenance one, that's tricky to keep straight (and indeed, there are places where those exceptions are getting counter-intuitively swallowed because nothing is responsible for handling them). In the structured world, those exceptions would actually propagate.
• Resource closures: When you split .create and .close methods, it's really easy to forget to gracefully clean stuff up. Users basically end up having to wrap stuff in nested try/catch/shield boilerplate and sacrifice pass-around-ability of the client, or write that boilerplate everywhere:

  try:
      client = await GlideClient.create(...)
      ...
  finally:
      try:
          task = asyncio.create_task(client.close())
          await shield(task)
      except Exception:
          pass

  This is why many popular async HTTP/IO clients prefer/recommend the context manager pattern, and why a lot of them can only really emit ResourceWarnings in their __del__ methods (which aren't really even guaranteed to be run anyway).

If data on usage and adoption exist it would be very beneficial.

I can try and look around to see if there is anything comprehensive, but the download stats for anyio and trio are somewhat illustrative as to their current/rising popularity in the ecosystem.

[thearchitector]

I also realized, after having given up the first time, that there is a way of using Trio sans the structural paradigms. Obviously you give up on most/all of the benefits, but doing so could be a more viable interm move that still allows the client to be used in user's legitimately structural applications (like my immediate use case).

I threw a draft PR up here.

[avifenesh]

Sorry for the response delay. In recovery mode. Will answer as soon as I'm back on my legs.

But something that might be missing conceptually in your approach.

Glide is not the same as other clients.
It is a multiplexer, you don't have a connection pull to use by request, or different connections perform different tasks.

There's just one connection in use, in most cases, and you shouldn't close it, but reuse it.
Moreover, the client mainly deals with issues internally and propagates just what is not possible to take care of.
For example bad args, or cluster down.

The option i see valid for that case is to create, similar to the Transaction object, and also for the transaction object, a command object, in which you can do:
with command do so you can have structured control over operations.
But as opposed to files, sockets, and similar, the use case of creating the client and closing it is not really a thing, and the client restoration and fix is done by the library itself.

[thearchitector]

i don't think that's a misalignment, just a matter of scope -- async http libraries that expose connection pools intended to be managed across the lifespan of the application advertise the same user-facing resource policy: enter the "session"/pool context once, yield out of it, and pass the yielded client around. the cleanup policy is still delegated to the original context manager to enforce best practice

the idea of opening and explicitly closing some resource exists in pretty much every async (and non-async, though they tend to be less in-your-face) library i've used -- closing the stuff on behalf of the user vs. asking (and hoping) the user closes that stuff are just two different approaches, the former being obviously way more defensive

[avifenesh]

The thing is that glide is not a connection pool, it is a multiplexer.
As opposed to other clients, glides don't open and close connection. The lifespan of the client intended to be across all the app lifetime and to be close at close.

Glide is indeed close to resources which need to be closed, for example a connection to node which does not exist anymore, but it should, and is, encapsulated.
The user has less control, but that's the idea of using a low level client, wrapped in high level languages.
The "real" core is secure and safe and contains a lot of logic, while the interface is easy to use, and lets you act without a lot of thinking.

[thearchitector]

The argument holds less ground from a feature perspective when taken only in-and-of-itself, that's definitely true. a transaction concept where someone is a lot closer to the actual calls seems like a stronger argument for adopting a structural approach in a more clear-cut manner. i could get behind that

[thearchitector]

in addition to maintaining the unstructured-but-trio-compatible approach, that is

[avifenesh]

I think we don't want to enforce one or the other.
I think that's the idea of having an "extra" interface for a structural approach, which lets you open a scope for a command and close makes sense for users who adopt this type of development.

I can support the initiative, but the team needs to understand the need, the goal, and have data to back it.
Would you be able to bring something to present and have a discussion with the broader team?

The main questions are why do we need it, can we show users interest, and what will be the maintenance cost

[avifenesh]

closing as it is a task in progress.