Drop Python 3.5 Support

I would like us to reconsider the base Python version after dropping 2.7 support, and use Python 3.6 instead of 3.5. The benefits of using Python 3.6 are:

• Support for variable type declarations, which are required to get serious with static typing of bokeh’s code base. Otherwise we will be able to only statically type APIs, which while being useful on its own (e.g. helping with API backwards compatibility issues), is far from what full program typing would give us.
• pathlib, or PathLike interface to be specific, support in the standard library. Given that we are introducing breaking changes anyway, it would be good to have proper pathlib support in the APIs that use paths.
• asyncio support in 3.5 is provisional and 3.6 makes it stable and adds new features (e.g. async generators and comprehensions). Given that there is ongoing work to switch from Tornado’s coroutines to async and await, 3.6 would be a better suited basis for this work.
• numpy may be dropping 3.5 soon (see NEP 29, there’s an open WIP PR with 3.5 removal).
• Availability of new versions of bokeh’s existing or prospective dependencies in the form of conda packages seems limited for 3.5.
• Fewer testing subjects, especially given the recent release of Python 3.8.
• Possibly other more or less important things (e.g. f-strings would be nice to have).

The arguments against this are:

• Python 3.5 is still supported, in security bugfix mode only, until September 2020. This doesn’t stop numpy’s and other developers from considering dropping support early. The fact that Python itself will get bug fixes, doesn’t mean that we have to actively develop software for such platform.
• There will be people left behind. This is true, tough I don’t know how big impact this would really have. I suppose marginal, but maybe someone has data to prove otherwise. I would prefer to provide improved quality software, for example with static typing, to the majority of our users, than to appease to a minority at the expense of everyone else (both users and developers of this project). At the technical level, upgrading minor Python 3.x versions should be a no-op in most cases. It’s nothing like switching from Python 2 to 3. In cases where users can’t upgrade due to bad IT culture at companies and institutions, there workarounds like Anaconda Distribution and other tools. If that’s too much, then having new shiny features in a visualization library should be really low on one’s problem list. There still will be older, perfectly usable versions of bokeh to work with on Python versions not supported anymore. I would consider supporting backporting of critical bugfixes, if feasible.

In the long run, we may want to align development of this project with NEP 29, though that’s a separate concern. Hopefully my views on this subject aren’t too radical and this proposal will gather enough support to proceed as outlined.

[jsignell]

Yeah it seems that the more recent versions aren’t getting any py3.5 downloads

[bryevdv]

@jsignell thanks for digging in to this!

Given that we currently seem to have a broad agreement and no strong calls (or any calls) in the other direction, as well as arguments and evidence that supports the decision, I think we can talk about next steps, which I think would be:

• BEP-5 needs to be updated including leaving an edit history with a link to this discussion.

• A new issue needs to be made around drafting a BEP-6 for codifying our python version tracking practices (i.e our version of NEP 29)

I guess the only question is whether we want to appeal any harder for additional input first? @birdsarah also relayed her support for this in a personal conversation. So there’s a clear majority of @bokeh/core in favor. Are there any other stakeholders in particular we could/should ping? Or even a public call to comment of some sort?