Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Alex Grönholm
@agronholm
since when?
Devin Fee
@dfee
2017
Alex Grönholm
@agronholm
but how can that be? flask is a synchronous framework still, or has that changed too?
Devin Fee
@dfee
I know the pyramid guys were playing with it and got it working as underpinnings. If it works there, it can work for flask.
I don’t see any production level packages supporting a flask asgi binding, though
Alex Grönholm
@agronholm
I don't see any way that could work sanely
anyway, that's not the point
but how it can help asphalt
if you're saying asgi is pointless for asphalt, how do you propose that asphalt should offer support for web apps?
given the upcoming focus on hyperio, the best way would of course be to offer its own http server
Devin Fee
@dfee
What support does asphalt not already provide for web apps? It’s foundational and web frameworks can sit on top
I have like 10 lines that connect my aiohttp app and a container component.
Alex Grönholm
@agronholm
that is a crutch
Devin Fee
@dfee
Probably another 20 that’s a middleware for adding contexts to the request (which I’m not sure is a good idea anyway)
Alex Grönholm
@agronholm
the context is the very foundation of asphalt
without it, all you have is a runner
Devin Fee
@dfee
Sure. But if I have a long lived web socket connection, I need to make sure im not tying up a sqla session, etc.
Sqla connection / session
Alex Grönholm
@agronholm
sure, but websocket connections should get special treatment
Devin Fee
@dfee
Yes. So maybe a context shouldn’t be created for them.
Alex Grönholm
@agronholm
normal web requests should have a context created, however
Devin Fee
@dfee
So I can do some preemptive work and see if upgrade headers come through and prevent a context from being created ... but I still need to have a child context from somewhere...
Alex Grönholm
@agronholm
yes, and that will need a parent
Devin Fee
@dfee
Without looking at the code... can a closed context have open children?
Alex Grönholm
@agronholm
there are probably no checks for that but you should not try that
Devin Fee
@dfee
Haha
Devin Fee
@dfee
@agronholm i think i once knew... but where do you draw the distinction between resource and component. for example, i have a PubSub class that could either be a component or a resource of an aioredis component (not asphalt-redis).
Devin Fee
@dfee
of course component in itself is a leaky abstraction (it can be a resource itself). but a resource isn't necessarily a component. so it'd appear that components are more "reusable".
Alex Grönholm
@agronholm
the point of a component is to set up one or more resources
and as you said it can be a resource itself
Mike Nerone
@mikenerone_gitlab
Is there a way I can add a lazy resource? Much like a resource_factory, except I don't want it to be context-specific. I want just one instance of the thing, but have it only created on demand (because the setup is expensive, and only needed if/when a user asks for certain operations).
Mike Nerone
@mikenerone_gitlab
I could use a resource factory that creates resource instances that are thin wrappers around an underlying shared object, but it seems like it might be a fairly common need, so I thought there might be a better trick. (btw, I'm constrained to Asphalt 4.0.0 by management for the moment).
Alex Grönholm
@agronholm
@mikenerone_gitlab you could create a resource factory that returns the same resource regardless of the context
not sure what other solution you had in mind
Mike Nerone
@mikenerone_gitlab
omg, of course!
Can't believe I wasn't seeing the forest for the trees
Thanks much! Related question: This expensive resource has some async setup it needs to do (it needs to fetch some details from an API before it's ready). Right now, it seems like a resource factory has to be a sync callable. Is that correct? (btw, I realize that even if async setup is possible, it implies that only request_resource() could be supported for the initial creation)
Alex Grönholm
@agronholm
@mikenerone_gitlab I guess you could publish an awaitable as a resource, using the actual target class as the type
but there is no machinery in place to make request_resource await on that awaitable too
Mike Nerone
@mikenerone_gitlab
I'm not a GUI guy, but I need to write a GUI tool that uses my asphalt-based app library. Anyone have suggestions for what GUI framework to use that would work well with Asphalt and/or advice on getting started?
Alex Grönholm
@agronholm
anything that has asyncio integration should work
PyQT will probably be okay but I don't think I've ever seen any really good integration with a GUI event loop
Mike Nerone
@mikenerone_gitlab

Just noticed a problem (while working with the Quamash Qt-based asyncio event loop implementation, but it's a general problem in using asphalt with alternate event loops). From run_application():

    if event_loop_policy:
        create_policy = policies.resolve(event_loop_policy)
        policy = create_policy()
        asyncio.set_event_loop_policy(policy)
        logger.info('Switched event loop policy to %s', qualified_name(policy))

The entry point is expected to point at a callable (presumably a class), and that gets called with no arguments to create the policy object that is then passed to set_event_loop_policy(). That's fine for the stdlib policies and probably most third-party ones, too, but some policies need additional arguments.

Quamash is an example. Note that it doesn't currently provide a policy (see harvimt/quamash#26, but I've got a trivial implementation for my own use), but even in theory, the policy object will need a reference to the Qt application with which it should be associated. Cases like this are why set_event_loop_policy() leaves it to the caller to pass the pre-instantiated policy object. Asphalt's style of doing the instantiation on the caller's behalf precludes this possibility.
Mike Nerone
@mikenerone_gitlab
Of course, the caller can get around this by calling set_event_loop_policy() themselves before run_application(), but by that argument, the event_loop_policy argument doesn't even need to exist. The support built into run_application() is just a little wonky in not considering this need.
Fortunately, it seems to me like this can be fixed in a backward-compatible way while still providing the needed support in the call to run_application(). Currently, the event_loop_policy argument passed to run_application() is expected to be None or an entry point name (str). You could simply have it also except an instantiated policy object, which it then would use directly.
Alex Grönholm
@agronholm
@mikenerone_gitlab I had never encountered an event loop policy that requires this
this would've been a non-issue in the next major version of asphalt which is based on AnyIO
Alex Grönholm
@agronholm
would you mind creating an issue for this? I can fit this into the 4.X series of Asphalt core if you want
Mike Nerone
@mikenerone_gitlab
Yes, I can do that. It's a travel day for me. Give me a few hours.