On Thu, Jan 9, 2014 at 10:53 AM, Dan Stromberg <drsali...@gmail.com> wrote: >> Using Python 3.4 (which isn't yet >> stable, but you can download betas) also gives you an asyncio module, >> but I'd leave that aside for the moment; first figure out threading, >> it's likely to be easier. > > Personally, I don't like asynchronous I/O, EG twisted. It tends to > give very complex, uniprocessor solutions to problems, even when those > problems have quite simple, alternative solutions. I'd rather just > accept and fork in most cases, with or without multiprocessing.
I haven't used the Python asyncio module yet (haven't gotten around to it, no other reason), but in my Pike work, I've gotten quite friendly with a callback system. It plays nicely with the structure I have for code reloading, by separating code and data, and then simply running everything off a single thread, one callback at a time. Works really well when everything's waiting anyway. It does force you to think about things differently, though. Case in point: My MUD client allows an arbitrary number of code files to inspect a line of text that the user's entered, before it goes to the server. Any one of them can suppress the line, in which case subsequent hooks won't see it and it won't go to the server. What about changing the line as it goes through? That's easy enough, I guess. But what if that change involves a popup message and user response... or a network request to a remote server? (I do, in fact, have exactly that. Long URLs get shortened via tinyurl.com.) A threaded model wouldn't even help much, here, unless I'm prepared to spawn a separate thread for every command the user enters, which is stupid overhead. Instead, I have a function that reinjects the line and carries on as if it hadn't been suppressed in the first place. Maybe it's not the best way to do things, but it can be extremely simple in the code. Most operations don't even need the continuation-call mechanism that I used there; mostly, everything's just (conceptually) "when this happens, call this function". The fact that they're serialized doesn't matter. Events from the GUI, incoming socket data (on any socket - there might be multiple), time-delay events (eg a ticking clock), etc - everything works the same way. It's really easy once you get your head around it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
