Jump to content

Feature Request: asynchronous API


Recommended Posts


I'd like to make a feature request for an asynchronous API. I'm using the new API and liking it so far, but I was disappointed that all network functions are still blocking like the old API. Most network APIs I have used require a callback as a parameter, so that the application is not left hanging, waiting for the result. Even better are the network APIs that use coroutines to wait for network calls such as Tornado. If this feature was added to the API it would make my day. Thanks for reading.

Link to comment
Share on other sites



Great to hear you are liking the new API.


During the design of it we did discuss at length making it fully asynchronous, but came to the following conclusions:


* The increased complexity would create a barrier for less experienced developers, contradicting our goal of approachability.

* The increased complexity would make it hard under the hood to reason about things like cache management.

* Many scripts would see no real performance improvement as the operations they make would require being sequential anyway.


One thing that we are working on though is thread safety so that the API client can more easily be shared between threads.


However, we are very interested in yours (and others) use cases so please share them here and we can discuss further.




Link to comment
Share on other sites

You make some good points. I'm using threads for the API calls so that it won't freeze the UI, but I often get errors because of it. So thread safety would also be really good to have. The error I almost always get is: 


TypeError: 'Symbol' object has no attribute '__getitem__'


I'm not exactly sure what this means, but it seems like the dynamic entity is not finished being constructed.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...