Feature Request: asynchronous API

[eight]

Hi,

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.

[Martin Pengelly-Phillips]

Hey,

 

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.

 

 

Martin

[eight]

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.

[Martin Pengelly-Phillips]

Yep, that looks like a threading issue. Until we add thread safety you could try putting your own threading locks around API calls or use a thread local session to mitigate.