Yes, but from their perspective, it's an implementation detail. LAPACK could have been written in assembly language or APL, and their Python code would work just as well.

Python/Matlab/IDL are important because it is easier to quickly write correct code than in C++/Fortran.

Right, but if you say people "use" something, it's disingenous (for a scientific paper) to imply that implementation details don't matter.

Had I written the paper (I'm a scientist, I work with astro data sets at times, and manage Python wrappers for Fortran and C++ libraries) I would have calculated this based on instructions executed, not lines of user-facing code.

After all, if the code the astro people called was Pure Python, they wouldn't use python, as it would be too slow.

Reminds me of the 'made in X' fallacy.

  #!/usr/bin/env python
  from subprocess import Popen
  Popen("/usr/bin/some-fortran-binary")
  print("Once again python saves the day.")

Actually, many optimized BLAS/LAPACK implementations are not written in Fortran. Many are a mix of C and assembly exposed through the standard Fortran interface.

While I see what you're saying, I doubt you would claim to 'use' assembly when writing a C++ codebase - because (unless you're doing very low-level hand optimizations of the kind that get ever rarer), someone else has done the hard work of creating a compiler to do the translation for you. Same thing with NumPy et al, except one level higher up the abstraction stack.

Actually, that's precisely what I do, except it's called machine language, not assembly. That is because assembly is an intermediate format above machine language (it's symbolic).