Tornado 6.0a1

[Ben Darnell]

Happy new year everyone!

I've just uploaded the first alpha release of Tornado 6.0. This release completes the transition that began in version 5.0: Support for Python 2 has been dropped and Tornado only supports versions of Python with asyncio and native coroutines. A lot of legacy callback-based interfaces have been removed as well.  Finally, Tornado now includes full mypy-compatible type hints.

Full draft release notes are at https://www.tornadoweb.org/en/latest/releases/v6.0.0.html

You can try the alpha with `pip install tornado==6.0a1` (if it doesn't show up for you, make sure your version of pip is up to date). 

I'm interested in feedback, especially about the upgrade process (Was it hard to make the transition? Did the deprecation warnings in 5.1 do their jobs?) and the type hints (are you using mypy or interested in trying it? Does your editor do anything useful with the hints for autocomplete, etc?)

Thanks,

-Ben

[Kevin LaTona]

Hey, Ben,

Happy New Year.

About a month ago I downloaded Tornado 6.0 off Github and did some test for a AsyncHTTPClient idea.

It ran perfect with zero issues.

Your integration with Asyncio’s  library worked out seamlessly and pretty close to prefect so far ……. from what I’ve seen.

I read thru parts of the code and as always you’ve done an elegant job of incorporating static typing into Tornado and cleaning up some of the older parts.

My only problem is Python static typing, so far is not something of much use in the projects I work on.

Heck part of the reason I started to use Python 12 years ago was to get away from doing all that complier declaration junk.  ;-)

If it every leads to some one coming up with a way to compile Python into lower level machine code to create a standalone binary  and that would give me the speed of C without writing C, it might make more sense.

Past that it occurred to me that using Asyncio's loop just make's easier to take that out the equation now and allowing projects like Tornado to focus on all the other parts… basically Guido nailed a good universal working IOLoop that just works now.

The only other feedback I have is the docs could help explain when one might want to use Tornado's IOLoop calls vs just directly calling Asyncio calls, which is what I ended up doing for this early test as it just seamed easier in this case/

Overall Nice upgrade so far……. 

Thanks for all the work you keep doing on improving and fine tuning Tornado code base.

Every time I dig into the your Tornado code I generally learn something new.

-Kevin

--
You received this message because you are subscribed to the Google Groups "Tornado Web Server" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-tornad...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Kluyver]

Hi Ben,

Thanks for the pre-release. We've caught one place where we were using the deprecated @web.asynchronous decorator, which should be easy to fix.

Do you have any idea what would cause websocket_connect() to throw:

tornado.websocket.WebSocketError: Non-websocket response

We have a test which gets that error on 6.0a1, but succeeds on 5.1.1.

Thanks,
Thomas

[Ben Darnell]

On Wed, Jan 2, 2019 at 7:58 AM Thomas Kluyver <tak...@gmail.com> wrote:

Hi Ben,

Thanks for the pre-release. We've caught one place where we were using the deprecated @web.asynchronous decorator, which should be easy to fix.

Do you have any idea what would cause websocket_connect() to throw:

tornado.websocket.WebSocketError: Non-websocket response

We have a test which gets that error on 6.0a1, but succeeds on 5.1.1.

That's probably a new bug (the error means that you tried to use `websocket_connect` to connect to a server/URL that doesn't actually speak websockets). The websocket module had the most substantial changes in this release and the refactoring probably broke something. Can you tell me anything about the server endpoint you're connecting to? Is it written in Tornado or something else?

-Ben

 

Thanks,
Thomas

On Wednesday, 2 January 2019 04:12:31 UTC, Ben Darnell wrote:

Happy new year everyone!

I've just uploaded the first alpha release of Tornado 6.0. This release completes the transition that began in version 5.0: Support for Python 2 has been dropped and Tornado only supports versions of Python with asyncio and native coroutines. A lot of legacy callback-based interfaces have been removed as well.  Finally, Tornado now includes full mypy-compatible type hints.

Full draft release notes are at https://www.tornadoweb.org/en/latest/releases/v6.0.0.html

You can try the alpha with `pip install tornado==6.0a1` (if it doesn't show up for you, make sure your version of pip is up to date). 

I'm interested in feedback, especially about the upgrade process (Was it hard to make the transition? Did the deprecation warnings in 5.1 do their jobs?) and the type hints (are you using mypy or interested in trying it? Does your editor do anything useful with the hints for autocomplete, etc?)

Thanks,

-Ben

--

[Thomas Kluyver]

That's probably a new bug (the error means that you tried to use `websocket_connect` to connect to a server/URL that doesn't actually speak websockets). The websocket module had the most substantial changes in this release and the refactoring probably broke something. Can you tell me anything about the server endpoint you're connecting to? Is it written in Tornado or something else?

Yes - this was part of the test suite for Jupyter Notebook, which runs a Tornado-based server. The test starts a kernel and then attempts to connect to its websocket.

Test utility that calls websocket_connect():

https://github.com/jupyter/notebook/blob/31c2184d011e2a6b78d02f6039f0da4273a2cfb5/notebook/services/kernels/tests/test_kernels_api.py#L57-L65

Websocket handler open() method:

https://github.com/jupyter/notebook/blob/31c2184d011e2a6b78d02f6039f0da4273a2cfb5/notebook/services/kernels/handlers.py#L258

(The logic from this pretty quickly spreads out through the codebase, unfortunately, so it's not easy to get a good picture of what it's doing)

[Ben Darnell]

I've figured out what happened here: `WebSocketHandler.get()` is now a (native) coroutine, so any subclass of WebSocketHandler that overrides `get()` must now be sure to `yield` or `await` the superclass method. This is a simple fix for notebook, in AuthenticatedZMQStreamHandler:

diff --git a/notebook/base/zmqhandlers.py b/notebook/base/zmqhandlers.py

index 94f8d13af..19b5bbb29 100644

--- a/notebook/base/zmqhandlers.py

+++ b/notebook/base/zmqhandlers.py

@@ -281,7 +281,8 @@ class AuthenticatedZMQStreamHandler(ZMQStreamHandler, IPythonHandler):

         # assign and yield in two step to avoid tornado 3 issues

         res = self.pre_get()

         yield gen.maybe_future(res)

-        super(AuthenticatedZMQStreamHandler, self).get(*args, **kwargs)

+        res = super(AuthenticatedZMQStreamHandler, self).get(*args, **kwargs)

+        yield gen.maybe_future(res)

     

     def initialize(self):

         self.log.debug("Initializing websocket connection %s", self.request.path)

I'm not sure if there's a more backwards-compatible way we could have handled this. (We could have documented that prepare() is probably the more future-proof way to add authentication before the websocket handshake).  The cryptic failure behavior is unfortunate, but with native coroutines failure to await is basically equivalent to failure to call, so there's not much we can do without adding some trickery to detect this specific case (or forego the performance benefit of a native coroutine here). 

-Ben

--

You received this message because you are subscribed to the Google Groups "Tornado Web Server" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-tornad...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

[Thomas Kluyver]

Thanks Ben, I've made a pull request with the change you suggested:

https://github.com/jupyter/notebook/pull/4392