I have a straightforward question about the str object, specifically     the PyUnicodeObject.  I've tried reading the source to answer the     question myself but it's nearly impenetrable.  So I was hoping     someone here who understands the current implementation could answer     it for me.
    
    Although the str object is immutable from Python's perspective, the     C object itself is mutable.  For example, for dynamically-created     strings the hash field may be lazy-computed and cached inside the     object.  I was wondering if there were other fields like this.  For     example, are there similar lazy-computed cached objects for the     different encoded versions (utf8 utf16) of the str?  What would     really help an exhaustive list of the fields of a str object that     may ever change after the object's initial creation.  Thanks!
    
    
    We now return you to the debate about the pathlib module,
    
    
    /arry
   ">

(original) (raw)



I have a straightforward question about the str object, specifically the PyUnicodeObject. I've tried reading the source to answer the question myself but it's nearly impenetrable. So I was hoping someone here who understands the current implementation could answer it for me.

Although the str object is immutable from Python's perspective, the C object itself is mutable. For example, for dynamically-created strings the hash field may be lazy-computed and cached inside the object. I was wondering if there were other fields like this. For example, are there similar lazy-computed cached objects for the different encoded versions (utf8 utf16) of the str? What would really help an exhaustive list of the fields of a str object that may ever change after the object's initial creation. Thanks!


We now return you to the debate about the pathlib module,


/arry