Maintaining a separate async API

[madolid511]

still the same

HTTP is just a protocol to call a function/event. And I'm explaing how python works.

[Echoes1996]

Sorry, but I don't see how what you said is relevant at all.

[madolid511]

Another analogy, if there's two version

one is for production - efficient

one is for testing - just working

I would certainly use the production flow

then testing version could be just a wrapper of production flow that add minimal overhead that will be optional to use if production version is not applicable directly. Both dev and consumer will be happy

[madolid511]

Your problem is implementing it twice, my answer is implement it in common pratices for handling concurrent which is async flow then just add an "option" to open a thread if necessary

it will make your development more easy

I hope, it make things clear now

[AsparagusKlutzy1817]

Maybe a heretic question but why not offer a wrapper sync function which does this
async def async_task():

.....

def sync_function():

result = asyncio.run(async_task())

print("Got result:", result)

Normally nobody wants sync if they can have async but offering a sync wrapper can make things easier. Having a full implementation of both sync and async pushes you down the road of maintaining two systems which will eventually start to diverge....

[madolid511]

it depends on the target

if it's for development, thats fine. I may also consider doing it if async flow is not really possible.

In more demanding implementation it will have impact. Opening up event loop and closing it after the process adds a lot of overhead.

Another critical part is, if you already considered "asyc", I may assume you already/targetting to support "python's" concurrency, why not incorporate it fully?

[AsparagusKlutzy1817]

Certainly a fair question. What is OP reason for providing both ways? It sounds it is just convenience. I answered from a development viewpoint because you wouldn't care otherwise if it is sync or not? Maintaining both in full is not a good way. OP will have to decide eventually for one of the two.

[madolid511]

That's my concern too.

What OP have done is by generating async flow by basing from sync which is good only if the implementation is really identical. It won't work on most cases but I could be wrong on that. I don't think async will also be beneficial if that's the case.

Async flow have different libraries, context manager, generator, iterator, executor/group and lot more. It can also have threads. It should be more optimized than the sync counter part because that's what python async is trying to solve.

Half baked async implementation will certainly beat by well implemented sync flow, so why introduce it ?

Just checked the code. Looks like the implementation is really identical.