Оптимизация пула строк Python Interpreter

Увидев этот вопрос и его дубликат, вопрос остался для меня.

Я получаю то, что is и == , и почему, если я запускаю

 a = "ab" b = "ab" a == b

Я True . Вопрос здесь будет ПОЧЕМУ это происходит:

 a = "ab" b = "ab" a is b # Returns True

Поэтому я сделал свое исследование, и я нашел это . Ответ говорит, что интерпретатор Python использует пул строк. Поэтому, если он видит, что две строки одинаковы, он присваивает один и тот же id новому для оптимизации.

Пока здесь все в порядке и ответа. Мой реальный вопрос – почему этот пул происходит только для некоторых строк. Вот пример:

 a = "ab" b = "ab" a is b # Returns True, as expected knowing Interpreter uses string pooling a = "a_b" b = "a_b" a is b # Returns True, again, as expected knowing Interpreter uses string pooling a = "ab" b = "ab" a is b # Returns False, why?? a = "ab" b = "ab" a is b # Returns False, WHY??

Так что для некоторых символов кажется, что пул строк не работает. Я использовал Python 2.7.6 для этих примеров, поэтому я думал, что это будет исправлено в Python 3. Но после того, как вы попытаетесь использовать те же примеры в Python 3, появятся те же результаты.

Вопрос: Почему оптимизация потоков не оптимизирована для этих примеров? Не лучше ли Python оптимизировать это?

Изменить: если я запускаю "ab" is "ab" возвращает True . Вопрос в том, почему использование переменных возвращает False для некоторых символов, но True для других.

One Solution collect form web for “Оптимизация пула строк Python Interpreter”

Ваш вопрос является дубликатом более общего вопроса « Когда python выбирает ставить строку », правильным ответом на то, что это интернирование строк, является спецификой реализации .

Интерпретация строк в CPython 2.7.7 описана очень хорошо в этой статье: Внутренние интернатуры Python . Информация в нем позволяет объяснить ваши примеры.

Причина, по которой строки "ab" и "a_b" интернированы, тогда как "ab" и "ab" не являются, это то, что первые выглядят как идентификаторы python, а последние – нет.

Естественно, интернирование каждой строки приведет к затратам времени исполнения. Поэтому интерпретатор должен решить, стоит ли задавать строку. Поскольку имена идентификаторов, используемых в программе python, встроены в байт-код программы как строки, строки, подобные идентификаторам, имеют более высокий шанс получить выгоду от интернирования.

Краткий отрывок из вышеупомянутой статьи:

Функция all_name_chars исключает строки, которые не состоят из букв ascii, цифр или символов подчеркивания, т.е. строк, похожих на идентификаторы:
 #define NAME_CHARS \ "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz" /* all_name_chars(s): true iff all chars in s are valid NAME_CHARS */ static int all_name_chars(unsigned char *s) { static char ok_name_char[256]; static unsigned char *name_chars = (unsigned char *)NAME_CHARS; if (ok_name_char[*name_chars] == 0) { unsigned char *p; for (p = name_chars; *p; p++) ok_name_char[*p] = 1; } while (*s) { if (ok_name_char[*s++] == 0) return 0; } return 1; } 
Учитывая все эти объяснения, мы теперь понимаем, почему 'foo!' is 'foo!' 'foo!' is 'foo!' оценивается как False тогда как 'foo' is 'foo' значение True .