René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Investigate asyncio compiler error","articleBody":"## Summary\n\nOriginally reported from: https://github.com/RustPython/RustPython/pull/6601#issuecomment-3713073297\n\n\u003c!-- Short description of the issue. --\u003e\n\n## Details\n\n\u003c!-- Whatever you want to share --\u003e\n\nwritten by @terryluan12 \n\n----\n\nAs an update, I've narrowed down the hang to an issue in the wait method of the Condition class. I **think** it's an issue with the AST generation? (but not 100%)\n\nThe test that is failing is `test_locks.ConditionTests.test_cancelled_error_re_aquire`\nThe relevant function is below\n\n```python\n\nasync def wait(self):\n    \"\"\"Wait until notified.\n\n    If the calling task has not acquired the lock when this\n    method is called, a RuntimeError is raised.\n\n    This method releases the underlying lock, and then blocks\n    until it is awakened by a notify() or notify_all() call for\n    the same condition variable in another task.  Once\n    awakened, it re-acquires the lock and returns True.\n\n    This method may return spuriously,\n    which is why the caller should always\n    re-check the state and be prepared to wait() again.\n    \"\"\"\n    if not self.locked():\n        raise RuntimeError('cannot wait on un-acquired lock')\n\n    fut = self._get_loop().create_future()\n    self.release()\n    try:\n        try:\n            self._waiters.append(fut)\n            try:\n                await fut                          # A) It reaches here fine\n                return True\n            finally:\n                self._waiters.remove(fut)\n\n        finally:\n            # Must re-acquire lock even if wait is cancelled.\n            # We only catch CancelledError here, since we don't want any\n            # other (fatal) errors with the future to cause us to spin.\n            err = None\n            while True:                             # B) The code enters a loop here to reacquire the lock\n                try:\n                    await self.acquire()            # C) While waiting here, the task is cancelled\n                    break\n                except exceptions.CancelledError as e:\n                    err = e                         # D) The code reaches here fine\n\n            if err is not None:\n                try:\n                    raise err                       # E) The error is reraised here\n                finally:\n                    err = None                      # F) It reaches here\n    except BaseException:\n        self._notify(1)                             # G) It is supposed to exit here\n        raise\n```\n\nWhereas in CPython, the program is supposed to go from F) to G), RustPython instead goes from F) to B), re-entering the final statement again (reaquiring the lock again at C), reaching a deadlock state, and hanging.","author":{"url":"https://github.com/youknowone","@type":"Person","name":"youknowone"},"datePublished":"2026-01-15T08:32:56.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/6736/RustPython/issues/6736"}