> We can not compare two Unicode by pointer even if both are interned anymore... It was a nice optimization.

If two strings are interned and part of the same interpreter, the "ptr1 == ptr2" comparison continues to work.

What is not compatible with subinterpreters, which have other interned string objects, is the assumption that two interned strings are not equal if both strings are interned and pointeres are not equal.

_PyUnicode_EqualToASCIIId() is the only function making this assumption.

* dictkeys_stringlookup(): if pointers are not equal, compare the hash: if the two hashes are equal, compare the strings content with unicode_eq()

* PyUnicode_Compare(): if pointers are not equal, compare the strings content with unicode_compare()

* _PyUnicode_EQ(): always compare the strings content

* PyUnicode_RichCompare(): if pointers are not equal, compare the strings content

None of these functions have a fast path for interned strings. Well, _PyUnicode_EqualToASCIIId() is different since right is always an interned string.


Note: unicode_compare() is strange, it requires both strings to be equal, but it does not consider that two strings are not equal if their kinds are not equal. If both strings are ready and their kinds are not equal, the two strings cannot be equal... unicode_compare_eq() returns 0 if the two kinds are not equal.