Rationale for read-only property of co_code

[=?ISO-8859-1?Q?Jo=E3o_Neves?=]

Hello all,

I've got this question that has been nagging me for a few days now.
What are the reasons for us to have co_code as read-only? I've been
trying to get some info about it, but I kept hitting the wall.

Correct me if I'm wrong, but as far as I understand, co_code
represents the compiled bytecode that should be run when, for
instance, a function is called. Wouldn't it be beneficial for
programmers to be able to change the bytecode in runtime? I mean, one
can't, as far as I'm aware, change the bytecode by accident, so if the
programmer would wish to change a function at runtime, he could do so
at his own risk.

If there is a higher reason behind the read-only property of co_code,
I definitely fail to see it, and would like to know what it is. If
not, why aren't we allowed to write into it?

Thanks in advance,

João Neves

[castironpi]

On Apr 2, 5:00*am, João Neves <[e-mail]:

Hello all,

I've got this question that has been nagging me for a few days now.
What are the reasons for us to have co_code as read-only? I've been
trying to get some info about it, but I kept hitting the wall.

Correct me if I'm wrong, but as far as I understand, co_code
represents the compiled bytecode that should be run when, for
instance, a function is called. Wouldn't it be beneficial for
programmers to be able to change the bytecode in runtime? I mean, one
can't, as far as I'm aware, change the bytecode by accident, so if the
programmer would wish to change a function at runtime, he could do so
at his own risk.

If there is a higher reason behind the read-only property of co_code,
I definitely fail to see it, and would like to know what it is. If
not, why aren't we allowed to write into it?

Thanks in advance,

João Neves

Are Python bytes codes Python byte codes? Do you foresee any machine-
dependent optimizations?

[Diez B. Roggisch]

I'm not quite sure I understood your question, sorry.

And you won't. He's one of the resident trolls... Better killfile him
ASAP :)

Diez

[=?ISO-8859-1?Q?Jo=E3o_Neves?=]

On Apr 3, 4:43 am, Scott David Daniels <[e-mail]:

Nope: If you change the code in-place, the whole stack's references
to where they were running would need to get updated to corresponding
locations in the new code. _That_ is a lot of work.

Ah, there it is. Now I get it, it makes perfect sense.
Looks like I'll have to stick to the usual mechanisms!
Thanks everyone!

---
João Neves

[Peter Otten]

João Neves wrote:

Let me give a very basic example. Say we have these two functions:

I suppose you mean

>>def inc(x): return x + 1

....

>>def dec(x): return x - 1

....

>>inc(1), dec(1)

(2, 0)

Examining the compiled bytecodes for these two functions:

>inc.func_code.co_code

'|\x00\x00d\x01\x00\x17}\x00\x00d\x00\x00S'

>dec.func_code.co_code

'|\x00\x00d\x01\x00\x18}\x00\x00d\x00\x00S'

Now suppose that I wanted to mess with inc, and have it behave like
dec.

>>inc.func_code = dec.func_code
inc(1), dec(1)

(0, 0)

There you are, and there wasn't even a slight chance that you combined the
byte code with an incompatible function signature ;)

Peter