4 ms·
That makes sense to me, thanks for the explanation. I don't suppose you do guided tours of the Python standard library documentation? :) And I get what you're
by spangry 10y ago
That makes sense to me, thanks for the explanation. I don't suppose you do guided tours of the Python standard library documentation? :)
And I get what you're saying about having nothing against asyncio being in the standard lib: I mostly agree. You can ignore it if you don't like it. And it does allow the more skillful python devs to do pretty amazing things (e.g. sanic, that uvloop pgsql driver etc.). I guess the small niggle I have with asyncio is similar to the one have with the standard library documentation (and Gnome, for that matter): I can't understand what the authors/developers were trying to achieve when writing it.
Take the std lib documentation for instance. It's only my opinion, but there seems to be very little consistency between libraries, and much of the documentation reads like a stream of consciousness punctuated by the occasional "oh and there's this thing too". This makes it very difficult to learn about what is being documented.
I mean, that's fine, it's their project and their prerogative and it isn't all bad. But it just seems self-defeating to write documentation that is incomprehensible. I suppose one could view technical documentation as a work of art that has some kind of intrinsic artistic value... Otherwise it just seems like wasted effort to write documentation that doesn't convey information in a useful way.
Sorry this turned a bit ranty. I'm only speaking for myself here; it's entirely possible I just happen to think in a way that is very different to how the std lib doc authors do.
- digler999 10y agoI get what you're saying, that the docs dont really follow an overarching theme. Thankfully, stackoverflow fills in the rest. > I can't understand what the authors/developers were trying to achieve when writing it. I can't speak for them, but event-driven designs are a great alternative to procedural polling / event loop designs. I am not sure, but I think there's a relationship to the functional programming style where you say "when there's data, do this to it". So I think what they're trying to accomplish is to enable FP paradigms in python. You could write a coroutine that says "yield until there's data, when there is, transform it". I used it with zeromq [1] to route messages between a few C++ programs that all work together. So my python program is a "supervisor" task that sends heartbeat messages to my binary programs over zeromq. Asyncio is handy for timing the heartbeats (because you can say "in 2 seconds, do this") and reading the message queue. I also hooked it up to inotify, so I can do "echo SOME_COMMAND > command.txt" and as soon as command.txt is written to, my supervisor gets a notification, reads the file, and processes the command. I almost lost my sanity to get it working, but once I got it, I really like it. One tip though, dont try to mix async and sync programming. Go big or stay home. [1] http://zeromq.org/ http://zeromq.org/
- bigmanwalter 10y agoOftentimes the people who understand the module being documented aren't able to put themselves in a contextless reader's shoes.