Rationale for read-only property of co_code

[João Neves]

On 2 Abr, 21:38, "Chris Mellon" <arka... at gmail.com> wrote:
> On Wed, Apr 2, 2008 at 2:33 PM, João Neves <seve... at gmail.com> wrote:
> > On Apr 2, 5:41 pm, "Dan Upton" <up... at virginia.edu> 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.

Yes, it may work (haven't tested - isn't there any problem with stuff
like co_name, for instance?), but for simplicity's sake, wouldn't it
be far more convenient if you could just write over co_code? :)
In the end, it's all a matter of convenience, I guess.