WebsocketHandler.get is async

[rmorshea]

As of Tornado v6.0.2 some methods were converted to be async/await capable. See commit:

tornadoweb/tornado@e69becb

Closes: #39

[betatim]

How could we deal with being compatible with Tornado 5 and 6 at the same time?

I was thinking https://www.tornadoweb.org/en/stable/gen.html#tornado.gen.maybe_future but that is deprecated. So maybe https://docs.python.org/3/library/inspect.html#inspect.isawaitable is the right thing to use if we should await or not?

[rmorshea]

Got it. Will make that change tomorrow.

[rmorshea]

@betatim done!

[ian-r-rose]

Recently the notebook server swapped out tornado's maybe_future for its own to deal with that deprecation: jupyter/notebook#4453 . That may be a good choice here as well.

[rmorshea]

@ian-r-rose does this problem show up in other places in this repo? I think it makes sense to use that if there's more locations where we need to address the backward compatibility.

[ian-r-rose]

@rmorshea I'm not sure. This seems to fix the immediate problem, but there may be more lurking somewhere. I confess I don't have the best grasp of websockets.

[rmorshea]

@ian-r-rose neither do I. @betatim actually debugged #39 I just made the PR.

[betatim]

I don't really know either. Having looked at the implementation of maybe_future in the notebook I am now thinking that we should use that. As with all these things it isn't as easy as just asking if isawaitable(obj). Especially as it seems that in this thread it is mostly the blind leading the blind 👀.

Does this mean that jupyter-server-proxy will require a brand new notebook package in order to work (if we use maybe_future from there)? If so that is also not ideal.

[ian-r-rose]

@betatim That's a good point. Perhaps we should try to import maybe_future, then fall back on gen.maybe_future if that fails?

[rmorshea]

@betatim used a try/except to import from notebook and then from tornado.

[betatim]

Merged. Thanks for this!