Skip to content

Fix types.coroutine to accept objects from Cython #68504

Description

@1st1
BPO 24316
Nosy @gvanrossum, @ncoghlan, @scoder, @1st1
Dependencies
  • bpo-24315: collections.abc: Coroutine should be derived from Awaitable
  • Files
  • coroutine.patch
  • types_coroutine.patch
  • types_coroutine.patch
  • types_coroutine.patch
  • types_coroutine.patch
  • types_coroutine.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/1st1'
    closed_at = <Date 2015-05-29.20:21:09.464>
    created_at = <Date 2015-05-28.16:31:52.508>
    labels = ['library']
    title = 'Fix types.coroutine to accept objects from Cython'
    updated_at = <Date 2015-05-29.21:11:28.466>
    user = 'https://github.com/1st1'

    bugs.python.org fields:

    activity = <Date 2015-05-29.21:11:28.466>
    actor = 'yselivanov'
    assignee = 'yselivanov'
    closed = True
    closed_date = <Date 2015-05-29.20:21:09.464>
    closer = 'yselivanov'
    components = ['Library (Lib)']
    creation = <Date 2015-05-28.16:31:52.508>
    creator = 'yselivanov'
    dependencies = ['24315']
    files = ['39536', '39548', '39551', '39555', '39556', '39557']
    hgrepos = []
    issue_num = 24316
    keywords = ['patch']
    message_count = 14.0
    messages = ['244315', '244373', '244386', '244391', '244393', '244394', '244399', '244406', '244408', '244409', '244412', '244413', '244414', '244419']
    nosy_count = 5.0
    nosy_names = ['gvanrossum', 'ncoghlan', 'scoder', 'python-dev', 'yselivanov']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue24316'
    versions = ['Python 3.5', 'Python 3.6']

    Activity

    1. 1st1 commented on May 28, 2015

      @1st1
      MemberAuthor

      Stefan,

      This patch should solve the problem with types.coroutine accepting only pure python generator functions.

      The approach is, however, slightly different from what you've proposed. Instead of having a wrapper class (delegating .throw, .send etc to a wrapped object), we now simply check if the returned value of the wrapped function is an instance of collections.abc.Coroutine. bpo-24315 enables duck typing for coroutines, so if a cython-based coroutine implements all coroutine abstract methods, it will automatically pass types.coroutine.

    2. self-assigned this
      on May 28, 2015
    3. added
      stdlibStandard Library Python modules in the Lib/ directory
      on May 28, 2015
    4. python-dev commented on May 29, 2015

      python-devmannequin
      Mannequin

      New changeset 7356f71fb0a4 by Yury Selivanov in branch '3.5':
      bpo-24316: Fix types.coroutine() to accept objects from Cython
      https://hg.python.org/cpython/rev/7356f71fb0a4

      New changeset 748c55375225 by Yury Selivanov in branch 'default':
      bpo-24316: Fix types.coroutine() to accept objects from Cython
      https://hg.python.org/cpython/rev/748c55375225

    5. scoder commented on May 29, 2015

      @scoder
      Contributor

      I just noticed that I hadn't used the real "types.coroutine" in my Py3.5 tests when reporting back in bpo-24017. When I pass a Cython generator through it, I get

      """
      Traceback (most recent call last):
        File "tests/run/test_coroutines_pep492.pyx", line 245, in test_coroutines_pep492.CoroutineTest.test_func_5 (test_coroutines_pep492.c:13445)
          for el in bar():
        File "/opt/python3.5/lib/python3.5/types.py", line 197, in wrapped
          'non-coroutine: {!r}'.format(coro))
      TypeError: callable wrapped with types.coroutine() returned non-coroutine: <generator object at 0x7f178c458898>
      """

      This is actually obvious, given that the sole purpose of the decorator is to turn something that is a Generator and *not* a Coroutine into something that is a Coroutine, as a means for the user to say "but I know better". So checking for the return value being a Coroutine is wrong. Instead, it should check that it's a Generator and if it's not an Awaitable, wrap it as a self-returning Awaitable. That's more or less what my proposed implementation in bpo-24017 did:

        class types_coroutine(object):
          def __init__(self, gen):
              self._gen = gen
      
          class as_coroutine(object):
              def __init__(self, gen):
                  self._gen = gen
                  self.send = gen.send
                  self.throw = gen.throw
                  self.close = gen.close
      
              def __await__(self):
                  return self._gen
      
          def __call__(self, *args, **kwargs):
              return self.as_coroutine(self._gen(*args, **kwargs))
    6. 1st1 commented on May 29, 2015

      @1st1
      MemberAuthor

      I just noticed that I hadn't used the real "types.coroutine" in my Py3.5 tests when reporting back in bpo-24017.

      Please test thoroughly the attached patch.

    7. scoder commented on May 29, 2015

      @scoder
      Contributor

      One failing test in "test_coroutines": test_func_5. The reason is that the GeneratorWrapper is not iterable (and there is no reason it shouldn't be, given that it wraps a Generator). That was my fault, I had already added an __iter__ method but didn't copy it in my previous message. Adding it as follows fixes the test for me:

          def __iter__(self):
              return self.__wrapped__

      Alternatively, "__iter__ = __await__" would do the same.

    8. scoder commented on May 29, 2015

      @scoder
      Contributor

      BTW, it's not only for compiled generators but also for normal Python functions that construct Python generators internally and return them, or that delegate the generator creation in some way. With this change, it's enough to decorate the constructor function and not each of the potential generators that it returns.

    9. reopened this on May 29, 2015
    10. 1st1 commented on May 29, 2015

      @1st1
      MemberAuthor

      Please test the attached patch.

      BTW, it's not only for compiled generators but also for normal Python functions that construct Python generators internally and return them

      You're right, that's why I used "primarily" word in that comment ;)

      types.coroutine() is only used by asyncio.coroutine() so far, and returning generator objects from "factory" functions isn't a very common pattern in asyncio.

    11. 1st1 commented on May 29, 2015

      @1st1
      MemberAuthor

      Updated patch. Wrapper now proxies gi_code, gi_running and gi_frame

    12. scoder commented on May 29, 2015

      @scoder
      Contributor

      Ok, now the problem with *this* patch is that __iter__ and __await__ are special methods that are being looked up on the type, not the instance. Similarly __next__, I think, as it also has its own (type) slot. But I think you're right that __next__ is also needed here.

      I'm attaching a patch that works for me.

    13. 1st1 commented on May 29, 2015

      @1st1
      MemberAuthor

      I'm attaching a patch that works for me.

      Looks like we were working in parallel ;) I've incorporated your changes. Please look at the new patch (hopefully this one is final)

    14. scoder commented on May 29, 2015

      @scoder
      Contributor

      Your latest patch works for me.

    15. python-dev commented on May 29, 2015

      python-devmannequin
      Mannequin

      New changeset 8080b53342e8 by Yury Selivanov in branch '3.5':
      bpo-24316: Wrap gen objects returned from callables in types.coroutine
      https://hg.python.org/cpython/rev/8080b53342e8

      New changeset c0434ef75177 by Yury Selivanov in branch 'default':
      bpo-24316: Wrap gen objects returned from callables in types.coroutine
      https://hg.python.org/cpython/rev/c0434ef75177

    16. 1st1 commented on May 29, 2015

      @1st1
      MemberAuthor

      Committed. Thanks, Stefan!

    17. 1st1 commented on May 29, 2015

      @1st1
      MemberAuthor

      Stefan, please take a look at this issue bpo-24325 too.

    18. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    stdlibStandard Library Python modules in the Lib/ directory

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions