Ссылка на сложность Python? - программирование

Есть ли ссылка на сложность Python? В cppreference, например, для многих функций (таких как std:: array:: size или std:: array:: fill) существует раздел сложность, который описывает их сложность работы, с точки зрения линейности по размеру контейнера или константа.

Я бы ожидал, что такая же информация появится на веб-сайте python, возможно, по крайней мере для реализации CPython. Например, в справочной таблице, в list.insert я ожидаю увидеть сложность: linear; Я знаю, что этот случай (и многие другие операции, связанные с контейнером) покрываются здесь, но многих других случаев нет. Вот несколько примеров:

В чем сложность tuple.__le__? Похоже, что при сравнении двух кортежей размера n, k сложность составляет около O(min(n,k)) (однако при малом n он выглядит иначе).
В чем сложность random.shuffle? Кажется, это O(n). Также представляется, что сложность random.randint составляет O(1).
Какова сложность метода строк __format__? Он кажется линейным по размеру входной строки; однако он также растет, когда число соответствующих аргументов возрастает (сравните ("{0}"*100000).format(*(("abc",)*100000)) с ("{}"*100000).format(*(("abc",)*100000))).

Я знаю, что (а) на каждый из этих вопросов можно ответить сам по себе, (б) можно посмотреть на код этих модулей (хотя некоторые из них написаны на С), и (в) StackExchange не список рассылки python для пользовательских запросов. Итак: это не запрос функции-документа, а вопрос двух частей:

Вы знаете, существует ли такой ресурс?
Если нет, знаете ли вы, в чем место, чтобы спросить об этом, или вы можете предположить, почему мне это не нужно?

Ответ 1

CPython довольно хорошо разбирается в своих алгоритмах, а временная сложность операции, как правило, лучше всего подходит для хорошей стандартной библиотеки.

Например:

Порядок упорядочивания должен быть O (min (n, m)), поскольку он работает путем сравнения по элементу.

random.shuffle - O (n), потому что сложность современного Fisher-Yates тасовалась.

.format Я предполагаю, что он линейный, так как требуется только одно сканирование через строку шаблона. Что касается разницы, которую вы видите, CPython может быть достаточно умным, чтобы кэшировать тот же самый формат кода, который использовался дважды.

В документах упоминается временная сложность, но обычно только тогда, когда это не то, что вы ожидаете - например, поскольку deque реализуется с двусвязным списком, он явно указано как имеющее O(n) для индексации в середине.

Не могли бы ли документы получить временную сложность, вызванную повсеместно? Я не уверен. Документы обычно содержат встроенные функции, с помощью которых они должны использоваться и которые оптимизированы для этих случаев использования. Подчеркивание временной сложности похоже на то, что это будет либо бесполезным шумом, либо побуждает разработчиков вторгаться в реализацию самой реализации Python.