mike bayer <mike...@zzzcomputing.com> added the comment:
> With greenlets OTOH, it becomes possible for another task to observe > someobj.a == 1 without someobj.b == 2, in case someobj.__setattr__ internally > invoked an await_(). Any operation can potentially invoke a context switch. > So debugging greenlets code is roughly as hard as debugging full-on > multithreaded code, and much harder than debugging async/await code. I would invite you to look more closely at my approach. The situation you describe above applies to a library like gevent, where IO means a context switch that can go anywhere. My small recipe never breaks out of the asyncio event loop, and it only context switches within the scope of a single coroutine, not to any arbitrary coroutine. So I don't think the above issue applies. Additionally, we are here talking about *libraries* that are independently developed and tested distinct from end-user code. If there's a bug in SQLAlchemy, the end user isn't the person debugging that. arguments over "is async or sync easier to debug" are IMO pretty subjective and at this point they are not relevant to what sync-based libraries should be doing. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22239> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
