Почему по умолчанию сохраняются только буквенные строки в пуле стажеров?
Вы можете использовать pd.Series.isin .
Для «IN» используйте: something.isin(somewhere)
Или для «NOT IN»: ~something.isin(somewhere)
В качестве обработанного примера:
>>> df
countries
0 US
1 UK
2 Germany
3 China
>>> countries
['UK', 'China']
>>> df.countries.isin(countries)
0 False
1 True
2 False
3 True
Name: countries, dtype: bool
>>> df[df.countries.isin(countries)]
countries
1 UK
3 China
>>> df[~df.countries.isin(countries)]
countries
0 US
2 Germany
2 ответа
Краткий ответ: интернализация литеральных строк обходится дешево во время выполнения , а экономит память . Служебные не-литеральные строки дороги во время выполнения и, следовательно, экономят небольшое количество памяти в обмен на то, что общие случаи становятся намного медленнее .
Стоимость "оптимизации" интернирующих строк во время выполнения не окупается, и поэтому фактически не является оптимизацией. Стоимость интернирования буквальных строк дешевая и поэтому окупается.
Я отвечу на ваш вопрос более подробно здесь:
http://blogs.msdn.com/b/ericlippert/archive/2009/09/28/string-interning-and-string -empty.aspx
Внутренние строки почти не дают преимуществ в большинстве сценариев использования строк, даже если у них имеется пул интернинга со слабой ссылкой нулевой стоимости (идеальная реализация интернирования). Чтобы интернирование строк могло принести какую-либо пользу, необходимо, чтобы несколько ссылок на совпадающие строки совпадали в течение достаточно «длительного» времени.
Рассмотрим следующие две программы:
- Введите 100 000 строк из текстового файла, каждая из которых содержит произвольный текст, а затем 100 000 пятизначных чисел. Рассматривайте каждое число, считываемое в виде индекса с нуля, в список из 100 000 строк, которые были прочитаны, и выводите соответствующую строку на выход.
- Введите 100 000 строк из текстового файла, выводя каждую строку, содержащую последовательность символов «fnord».
Для первой программы, в зависимости от содержимого текстового файла, интернирование строк может привести к почти 50 000: 1 экономии памяти (если строка содержит 100 000 идентичных длинных строк текста) или может представлять общее количество отходов (если все 100 000 строк различны). В отсутствие интернирования строк входной файл с 100 000 одинаковых строк приведет к одновременному существованию 100 000 экземпляров одной и той же строки . Благодаря интернированию строк количество живых экземпляров может быть уменьшено до двух. Конечно, компилятор не может даже попытаться угадать, может ли входной файл содержать 100 000 одинаковых строк, 100 000 различных строк или что-то промежуточное.
Для второй программы маловероятно, что даже идеальная реализация интернирования строк принесет много пользы. Даже если все 100 000 строк входного файла оказались идентичными, интернирование не могло сэкономить много памяти. Эффект интернирования заключается не в том, чтобы предотвратить создание избыточных экземпляров строк, а в том, чтобы позволить идентифицировать и отбрасывать избыточные экземпляры строк. Так как каждая строка может быть отброшена после того, как она будет проверена и либо выведена, либо нет, единственной вещью, которую может приобрести интернирование, будет (теоретическая) способность отбрасывать избыточные экземпляры строк (очень) немного раньше, чем это было бы возможно в противном случае.
В некоторых случаях может быть полезно кэширование определенных «промежуточных» строковых результатов, но эту задачу действительно лучше оставить программисту. Например, у меня есть программа, которая должна преобразовывать много байтов в двузначные шестнадцатеричные строки. Чтобы облегчить это, у меня есть массив из 255 строк, которые содержат строковые эквиваленты значений от 00 до FF. Я знаю, что в среднем каждая строка в этом массиве будет использоваться, как минимум, сотни или тысячи раз, поэтому кэширование этих строк - огромный выигрыш. С другой стороны, строки могут быть кэшированы только потому, что я знаю, что они представляют. Я могу знать, что для любого n 0-255, String.Format("{0:X2}",n) всегда будет давать одно и то же значение, но я не ожидаю, что компилятор узнает это.