The __code__ member is an internal implementation detail of the interpreter and we will never be able to implement it. types.coroutine will need to be implemented in a way that does not need this.

And the implementation is obviously trivial: https://github.com/micropython/micropython-lib/blob/master/uasyncio.core/uasyncio/core.py#L11 and is included in an implementation of "asyncio-like" library in the standard micropython-lib: http://forum.micropython.org/viewtopic.php?f=15&t=85

I used a class as a decorator to do what types.coroutine does.

class coroutine:
    def __await__(self):
        yield from self.func(*self.args, **self.kwargs)

    def __iter__(self):
        yield from self.func(*self.args, **self.kwargs)

    def __call__(self, *args, **kwargs):
        self.args = args
        self.kwargs = kwargs
        return self

    def __init__(self, func):
        self.func = func

uasyncio is not ready for the esp8266, is it?

uasyncio is not ready for the esp8266, is it?

No, not yet.

uasyncio is not ready for the esp8266, is it?

Comparing to what? Your library which you don't know how to write? uasyncio is a generic library which works on MicroPython, period. Some ports may be not ready to run it yet. If you're interested in esp8266, try it, and report results (on the forum). That's much more useful than trying to duplicate effort.

There's no need to be hostile. I don't know where you get that I don't know how to write my library, because it's working. I was just asking because I remember seeing it as a goal on the Kickstarter campaign.

@autrilla : Sorry, but getting invalid bug tickets (yours is such) slows down our work on the goals of the Kickstarter campaign. And it's personally frustrating to see people duplicating effort, then coming with "I'm stumped, what to do?" requests instead of helping with a community effort (micropython-lib is a community effort, and people already put lot of effort into it to save other people from being stumped on simple things).