4 ms·
As someone who happens to be eternally grateful to the author for his contribution to the Python ecosystem [0], I kinda feel like this comment thread is overrea
by boomskats 4y ago
As someone who happens to be eternally grateful to the author for his contribution to the Python ecosystem [0], I kinda feel like this comment thread is overreacting to his overreaction. When I look at this post all I see is a useful, well explained, byte-size writeup that a search engine might recommend to someone looking for help in writing async Python.
Maybe it's because a bunch of my friends are Scottish and I get their sense of humour.
[0]: https://rich.readthedocs.io/ https://rich.readthedocs.io/ (yes I'm talking about the fancy new progress bar that pip got recently)
- vore 4y agoTo me, the surprise here is that usually you don’t expect Python finalizers to do something like this: when they dispose something, it’s usually unobservable from the perspective of the program, e.g. an unreachable file descriptor. Here, the runtime is disposing something that is still observably in progress, which is surprising behavior.
- deleted 4y ago[deleted]
- quietbritishjim 4y agoI do wish he dwelt on task groups a bit more at the end. Many comments here seemed too have missed that bit. They're not just a handy way of executing a hack. Instead, they're a revolutionary way (ok maybe that's a but string but not much) to structure your async program to avoid a whole host of bugs. A code snippet would have been nice, or a link to the blog post that introduced them (in trio, another async library): https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
- quietbritishjim 4y ago*bit strong
- ravloony 4y agoI also came here to say this. Structured concurrency gets rid of these types of problems.