but of course, I can’t iterate over get_route_tabl...
# pythonp
proud-artist-4864
03/10/2019, 10:43 AMbut of course, I can’t iterate over get_route_tables (or if I encapsulate it inside another async def) because it’s a co-routine
i
incalculable-sundown-82514
03/11/2019, 5:53 PMYeah - have you been seeing that it’s a pain to break things into coroutines?
It’s a shame that data sources are really the only time when the “async-ness” of Pulumi breaks through and it’s empirically pretty confusing.
That said, if you are OK using coroutines, you can use
async forp
proud-artist-4864
03/13/2019, 6:22 AMit means that I have to have the async for inside yet another async def 🙂
proud-artist-4864
03/13/2019, 6:27 AMIt’s doable, but clumsy. What I’d really like is if “get_route_tables” returned a list of route53.RouteTables, that can be iterated fine 🙂
The async stuff is sorta clumsy currently, but Python’s async is sorta clumsy in general 🙂
I think what’s needed is a way to hang the classes and functions I create off the same async loop executor so that they are able to be incorporated into the engine when it’s running. But that would mean exposing the pulumi.stack.run_in_stack in some way so that things like async for’s and async defs created by the user are also run
i
incalculable-sundown-82514
03/21/2019, 9:35 PMIt’s doable, but clumsy. What I’d really like is if “get_route_tables” returned a list of route53.RouteTables, that can be iterated fine 🙂I hear you, but because the rest of Pulumi is so asynchronous, I’m afraid that can’t be done without seriously regressing other aspects of deployment, which is unfortunate. You can use
asyncio.ensure_future