[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

Blaze Spinnaker added the comment: I know this issue is closed, but can you folks review: https://github.com/ipython/ipykernel/issues/548#issuecomment-713637954 The nest_asyncio patch is becoming a defacto contract to fixing this amongst a lot of people. But the patch doesn't really event

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

Yury Selivanov added the comment:  -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

Andrew Svetlov added the comment: Let's close the issue as "won't fix". Third-party loop implementation *can* be reentrant but we don't want to encourage people to use this pattern in stdlib. -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

Jason Fried added the comment: Yeah I have to agree at this point, from a naive point of view it looks awesome, but its just as bad as loosing gil guarantees. On Mon, Aug 26, 2019 at 03:04 Andrew Svetlov wrote: > > Andrew Svetlov added the comment: > > The solution produces subtle and

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

Andrew Svetlov added the comment: The solution produces subtle and error-prone code. It can live in third party library but not good enough for stdlib I think. -- ___ Python tracker

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

flying sheep added the comment: There’s this monkeypatching solution: https://pypi.org/project/nest-asyncio/ But yes, it’s a very practical problem that you can’t call async code from sync code that’s being called from async code. -- nosy: +flying sheep

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

Jason Fried added the comment: For loops not supporting this throwing NotImplmentedError from the method to enable reentrancy seems appropriate. "You should convert all your stack to async functions..." That may not be practical for large code bases in transition to

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

Andrew Svetlov added the comment: Sorry, no. The feature was requested many times but was constantly rejected. By this, you are adding a BLOCKING call to your async function. At least it leads to log warning about too long callback execution. Moreover, I suspect that

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

Change by Jason Fried : -- keywords: +patch pull_requests: +6540 stage: -> patch review ___ Python tracker ___

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

Change by Jason Fried : -- nosy: +lukasz.langa ___ Python tracker ___ ___

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

New submission from Jason Fried : At Facebook and Instagram we have large interconnected codebases without clear boundaries of ownership. As we move more and more services to utilize asyncio we are finding that once blocking (but fast) code paths, are now cropping up