@@ -7,14 +7,14 @@ Worth noting that if an extension accidentally holds onto a interned string,
7
7
event after calling Py_Finalize, it will result in use-after-free error,
8
8
leaving the user to a potential vulnerabilities. That said, the history of
9
9
how these interned strings are handled have been changing during throughout
10
- different versions. For example:
10
+ different versions.
11
11
12
- * In Python 3.9 and older, interned strings were never deleted. Only special
13
- build for Valgrind and Purity cleared them at exit.
14
- * In Python 3.10 and 3.11, interned strings are always deleted at exit.
15
- * In Python 3.12, interned strings are deleted only if Python is built in
16
- debug mode: they are not deleted in release mode.
17
- * In Python 3.13, interned strings will now be akll deleted.
12
+ For example, in Python 3.9 and older, interned strings were never deleted.
13
+ Only special builds for Valgrind and Purity cleared them at exit. In Python
14
+ 3.10 and 3.11, interned strings are always deleted at exit. In Python 3.12,
15
+ interned strings are deleted only if Python is built in debug mode: they
16
+ are not deleted in release mode. In Python 3.13, interned strings will
17
+ now be all deleted.
18
18
19
- Given how we've changed guarantees throughout different versions, we do not
20
- expect that users actively rely on this behavior for their extensions.
19
+ Given how the guarantees changed throughout different versions, it is not
20
+ expected that users actively rely on this behavior for their extensions.
0 commit comments