On Fri, May 31, 2013 at 5:22 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Thu, 30 May 2013 16:40:52 +0000, Steven D'Aprano wrote: > >> On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote: > >>> You're assuming you can casually hit Ctrl-C to stop an infinite loop, >>> meaning that it's trivial. It's not. Not everything lets you do that; >>> or possibly halting the process will halt far more than you intended. >>> What if you're editing live code in something that's had uninterrupted >>> uptime for over a year? >> >> Then more fool you for editing live code. > > Ouch! That came out much harsher than it sounded in my head :( > > Sorry Chris, that wasn't intended as a personal attack against you, just > as a comment on the general inadvisability of modifying code on the fly > while it is being run.
Apology accepted :) You're right that, in theory, a staging area is a Good Thing. But it's not always feasible. At work, we have a lot of Pike code that really does keep running indefinitely (okay, we have yet to get anywhere near a year's uptime for administrative reasons, but it'll be plausible once we go live; the >1year figure came from one of my personal projects). While all's going well, code changes follow a sane progression: dev -> alpha -> beta -> live with testing at every stage. What happens when we get a problem, though? Maybe some process is leaking resources, maybe we come under some kind of crazy DOS attack, whatever. We need a solution, and we need to not break things for the currently-connected clients. That means editing the live code. Of course, there are *some* protections; the new code won't be switched in unless it passes the compilation phase (think "except ImportError: keep_existing_code", kinda), and hopefully I would at least spin it up on my dev box before pushing it to live, but even so, there's every possibility that there'll be a specific case that I didn't think of - remembering that we're not talking about iteration from constant to constant, but from variable to constant or constant to variable or variable to variable. That's why I would prefer, in language design, for a 'failed loop' to result in no iterations than an infinite number of them. The infinite loop might be easily caught on my dev test - but only if I pass the code through that exact code path. But to go back to your point about editing live code: You backed down from the implication that it's *foolish*, but I would maintain it at a weaker level. Editing code in a running process is a *rare* thing to do. MOST programming is not done that way. It's like the old joke about the car mechanic and the heart surgeon (see eg http://www.medindia.net/jokes/viewjokes.asp?hid=200 if you haven't heard it, and I will be spoiling the punch line in the next line or so); most programmers are mechanics, shutting down the system to do any work on it, but very occasionally there are times when you need to do it with the engine running. It's like C compilers. Most of us never write them, but a few people (relatively) actually need to drop to the uber-low-level coding and think about how it all works in assembly language. For everyone else, thinking about machine code is an utter waste of time/effort, but that doesn't mean that it's folly for a compiler writer. Does that make sense? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
