3 ms·
Technically right, but the original code only optionally depends on Numba, and Numpy is ubiquitous in scientific Python. The problem I was trying to solve in a
by KolenCh 2y ago
Technically right, but the original code only optionally depends on Numba, and Numpy is ubiquitous in scientific Python.
The problem I was trying to solve in all those boilerplates is basically that Numpy still has overhead and dropping it to lower level is trivial if Numba is used, but the package maintainers doesn’t want to introduce Numba dependency for various reasons. And the diff is showing that change from Numpy/Numba to C++ with pybind11.
- maccard 2y agoThat doesn't change the fact that it's not representative of how many lines something takes in python vs C++. If you replaced it with a call to native that used a third party library it would be back to being one line.
- KolenCh 2y agoFirst, no sane mind will think one single example will be representative to anything. Second, if you want to focus on 3rd party or not, sure. But you could also think Numba jit vs C++ and in this case it puts them on a more equal footing to compare them. As far as Numba is concerned, numpy is in its stdlib as it aren’t calling Numpy but jit compile it. You may say Numba is not Python, true, but you could consider Numba an implementation of a subset of Python. We can argue about the details but the example is not that long to read. My summary and your summary are both at best distilled through our own point of view a.k.a. biases. Anyone can read the diff itself to judge. That’s why I link to it.
- maccard 2y agoMy point is that you replaced calling a third party library from python with an implementation in native. You could easily replace a c++ third party library with a full python implementation of the same thing and come to the opposite conclusion. The example matters because it’s bad - you’re not comparing like for like.