<p dir="ltr"><br>
Le 9 avr. 2016 03:04, "Larry Hastings" <<a href="mailto:larry@hastings.org">larry@hastings.org</a>> a écrit :<br>
> 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.</p>
<p dir="ltr">Yes, the hash is computed once on demand. It doesn't matter how you build the string.</p>
<p dir="ltr">> 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?</p>
<p dir="ltr">Cached utf8 is only cached when you call the C functions filling this cache. The Python str.encode('utf8') doesn't fill the cache, but it uses it.</p>
<p dir="ltr">On Windows, there is a cache for wchar_t* which is utf16. This format is used by all C functions of the Windows API (Python should only use the Unicode flavor of the Windows API).</p>
<p dir="ltr">I don't recall other caches.</p>
<p dir="ltr">> What would really help an exhaustive list of the fields of a str object that may ever change after the object's initial creation.</p>
<p dir="ltr">I don't recall exactly what happens if a cache is created and then the string is modified. If I recall correctly, the cache is invalidated.</p>
<p dir="ltr">But the hash is used as an heuristic to decide if a string is "immutable" or not, the refcount is also used by the heuristic. If the string is immutable, an operation like resize must create a new string.</p>
<p dir="ltr">You can document the PEP 393 in Include/unicodeobject.h.</p>
<p dir="ltr">Victor</p>