This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dino.viehland
Recipients dino.viehland, eric.snow, methane
Date 2019-05-29.01:55:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1559094927.91.0.556706781636.issue36839@roundup.psfhosted.org>
In-reply-to
Content
Sure, but immutable/const is almost always a language level guarantee.  The only case where that's not true is when you have OS/hardware level memory protection and that doesn't apply to any of Python's existing byte codes.

So from a Python perspective, code objects are remaining immutable - they can only be created by objects which expose the read-only buffer protocol.  So for example passing in a memoryview(b'abc') will work here while a memoryview(bytearray(b'abc')) will fail.  And because when asking for a non read-write view the buffer implementer needs to be consistent  for all callers (https://docs.python.org/3/c-api/buffer.html#c.PyBUF_WRITABLE) it seems that this invariant should hold for all objects being passed in.

Could someone create a buffer object which still allows the underlying memory to be written?  Sure.  But I can use ctypes to modify byte code today as well with something like "ctypes.cast(id(f.__code__.co_code) + 32, ctypes.POINTER(ctypes.c_char)) [0] = 101" 

So people will still be able to do nasty things, but there are certainly 
guards in place to strongly discourage them from doing so.
History
Date User Action Args
2019-05-29 01:55:27dino.viehlandsetrecipients: + dino.viehland, methane, eric.snow
2019-05-29 01:55:27dino.viehlandsetmessageid: <1559094927.91.0.556706781636.issue36839@roundup.psfhosted.org>
2019-05-29 01:55:27dino.viehlandlinkissue36839 messages
2019-05-29 01:55:27dino.viehlandcreate