On 05/02, Yury Selivanov wrote: > On 2015-05-02 2:14 PM, Ethan Furman wrote: >> On 05/02, Yury Selivanov wrote: >>> On 2015-05-02 1:04 PM, Ethan Furman wrote: >> And yet in current asyncio code, random generators can be accepted, and not >> even the current asyncio.coroutine wrapper can gaurantee that the generator >> is a coroutine in fact. > This is a flaw in the current Python that we want to fix. Your "fix" doesn't fix it. I can decorate a non-coroutine generator with type.coroutine and it will still be broken and a bug in my code. >> For that matter, even the new types.coroutine cannot gaurantee that the >> returned object is a coroutine and not a generator -- so basically it's just >> there to tell the compiler, "yeah, I really know what I'm doing, shut up and >> do what I asked." > > Well, why would you use it on some generator that is not > a generator-based coroutine? I wouldn't, that would be a bug; but decorating a wrong type of generator is still a bug, and type.coroutine has not fixed that bug. It's worse than mandatory typing because it can't even check that what I have declared is true. >> So either way, nothing has been added besides a mandatory boiler-plate >> requirement. > > It's not nothing; it's backwards compatibility. Please read > https://www.python.org/dev/peps/pep-0492/#await-expression I have read it, more than once. If you lift the (brand-new) requirement that a generator must be decorated, then type.coroutine becomes optional (no more useful, just optional). It is not a current requirement that coroutine generators be decorated. -- ~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4