So my personal opinion is that u should design your API independent of either 
of these (asyncio, eventlet, threads...),

I think if u design the key parts of your API with the future[1] concept in 
mind then you can easily connect into the future (asyncio or other).

The asyncio layer has a future wrapper of its own (it actually has its own 
future related class[2], both of which are in the standard library to add to 
the confusion/fun...),

But if you target that kind of API (one that can return async objects, futures 
or other) then I think you will be tolerant of changes for asyncio or other...

With taskflow[3] I've tried to do this. It runs tasks/atoms (a taskflow 
concept) via futures and executors (one of its executors actually runs things 
remotely), which hopefully makes it easier to switch in a asyncio executor or 
other in the future, and it also has connections to make it transparent that 
eventlet is just another future executor[4]. But I guess it becomes a question 
of what platform (3.4+) do you want to support  and what design decisions you 
are ok with making that don't affect your current system to drastically...


My 2 cents,


On Sep 12, 2014, at 2:53 PM, Eichberger, German <> 

> Hi,
> I think the “standard” threading library for OpenStack is eventlet – however, 
> it seems that Oslo is spearheading efforts to get to a more compatible one 
> (see I am now 
> wondering since we are starting fresh if we should embrace (a potential) 
> future or stick with eventlet and all its flaws?
> Thoughts?
> German
> _______________________________________________
> OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to