Le 9 avr. 2016 03:04, "Larry Hastings" <[email protected]> a écrit :
> 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.
Yes, the hash is computed once on demand. It doesn't matter how you build
the string.
> 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?
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.
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).
I don't recall other caches.
> What would really help an exhaustive list of the fields of a str object
that may ever change after the object's initial creation.
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.
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.
You can document the PEP 393 in Include/unicodeobject.h.
Victor
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
