This should fix issue #616

#627 came first, what's the difference in both of your approaches?

#627 doesn't having the folding regex portion, so this PR makes sense.

#627 implements async keyword better; I think their approach is preferred.

Amend yours without the async part. Then we can accept both PR’s.

I’m working off a branch with that configuration ATM. I can confirm it works for me.

But on the other hand, async and await will become reserved keywords in Python 3.7 (and deprecated in 3.6), so it may be helpful to highlight them accordingly regardless of position - in order to avoid accidentally using them as variable names etc.
https://docs.python.org/3.6/whatsnew/3.6.html#deprecated

Good point, I added async to statements in my PR

Good point.

I’m fine with either approach.

Wouldn’t that break highlighting for lower python versions though?

It will mean that async will be highlighted as a keyword everywhere (not only with def/for/with). Not sure it's a big deal, await should be a keyword anyway to make this work.

+1 for thinking ahead. Though I wouldn’t want to break highlighting for older python versions. Most projects are still using Python 2.x at this time. It’s not always the developer’s choice what python version and conventions they use.

While it’s probably best practice for developers on lower versions to abstain from using future reserved keywords, highlighting should reflect the python version being used accurately.

Have you considered any ways to support all 3 cases, 3.4 and below, 3.5 and 3.6+

It's not a big deal to me personally. To people on legacy projects, it's hard to tell. It can be highly annoying to have local variables highlighted as keywords.

Yep, totally agree:

How about adding possibility to disable highlighting for async/await:
https://github.com/klen/python-mode/pull/627/files#diff-93673e8a4fc12998d3ba57063e333855R107

Like this let g:pymode_syntax_highlight_async_await = 0

Fixed by #627 Thank you @MarSoft !