Time complexity of operations on Python's built-in types

Discussion (5 Comments)Read Original on HackerNews

alexpotato•about 2 hours ago

Dave Beazley has a great talk about using Python built ins [0] for data analysis and other quick operations.

As a meta note, I've used many of these builtins over the years but, due to LLMs, have been using them less and less. Re-watching the video almost felt like watching bushcrafters make a chair using just a knife and saw...

0 - https://www.youtube.com/watch?v=lyDLAutA88s

jjgreen•about 2 hours ago

Nice page, but odd that they have O(...) in every row, surely that belongs in the column header

wodenokoto•about 2 hours ago

Why are `min(r)` and `max(r)` for range objects o(n) ?

I thought min and max where constants stored in the object. Basically you are just asking for one of the parameters it was created with.

gpugreg•about 2 hours ago

Because the use case is very niche and nobody optimized it yet.

https://github.com/python/cpython/issues/135824#issuecomment...

`x in range(n)` is already optimized, but that was easier since the `__contains__` method already existed, but an equivalent `__min__` or `__max__` does not.

dist-epoch•about 1 hour ago

> Basically you are just asking for one of the parameters it was created with.

See, you already made a mistake:

    >>> min(range(10, 1, -3))
    4

4 is neither the min or max of the range (their actual names are start and stop), and notice how the max is the first argument and the min is the second argument

Of course, the actual implementation of constant time min/max on range would be trivial.

Time complexity of operations on Python's built-in types

⚡ Community Insights

Discussion (5 Comments)Read Original on HackerNews