Are generator-coroutines really the answer?
summary
Claim: generator-coroutines let code linearize state machines and externalize stopping criteria, but practical costs appear: Python ≥3.6 async/await and yield from get used, itertools and pandas/numpy/Scipy reveal mismatches, and composition requires reimplementing chainlike helpers. Timing shows decisions cost ~1 μs while small work is ~ns so eager kernels dominate; for slower 1 ms tasks generators help. Pumping/priming and the first-rest modality force awkward wrappers; demos (data pipeline, Uno) sometimes run but need extra plumbing and fragile priming.
AI-written summary · about
chapters (10)
- 0:00Generator-coroutines intro
- 4:19Terminology confusion
- 10:34Lazy vs eager computation
- 15:45Homogeneity in generators
- 20:41Iteration helpers benefits
- 28:01State machines with generators
- 33:56First-rest modality issues
- 37:28Composition limits
- 40:18Practical challenges
- 41:21Answer: generator-coroutines?
related talks
01h 29mStandardised Coroutine Concurrency in Python 3
26mGenerators, coroutines and nanoservices
49mGenerators Will Free Your Mind
01h 26mBeyond Python Enhanced Generators
41mMore About Generators
01h 00mCoroutine Concurrency in Python 3 with asyncio
59mGet to grips with asyncio in Python 3
01h 26mBeyond Python Enhanced Generators