> but with FANTASTIC libraries written in C _and FORTRAN_
ftfy - it's the only way a tragically slow language like Python can keep up.
Edit: didn't forget FORTRAN
ftfy - it's the only way a tragically slow language like Python can keep up.
Edit: didn't forget FORTRAN
For the vast majority of use cases, performance just isn't a priority. Doubly so for Python, that shines for simple automation, command line applications, and perhaps some serveless computing.
Being easy to write, having a good ecosystem of libraries, and being widely known is typically good enough. I wouldn't use Python to write a robust backend server side application, mostly because the language doesn't lend itself well for it.
If it was too slow, we'd be doing all of this in Java, the C# or maybe doing it in C/Fortran. But because of some early design decisions (Guido being on the matrix-sig helped), the history behind Numeric/Numarray and finally NumPy and SciPy being based on those efforts allowed it to thrive.
Those were your words, not mine. I need not make any assumptions.
I just replied listing use cases where Python shine due to its strengths, performance being mostly irrelevant. I didn't even mention data science.
And although it's beyond the point, if I was to use Python, why should I care in which language a library was written? If the language allows libraries written in other languages, this is actually a nice feature.
That’s actually my primary use case for python, playing with C/C++ libraries in a repl because they don’t natively have one.
Sure, it takes work to wrap a library but that’s something I enjoy doing.
That is simply not true. Even libraries like numpy, scipy and scikit-learn are majority python code.
https://stackoverflow.com/questions/1825857/how-much-of-nump...
Just wait until they learn the python interpreter is written in C… <grabs popcorn>