On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote: > Actually, even the file system can do some of this to you. I was > checking lsof on one of my Linux systems a little while ago, and found > that I had half a dozen old versions of a program, all with the same > file name, all deleted. (When you unlink a running binary on Linux, > the program keeps running the old version, and then you can put a new > version in its place, with the same file name. Any new invocation will > pick up the new binary; existing ones keep what they have.) So a > program can unlink itself, write out a new version of itself, and > happily keep going - letting new invocations take the changed version, > safely. Again, not exactly self-modifying code... or is it? Again, > tamed by boundaries.
Your lsof example looks like a rather typical case of ugly self-modifying code Self-modifying code has many flavours; consider: $ sudo apt-get upgrade apt-get relatively harmless but self-modifying nonetheless When its more invisible its more dangerous # apt-get upgrade linux-image My understanding of Mark Harris' original reference to 'self-modifying' is a more standard, ubiquitous, ugly but indispensable example -- the use of the interactive interpreter. I write a function: def foo()... ... recursive use of foo() I then rename the foo to FOO but forget to rename the internal call For normal file/module loading one would get a straightforward error message At the interactive interpreter one gets massive confusion. Does it mean we stop playing around in the interactive environment? Hopefully not! But there are pitfalls and its good to be straight about them. As far as I can see, recursivity is the foundation of our field; self-modifying code, self-reference (y-combinator) are just some of its many faces: http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html -- https://mail.python.org/mailman/listinfo/python-list
