Asynchronous? about osfclient

[betatim]

dockerspawner for jupyterhub is where I have seen it. There the number of threads is set to one on purpose for the executor but that is because of docker (I think) not a general limitation.

---

first he made us remove nice python3 only syntax and noooooww "python2 compat is not a hard requirement" :-p

[betatim]

What is the use case you have in mind?

Short answer: Not really.

Longer answer: I assume you mean the library part of osfclient right? I think the biggest hurdle/burden would be finding something that works both in python2 and python3 in terms of async. I haven't kept an eye on this: is there a async replacement for requests?

Something we should definitely think about is how to make it easy/not get in the way of making osfclient (the library) appear to be async by putting calls to it into a ThreadPoolExecuoter. This approach works quite well for jupyterhub which is a tornado application wanting to make calls to the sync docker client.

Would this kind of compromise work for what you had in mind?

[jonathon-love]

yeah, we'd like to use it in jamovi

https://www.jamovi.org

but yeah, i think you're right. the challenge will be python2 compatibility.

according to this:

http://docs.python-requests.org/en/master/user/advanced/#blocking-or-non-blocking

grequests and requests-futures are async alternatives.

maybe i'll take a look at the jupyter hub, because we're a tornado application as well, and if that approach just works ...

cheers

jonathon

[ctb]

from my perspective py2 compatibility is nice but certainly not critical in the long term, especially if there are good reasons to abandon it.

…

--t