Maybe also knowing when not to use python, or finding a solution in python that uses C/rust/etc underneath.

(2) surprised me a little. Not because of the performance consequences, but because I almost never see explicit calls to `copy()` in Python (and I read a lot of Python).

I think maybe a more realistic example there would be people using splatting without realizing/internalizing that it performs a full copy, e.g.

    xs = [1, *ys] 

Another one that stood out was (3). Slots are great, but >95% of the time I'd expect people would want to use `slots=True` with dataclasses instead of manually writing `__slots__` and a constructor like that. `slots=True` has worked since Python 3.10, so every non-EOL version of Python supports it.

There's some genuinely interesting tips in here, but #10 is for sure just padding so they could call the article "10 Hacks" haha. Everything else is at least somewhat Python specific, but "Hack 10: Avoid repeated function calls in loops" is just applicable to anything.

Some helpful guidelines, but it's 2025 and people still use time.time and no stats with their benchmarks :(

In general I feel like these kind of benchmarks might change for each python version, so some caveats might apply.

a smart hack for performance is don't use python

> Copying large objects like lists […] can be costly in both time and memory.

> modify[ing] objects in place […] improves performance by avoiding the overhead of allocating and populating new structures.

AFAIK the poor performance of list copies (demonstrated in the article by a million-element list taking 10ms) doesn’t come from memory allocation nor from copying the contents of the list itself (in this case, a million pointers).

Rather it comes from the need to chase all of those pointers, accessing a million disparate memory locations, in order to increment each element’s reference count.