> Can Execution Context be implemented outside of CPython
I know I'm well late to the game and a bit dense, but where in the pep is
the justification for this assertion? I ask because we buy something to
solve the same problem in Twisted some time ago:
https://bitbucket.org/hipchat/txlocal . We we
>From the PEP:
> The problem with them is that a class has to be explicitly marked to
support them, which is unpythonic and unlike what one would normally do in
idiomatic dynamically typed Python code.
> The same problem appears with user-defined ABCs: they must be explicitly
subclassed or register
> Some of the possible options for the title are
It seems like you're talking about something most other languages would
refer to as "Interfaces". What is unique about this proposal that would
call for not using the industry standard language?
> Type-hints should not have runtime semantics, beyond
> An async procedure call whose refcount reaches zero without completing
simply goes away; finally: blocks are *not* called and there is *no*
warning.
I believe OP is looking at these two scenarios:
def generator():
try:
yield None
yield None
finally:
print('finall
I agree with Barry. We need more material that introduces the community to
the new async/await syntax and the new concepts they bring. We borrowed the
words from other languages but not all of their behaviours.
With coroutines in particular, we can do a better job of describing the
differences bet
I think there may be somewhat of a language barrier here. OP appears to be
mixing the terms of coroutines and futures. The behavior OP describes is
that of promised or async tasks in other languages.
Consider a JS promise that has been resolved:
promise.then(function (value) {...});
promise.then
