3 ms·

> I cannot get asyncio to fit in my brain I found it extremely (to the point of a frustration-induced mental breakdown) hard. I still can't fit it all in my br

> I cannot get asyncio to fit in my brain I found it extremely (to the point of a frustration-induced mental breakdown) hard. I still can't fit it all in my brain, but I got enough so that my code works. The best explanation I can give is by analogy: think of the kernel of an OS, and how it spreads CPU time across all the processes. Sometimes processes know they dont need to work, say they're waiting for a disk read, or a network message, so they surrender and say "ok kernel, I'm done for now, let someone use CPU". Thats like what the "yield" command does in asyncio, although yield requires a context. So you say "yield until this function does something interesting" (I think it's called 'await' now), then a mini-"kernel" (the io service) stops executing that function and polls all the other functions to see if any of their yields have changed state. It just keeps polling till it finds some work it can do. I dont yet fully grok the futures yet, but I think they're just a way of packaging up the "work item" produced when a yield actually gives you something. * Disclaimer: I barely understand this, so if I'm spreading bad information I apologize in advance. I have nothing against asyncio in python, I think its presence helps put python in the "big leagues" of languages, and not just a toy for noobs with arduinos. It's an additional language feature, like C++ templates. You dont have to use it, so the noobs can keep doing their thing. But it prevents more experienced devs from outgrowing the language and having to learn a new one, or port working code to a new language.

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 ago
  I 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 ago
  Oftentimes the people who understand the module being documented aren't able to put themselves in a contextless reader's shoes.
bigmanwalter 10y ago
I've never had 'yield' explained to me so succinctly :) Thanks!

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 ago
I 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 ago
Oftentimes the people who understand the module being documented aren't able to put themselves in a contextless reader's shoes.

bigmanwalter 10y ago

I've never had 'yield' explained to me so succinctly :) Thanks!