Python is basically a DSL for C extensions. That is the whole point. It would be like criticizing any compiled language for essentially being a DSL for machine code, and not "Real Instructions".
Python's ability to interop with pre-built, optimized libraries with a lightweight interface is arguably its greatest selling point. Everyone and their dog knows purely interpreted CPython is slow. It doesn't need to be pointed out every single time python performance is brought up unless literally discussing optimizing the CPython vm.
* looking up a reference of an attribute with a string key underpins the meat and potatoes of python's execution model
* it’s a subclass of dict
* its update method (used by the code in the post) dispatches to a C implementation on its fast path
If you say "it does not count as Real Python if you dispatch to C", then you literally cannot execute any CPython vm opcodes, because it's all dispatching to C under the hood.
https://github.com/python/cpython/blob/4395ff1e6a18fb26c7a66...
isn’t exactly pure Python, because, under a different runtime (eg PyPy), the code would take a different path (the “pure Python” implementation of _count_elements[1] instead of the C implementation[2][3]). Yes, it's hard to draw exact lines when it comes to Python, especially as the language is so tied to its implementation. However, I think in this case it's relatively clear that the code that specific line is calling is an optimization in CPython, specifically intended to get around some of the VM overhead. Said optimization comes into play in the OP.
[1]: https://github.com/python/cpython/blob/4395ff1e6a18fb26c7a66...
[2]: https://github.com/python/cpython/blob/4395ff1e6a18fb26c7a66...
[3]: https://github.com/python/cpython/blob/4395ff1e6a18fb26c7a66...
Apparently there will be someone who feels the need to point it out; and someone who feels the need to point out that it doesn't need to be pointed out; and …
https://github.com/python/cpython/blob/main/Lib/collections/...