Idea: quick'n'dirty Python 3.6 support

[orent]

Python 3.4 is really old. The oldest version still widely supported is 3.6. This makes it difficult, for example, to use IronPython with packages from PyPI and other more modern code. IronPython3 already supports many of the newer features (e.g. f-strings), but cannot claim to be 3.6 until it can at least parse Python 3.6 source code without a SyntaxError.

The idea is to add minimal parser support for async/await so they do not cause a SyntaxError. In the mean time, it can produce a placeholder coroutine object that raises an exception if actually used. It should be OK for an alpha version to have partial support and it will instantly be more useful than Python 3.4 as there are many useful packages that do not require async support. Full async support can be added later on whatever schedule you already had planned.

The parser should also support PEP 526 variable type annotations without raising SyntaxError. The annotations can be simply discarded. Porting the new standard library modules should be relatively straightforward. The pathlib module will require adding support for the fspath() in the core.

[slozier]

It's an interesting idea. I have a local branch that targets 3.5 which works fairly well after commenting out the few async/await instances that appear in the standard library. I can try to extend the exercise and target 3.6 to see what the pain points would be.

I guess my main concerns are:

• Having multiple branches to test and maintain (although maybe we could release a 3.4-beta and then bump the main branch to 3.6-alpha).
• Packages that may not work without async/await. I haven't done any testing so I don't know if this is actually an issue, but if "core" packages such as pip, requests or whatever were to have an async/await dependency it may complicate matters.

Anyway, I'll run some tests to see what sticks out...

[BCSharp]

I think that upgrading the parser to be able to parse Python 3.6 is a very good idea, even if it turns out that there are other blocking issues in StdLib to bump up to 3.6. This is how some features of 3.4 were done too: e.g. nonlocal was first implemented in the parser, and the actual support for it came later.

I share @slozier's concern for having to maintain/test two branches and the idea to do one more release (3.4-beta) and then bump to 3.6 seems to me the most appealing.

[pm64]

Just wondering if there's been any further thinking on this. At this point I'm not able to use IronPython in the majority of my projects because they require 3.6.