Rationale for read-only property of co_code

[castironpi at gmail.com]

On Apr 2, 11:41 am, "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).
>
> In short, you need a good reason to support self-modifying code, and
> my guess is nobody could come up with one for Python.
>
> -dan

Not in the least.  You can avoid a lot of if statements, if you have
so many, by enumerating functions to call.  "Then call this", i.e.
turn functions on and off.  However, there may be data structures
which can accomplish this in constant time too... any takers?