RE: Mutable Bytes

Lenard Lindstrom wrote:

>I can only guess that in Python character strings were used 
>for binary data to keep down the number of built-in types. 

>Also a function's compiled byte code is stored as a string. 
>Byte code is a low level feature that is not considered 
>portable across versions. So it makes sense to discourage 
>direct manipulation of the byte code. If Prothon binary data 
>is made visible within the language as byte strings does it 
>make sense to allow direct changes to them?

If bytecodes were an attribute of a function like you have always suggested,
you'd be able to change them whether the bytecodes themselves were in a
mutable object or not.  Just as you can change a string attribute of
something even though a string is immutable.

Also, the problem you bring up is a perfect candidate for the security
feature.  You could easily set the bytecode object write access to system
level and then nobody could ever touch it.

By the way, I think you are getting your wish.  I am in the middle of
restructuring my objects for the new copying garbage collector and
binary-data is stored directly inside objects now instead of being linked to
in a separate malloc.  Every function is copied before it is called and my
old way of storing the bytecodes in the binary-data section of an object is
now inefficient because the bytecodes would be copied on every call.  Having
the bytcodes in a separate Bytes object would mean the shallow function copy
wouldn't have to copy the bytecodes on every call.  So I'm moving the
bytecodes to an attrbiute of the function like you have always said it
should be.

Another change I am mentioning in my talk is on my to-do list.  The scope
object for functions will now be the actual function object itself.  So all
local variables will be attributes of the function also.  This means every
attribute like fParams_ better have the trailing underbar. :-)