Refresh examples to ensure that they run in current version

[dwskoog]

I found to bugs in the main code by refreshing the examples to work under the current API:

• Source.from_tcp could kill the TCP socket because it assumed the result of self.source._emit was always awaitable.
  • I added another test to push two inputs over the same socket to keep that from happening
• core.flatten in 0.6.4 would skip over empty iterables, but the change to handle no-length iterables made it raise a spurious StopIteration under the same condition.
  • I added a test to feed an empty list to flatten to show the behavior.
  • This behavior change broke our production unit tests when I finally got a moment to upgrade to 0.6.5

Example refreshes:

• I rebuilt the URL scraper example to work in Python3 with the BeautifulSoup4 which is how I found the flatten change and then I ran updated my company's product code to 0.6.5 and immediately ran into the StopIteration fault in our test suite.
• I redid all of the Fibonacci examples to look similar and run the same.

Unit tests:

• I added the Standard Hack from the Python docs to find an open port and used that in test_tcp_word_count_example to make it less flaky.

[martindurant]

Thank you, and I have not forgotten #493 either.

There is some code to ensure that if any of the nodes are asynchronous, then all of them should be. So _emit not returning an awaitable - that happens in the case that a node cannot be async? Is there an argument that streamz should standardise on async nodes only?

[dwskoog]

Thank you, and I have not forgotten #493 either.

There is some code to ensure that if any of the nodes are asynchronous, then all of them should be. So _emit not returning an awaitable - that happens in the case that a node cannot be async?

The from_tcp and _emit fix I included came from the network word count example. It was the most expedient way of getting the example working.

From going back through the code around Source/Stream creation, it seems that the example as written guarantees that the resultant stream is synchronous:

streamz/examples/network_wordcount.py

Lines 10 to 11 in 8c73290

	s = Stream.from_tcp(9999)
	s.map(bytes.split).flatten().frequencies().sink(print)

streamz/streamz/sources.py

Line 40 in 8c73290

super().__init__(ensure_io_loop=True, **kwargs)

streamz/streamz/core.py

Lines 258 to 259 in 8c73290

	if ensure_io_loop and not self.loop:
	self._set_asynchronous(False)

I believe that is why the _emit call was not returning an Awaitable and the server ended up killing the socket when trying to await it anyway. As far as I understand the deeper plumbing of Stream, this was executing the actual work in an event loop just in a different thread and so the stream itself was returning the end result instead of a Task representing the work and subsequent result.

Is there an argument that streamz should standardise on async nodes only?

I think as a framework there is probably value in both threaded and asyncio support. The asyncio module/design appears to be fairly polarizing in the larger Python ecosystem. A significant number of projects that I run into in the wild forswear it entirely while others are asyncio-only. Our historical code is non-asyncio/multiprocessing and our more current work is all asyncio-native. We've definitely had difficulties supporting both.