Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
(Also, there might be some interaction with PEP 492 here, which also tweaks the definition of generators.) On Sat, Apr 18, 2015 at 9:38 AM, Guido van Rossum wrote: > That's a good question. We *could* make it so that you can subclass > Generator and instantiate the instances; or we could even make it do some > structural type checking. (Please file a pull request or issue for this at > github.com/ambv/typehinting .) But perhaps we should also change asyncio? > What check are you talking about? > > On Fri, Apr 17, 2015 at 10:35 PM, Stefan Behnel > wrote: > >> Guido van Rossum schrieb am 17.04.2015 um 23:58: >> > The ``typing`` module defines the ``Generator`` type for return values >> > of generator functions. It is a subtype of ``Iterable`` and it has >> > additional type variables for the type accepted by the ``send()`` >> > method and the return type of the generator: >> > >> > * Generator, used as ``Generator[yield_type, send_type, return_type]`` >> >> Is this meant to accept only Python generators, or any kind of object that >> implements the coroutine protocol? I'm asking because asyncio currently >> suffers from an annoying type check here, so I'd like to avoid that this >> problem keeps popping up again in other places. >> >> Stefan >> >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (python.org/~guido) > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
That's a good question. We *could* make it so that you can subclass Generator and instantiate the instances; or we could even make it do some structural type checking. (Please file a pull request or issue for this at github.com/ambv/typehinting .) But perhaps we should also change asyncio? What check are you talking about? On Fri, Apr 17, 2015 at 10:35 PM, Stefan Behnel wrote: > Guido van Rossum schrieb am 17.04.2015 um 23:58: > > The ``typing`` module defines the ``Generator`` type for return values > > of generator functions. It is a subtype of ``Iterable`` and it has > > additional type variables for the type accepted by the ``send()`` > > method and the return type of the generator: > > > > * Generator, used as ``Generator[yield_type, send_type, return_type]`` > > Is this meant to accept only Python generators, or any kind of object that > implements the coroutine protocol? I'm asking because asyncio currently > suffers from an annoying type check here, so I'd like to avoid that this > problem keeps popping up again in other places. > > Stefan > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
Guido van Rossum schrieb am 18.04.2015 um 18:38: > That's a good question. We *could* make it so that you can subclass > Generator and instantiate the instances; or we could even make it do some > structural type checking. (Please file a pull request or issue for this at > github.com/ambv/typehinting .) Done: https://github.com/ambv/typehinting/issues/89 > But perhaps we should also change asyncio? > What check are you talking about? https://hg.python.org/cpython/file/439517000aa2/Lib/asyncio/coroutines.py#l169 The current (3.5alpha) check in iscoroutine() is an instance check against _COROUTINE_TYPES, which contains types.GeneratorType and another wrapper type. It excludes objects that implement the coroutine protocol without being Python generators, e.g. Cython compiled generators, which mimic the Python generator interface without having byte code in them (meaning, they are not C-level compatible with Python generators). I'm sure the same applies to other compilers like Numba or Nuitka. Supporting asyncio in recent Python releases thus means monkey patching _COROUTINE_TYPES and adding another type to it. Given that it's not a public interface, this seems a bit fragile. It also seems that this code only appeared somewhere in the 3.4.x release series. Older versions were even worse and did a straight call to inspect.isgenerator() in their iscoroutine() function, which means that the whole function needed to be replaced and wrapped (and even that didn't fix all places where inspect was used). I guess I should open a (CPython) ticket for this topic, too... Stefan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
Stefan Behnel schrieb am 18.04.2015 um 19:39: > Guido van Rossum schrieb am 18.04.2015 um 18:38: >> That's a good question. We *could* make it so that you can subclass >> Generator and instantiate the instances; or we could even make it do some >> structural type checking. (Please file a pull request or issue for this at >> github.com/ambv/typehinting .) >> >> But perhaps we should also change asyncio? >> What check are you talking about? > > https://hg.python.org/cpython/file/439517000aa2/Lib/asyncio/coroutines.py#l169 > > The current (3.5alpha) check in iscoroutine() is an instance check against > _COROUTINE_TYPES, which contains types.GeneratorType and another wrapper > type. It excludes objects that implement the coroutine protocol without > being Python generators, e.g. Cython compiled generators, which mimic the > Python generator interface without having byte code in them (meaning, they > are not C-level compatible with Python generators). I'm sure the same > applies to other compilers like Numba or Nuitka. Supporting asyncio in > recent Python releases thus means monkey patching _COROUTINE_TYPES and > adding another type to it. Given that it's not a public interface, this > seems a bit fragile. > > It also seems that this code only appeared somewhere in the 3.4.x release > series. Older versions were even worse and did a straight call to > inspect.isgenerator() in their iscoroutine() function, which means that the > whole function needed to be replaced and wrapped (and even that didn't fix > all places where inspect was used). Hmm, looks like I remembered it incorrectly. Monkey patching the inspect module is required in both versions as it's being used in more places, especially the coroutine wrappers. I'll see how I can get it working with Cython and then open tickets for it. Stefan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
Maybe the thing to fix then is the inspect module, not asyncio? Anyway, let is know via tickets. On Sat, Apr 18, 2015 at 12:29 PM, Stefan Behnel wrote: > Stefan Behnel schrieb am 18.04.2015 um 19:39: > > Guido van Rossum schrieb am 18.04.2015 um 18:38: > >> That's a good question. We *could* make it so that you can subclass > >> Generator and instantiate the instances; or we could even make it do > some > >> structural type checking. (Please file a pull request or issue for this > at > >> github.com/ambv/typehinting .) > >> > >> But perhaps we should also change asyncio? > >> What check are you talking about? > > > > > https://hg.python.org/cpython/file/439517000aa2/Lib/asyncio/coroutines.py#l169 > > > > The current (3.5alpha) check in iscoroutine() is an instance check > against > > _COROUTINE_TYPES, which contains types.GeneratorType and another wrapper > > type. It excludes objects that implement the coroutine protocol without > > being Python generators, e.g. Cython compiled generators, which mimic the > > Python generator interface without having byte code in them (meaning, > they > > are not C-level compatible with Python generators). I'm sure the same > > applies to other compilers like Numba or Nuitka. Supporting asyncio in > > recent Python releases thus means monkey patching _COROUTINE_TYPES and > > adding another type to it. Given that it's not a public interface, this > > seems a bit fragile. > > > > It also seems that this code only appeared somewhere in the 3.4.x release > > series. Older versions were even worse and did a straight call to > > inspect.isgenerator() in their iscoroutine() function, which means that > the > > whole function needed to be replaced and wrapped (and even that didn't > fix > > all places where inspect was used). > > Hmm, looks like I remembered it incorrectly. Monkey patching the inspect > module is required in both versions as it's being used in more places, > especially the coroutine wrappers. I'll see how I can get it working with > Cython and then open tickets for it. > > Stefan > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
