[catching up on old threads] On Tue, Mar 18, 2008 at 5:47 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Adam Olsen wrote: > > I'd tend to assume only *purely* functional languages should have > > asynchronous interrupts. Any imperative language with them is > > suspect. > > Yet there are situations where *not* having any such thing > can be extremely inconvenient. > > If I'm performing some background calculation that only > munges on its own data, and doesn't touch anything shared, > it's quite safe to kill it at any point and throw away > everything it was working on.
Maybe it should be a forked subprocess then, if it doesn't touch anything shared? > Being unable to do that from outside means that I have > to sprinkle explicit tests through it for an abort flag, > which is a horrible thing to have to do from a software > engineering standpoint for many reasons. > > In the consenting-adults environment of Python, I don't > like having a useful facility withheld from me just > because it's possible to misuse it. Huh? We do that all the time. We won't let you control when memory is deallocated. We won't let you call __hash__ when you've overridden __eq__ but not __hash__; there are zillions of examples. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
