John Belmonte

update on pending pylint missing-await checker (#700): * it's run against the entire trio codebase along with a few builtin checkers related to async/await * it properly ignores async generators...

I see that type annotations are used in a few spots already. @njsmith would you accept a PR to add type annotation to open_memory_channel() return value? ``` ./trio/_subprocess/linux_waitpid.py:async def _task(state:...

+1, but suggest unqualified names ("send", "receive")

Is the next step to file something to bpo? (I don't think I could describe this well myself) Isn't this obviously a contextlib bug-- I mean shouldn't `enter_async_context()` be equivalent...

I've tried opening a bpo issue: https://bugs.python.org/issue44594

> ```python3 > saved_context = exc_details[1].__context__ > try: > raise exc_details[1] > finally: > exc_details[1].__context__ = saved_context >``` how about changing the existing code to `raise from None`?

> Maybe contextlib would be up for fixing this upstream? The hack would be something like: > > ```python > saved_context = exc_details[1].__context__ > try: > raise exc_details[1] > finally:...

To clarify the problem case, I believe Trio is doing this: ```python3 exc = foo() try: raise exc finally: exc.__context__ = None ``` Neither ExitStack nor AsyncExcitStack are preserving the...

So back to this fix, it doesn't seem to work because `__context__` is already not `None` before raising. > ```python > saved_context = exc_details[1].__context__ > try: > raise exc_details[1] >...

Looking at `_fix_exception_context()`, there is not much wiggle room. Ultimately it's always going to overwrite `__context__` of `new_exc` unless `__context__` is already set to the old exception. The only way...