скорость .loc, .iloc и устаревший .ix. Почему бы не использовать .ix?

Question

Существует несколько вопросов о переполнении стека, сравнивающих loc, iloc и ix, таких как этот , и несколько вопросов о разнице в скорости, таких как этот .Кажется, что консенсус заключается в том, что .ix быстрее, но он устарел .

Это подводит меня к моему вопросу, если .ix намного быстрее, особенно в индексировании на основе меток,зачем осуждает это?Почему вы не хотите использовать более быстрый метод?Единственная причина, по которой я нашел устаревший .ix, заключается в том, что он вводит людей в заблуждение, так как работает как для меток, так и для целых чисел.Я что-то пропустил?Или единственный недостаток .ix в том, что он сбивает с толку и поэтому не может быть поддержан в будущем?

Кроме того, побочный вопрос о реализации трех методов.Как получается, что .ix быстрее и менее конкретен.Это кажется мне нелогичным.Я ожидаю, что чем более общий метод получит, тем медленнее он будет.Почему бы не написать loc и iloc, чтобы они были быстрее, чем .ix?

Answer 1

ix должен сделать предположения о том, что означают этикетки. Это не интуитивное поведение и может привести к серьезным поломкам в угловых случаях (например, когда метки столбцов сами по себе являются целыми числами). С loc вы только пропускаете ярлыки. С iloc вы передаете только целочисленные индексы позиции. Ввод очевиден, а вывод также.

Теперь, упомянутые различия в скорости имеют порядок миллисекунд или микросекунд, что представляет собой разницу "серьезно, не беспокойтесь об этом ™". Я считаю, что это достойный компромисс для более последовательного и надежного API. - сказал Нуфф.