On Wed, Apr 2, 2008 at 2:33 PM, João Neves <[EMAIL PROTECTED]> wrote: > On Apr 2, 5:41 pm, "Dan Upton" <[EMAIL PROTECTED]> wrote: > > > The thing I've been wondering is why _is_ it read-only? In what > > > circumstances having write access to co_code would break the language > > > or do some other nasty stuff? > > > > > João Neves > > > > > I can't speak to Python's implementation in particular, but > > self-modifying code in general is unpleasant. It certainly is > > possible to support it in runtime environments, but it's usually not > > easy to do so. That is, of course, somewhat dependent on the > > implementation of the runtime environment, and even to some degree the > > underlying hardware. (For instance, the compiled code you want to run > > could be in the hardware cache; if you then change the instructions at > > those addresses in memory, it's not always straightforward to get the > > processor to realize it needs to load the new data into the > > instruction cache.) Plus, I suppose it might be possible to break > > strong (even dynamic) typing if you start changing the code around > > (although I can't construct an example off the top of my head). > > Indeed, the caching issue is a relevant one I guess, and adding the > mechanism to go around that might have a significant impact on > performance. > I haven't looked in detail into it, but I agree with your opinion > concerning strong and dynamic typing. If type check is done while > compiling to bytecode, there is no guarantee the modified bytecode > will respect the rules, for instance. I don't know though, haven't > really checked how it's done at this point. :) > I will be fiddling around with the Python VM these days anyway, and > since I'm going to muck around the bytecode, I might just try to see > the effects of removing the read-only restriction from co_code. >
There is no need to overwrite co_code. Create a new code object with your desired bytecode and use that instead. -- http://mail.python.org/mailman/listinfo/python-list
