25

Is there any Python complexity reference? In cppreference, for example, for many functions (such as std::array::size or std::array::fill) there's a complexity section which describes their running complexity, in terms of linear in the size of the container or constant.

I would expect the same information to appear in the python website, perhaps, at least for the CPython implementation. For example, in the list reference, in list.insert I would expect to see complexity: linear; I know this case (and many other container-related operations) is covered here, but many other cases are not. Here are a few examples:

  • What is the complexity of tuple.__le__? It seems like when comparing two tuples of size n, k, the complexity is about O(min(n,k)) (however, for small n's it looks different).
  • What is the complexity of random.shuffle? It appears to be O(n). It also appears that the complexity of random.randint is O(1).
  • What is the complexity of the __format__ method of strings? It appears to be linear in the size of the input string; however, it also grows when the number of relevant arguments grow (compare ("{0}"*100000).format(*(("abc",)*100000)) with ("{}"*100000).format(*(("abc",)*100000))).

I'm aware that (a) each of these questions may be answered by itself, (b) one may look at the code of these modules (even though some are written in C), and (c) StackExchange is not a python mailing list for user requests. So: this is not a doc-feature request, just a question of two parts:

  1. Do you know if such a resource exists?
  2. If not, do you know what is the place to ask for such, or can you suggest why I don't need such?
Improve this question
9
  • 4
    I am not aware of a resource like that, this seems like a good fit for python-ideas! Commented Feb 5, 2014 at 9:24
  • 1
    I suspect you're going to get a lot of unsatisfying upvotes and an implicit "no" answer. Commented Feb 5, 2014 at 9:27
  • 2
    This slightly looks like an off-topic question, as OP expects an off-site resource Commented Feb 5, 2014 at 9:28
  • 10
    I don't think we're going to get spam for this, and for people to give opinionated answers about their favorite Python time-complexity documentation, we would have to first find at least one answer. I don't think the basis for that close reason really applies. Commented Feb 5, 2014 at 9:31
  • 1
    Ask your "very good" question on Quora :). Even if there is no answer atleast somebody will get an idea to have an extra line on time/space complexities of the standard library functions in the documentation just as cppreference does. However I vote to repoen your question. +1. Commented Feb 5, 2014 at 11:02

1 Answer 1

Reset to default
5

CPython is pretty good about its algorithms, and the time complexity of an operation is usually just the best you would expect of a good standard library.

For example:

Tuple ordering has to be O(min(n,m)), because it works by comparing element-wise.

random.shuffle is O(n), because that's the complexity of the modern Fisher–Yates shuffle.

.format I imagine is linear, since it only requires one scan through the template string. As for the difference you see, CPython might just be clever enough to cache the same format code used twice.

The docs do mention time complexity, but generally only when it's not what you would expect — for example, because a deque is implemented with a doubly-linked list, it's explicitly mentioned as having O(n) for indexing in the middle.

Would the docs benefit from having time complexity called out everywhere it's appropriate? I'm not sure. The docs generally present builtins by what they should be used for and have implementations optimized for those use cases. Emphasizing time complexity seems like it would either be useless noise or encourage developers to second-guess the Python implementation itself.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

It also ties their hands with respect to altering implementation. This is the reason, for example, why C++'s standard avoided specifying the time complexity of the size method to be O(1) for standard containers like vector until recently (which is why many CS courses still teach you to always test for vector.empty() rather than vector.size() == 0). Remember, even CPython is limited by the underlying C standard lib implementations, many of which themselves don't specify hard complexity constraints and instead leave it up to implementation.
it also ties the hands of alternative implementations — but then, it could arguably be a good thing to enforce that a correct Python implementation is O(1) for, say, set membership. i think the use-case approach probably does a good enough job of that though, and indeed leaves some breathing room for alternatives to do better.
I would hope we don't insist on O(1) for set membership. I don't know of any data structures for sets that can guarantee that bound in the worst case. And some really good implementations are explicitly O(log n).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.