-
-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for PEP 567 #420
Comments
Yeah, What I'm thinking we should do is deprecate Unfortunately, we don't currently have any way to test on a recent 3.7 snapshot (travis-ci/travis-ci#9119), so probably that will need to be resolved first. In particular, we'll need to write tests for our workalike implementation, and I want to run those tests against the real thing too to make sure we don't accidentally mess up the semantics! (BTW, just in case you haven't seen |
Oh, and we'll want to be calling |
It looks like Travis's It did occur to me that for supporting older Pythons, then instead of having Personally I'd be happy with a version of this library that was in pure Python and didn't bother monkeypatching asyncio, but I think @1st1 has been thinking about a more ambitious backport project, so CC'ing him to get his thoughts. |
pypi doesn't have |
PEP 567 got accepted on the 22nd, adding context-local variables to Python 3.7, and it would be super useful to have implemented (especially for something I'm working on).
However, 3.5/3.6 compat is an issue, and if it wasn't for that I would've PR'd in already (since the change is probably super trivial,
msg = task.coro.send(next_send)
->context = contextvars.copy_context(); msg = context.run(task.coro.send, next_send)
or similar.), and I don't know how that would be solved.The text was updated successfully, but these errors were encountered: