Nbconvert: Remove Python 2 compatibility code

[takluyver]

nbconvert 6.0 will require Python 3.5 or greater. We've stopped testing on Python 2, and now any compatibility code can be removed.

This is a straightforward task for new contributors. It could also be done piece-by-piece, potentially by several people, so you don't have to do one big PR. Although someone will need to decide when it's complete.

[maartenbreddels]

Is it an option to go to python36, so we can have async generators? In voila this will be helpful in the future to do the cell execution and rendering on a cell by cell basis while being async.

[MSeal]

I had mentioned that we have a large user-base for nbconvert on google infrastructure (https://cloud.google.com/ai-platform/deep-learning-vm/docs/images) which is still pinned to 3.5. Mostly I know about this from requests and interactions through papermill conversations, but the users are using a lot of jupyter tools and I think we should probably not drop 3.5 support for them immediately in the 6.x release.

Would using https://github.com/python-trio/async_generator help with cross version support for async generators you think @maartenbreddels ?

[takluyver]

Maybe if we start separating out the execution machinery, that can require 3.6 sooner than the rest of nbconvert? I don't think the rendering can be async anyway, except by doing it in a separate thread.

Alternatively, how much difference do async generators specifically make? 3.5 already has asyncio and the async/await syntax, and it's not obvious to me that we need async generators to make execution happen asynchronously.

[MSeal]

As context for this thread in the future if someone tackles some of the discussed items, if async is added it should be constrained to 3.6+ -- the 3.5 patterns have known issues that make certain things not work as expected and the work arounds can be extravagant. I think we can drop 3.5 after 6.0 release, so that's less of a concern for future implementations.

[rubywerman]

I'm interested in working on this. I've started looking for Python 2 code that should be removed and am trying to figure out the best place to start. My idea is to start by removing py3compat calls because it seems like these function calls are being used to deal with string issues in Python 2 code. Additionally, py3compat is part of ipython_genutils, whose repo states "this package shouldn't exist."

Does this seem like a reasonable first step?

[MSeal]

@rubywerman Yes that sounds like a good place to start. Thanks for offering to help. Another place to look for python2 specific code snippets are around try blocks catching exceptions for python2/3 cases, PY3 variable references, and term unicode appearing.