This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author zzzeek
Recipients Rokas K. (rku), crusaderky, djarb, jab, jcea, martin.panter, njs, yselivanov, zzzeek
Date 2020-07-07.20:12:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1594152773.13.0.87394393865.issue22239@roundup.psfhosted.org>
In-reply-to
Content
> 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.
History
Date User Action Args
2020-07-07 20:12:53zzzeeksetrecipients: + zzzeek, jcea, djarb, njs, jab, martin.panter, yselivanov, Rokas K. (rku), crusaderky
2020-07-07 20:12:53zzzeeksetmessageid: <1594152773.13.0.87394393865.issue22239@roundup.psfhosted.org>
2020-07-07 20:12:53zzzeeklinkissue22239 messages
2020-07-07 20:12:53zzzeekcreate