Measuring API usage for popular numerical and scientific libraries
Developers of open source software often have a difficult time understanding how others utilize their libraries. Having better data of when and how functions are being used has many benefits. Some of these are:
- better API design
- determining whether or not a feature can be deprecated or removed.
- more instructive tutorials
- understanding the adoption of new features
Python Namespace Inspection
We wrote a general tool
python-api-inspect
to analyze any function/attribute call within a given set of
namespaces in a repository. This work was heavily inspired by a blog
post on inspecting method usage with
Google BigQuery
for pandas,
NumPy, and
SciPy. The previously mentioned work used
regular expressions to search for method usage. The primary issue with
this approach is that it cannot handle import numpy.random as rand;
rand.random(...)
unless additional regular expressions are
constructed for each case and will result in false
positives. Additionally,
BigQuery is not a free resource.
Thus, this approach is not general enough and does not scale well with
the number of libraries that we would like to inspect function and
attribute usage.
A more robust approach is to inspect the Python abstract syntax tree
(AST). Python comes with a performant method from the ast
module ast.parse(...)
for constructing a Python AST from source code. A node
visitor
is used to traverse the AST and record import
statements, and
function/attribute calls. This allows us to catch any absolute
namespace reference. The following are cases that
python-api-inspect
catches:
import numpy
import numpy as np
import numpy.random as rnd
from numpy import random as rand
numpy.array([1, 2, 3])
numpy.random.random((2, 3))
np.array([1, 2, 3])
rnd.random((2, 3))
rand.random((2, 3))
There are limitations to this approach since Python is a heavily duck-typed language. To understand this see the following two examples.
def foobar(array):
return array.transpose()
a = numpy.array(...)
a.transpose()
foobar(a)
How is one supposed to infer that a.transpose()
is a numpy
numpy.ndarray
method or foobar
is a function that takes a
numpy.ndarray
as input? These are open questions that would allow
for further inspection of how libraries use given functions and
attributes. It should be noted that dynamically typed languages in
general have this
problem. Now
that the internals of the tool have been discussed, the usage is quite
simple. The repository
Quansight-Labs/python-api-inspect
comes with two command line tools (Python scripts). The important tool
inspect_api.py
has heavy caching of downloaded repositories and
source files that have been analyzed. Inspecting a file the second
time is a sqlite3 lookup. Currently, this repository inspects 17
libraries/namespaces and around 10,000 repositories (100 GB
compressed). It has been designed to have no other dependencies than
the Python stdlib and easily run
from the command line. Below is the command that is run when
inspecting all the libraries that depend on numpy.
python inspect_api.py data/numpy-whitelist.ini \
--exclude-dirs test,tests,site-packages \
--extensions ipynb,py \
--output data/inspect.sqlite
The command comes with several options that can be useful for
filtering the results. --exclude-dirs
is used to exclude directories
from counts (e.g. tests
directory or site-packages
directory)
within a repository. This option reveals the use of a given namespace
in tests as opposed to within the library. --extensions
is by
default all Python files *.py
but can also include Jupyter notebooks
*.ipynb
showing us how users use a namespace in an interactive
context. Unsurprisingly this work found that many Jupyter notebooks in
repositories have syntax errors.
While not the focus of this post, an additional script is provided in
the repository dependant-packages.py
. This script is used to
populate the data/numpy-whitelist.ini
file with repositories that
depend on numpy. This would not be possible without the libraries.io
API. It is a remarkable project which
deserves more attention.
Results
The table below summarizes the findings of namespace usage within all
*.py
files, all *.py
in only test directories, all *.py
files
excluding ones within test directories (tests
, test
), and only
Jupyter notebook *.ipynb
files. All of the results are provided as
csv
files. It is important to note that the inspect_api.py
script
gets much more detail than is included in the csv
files and there is
plenty of additional work that could be done with this tool for
general Python ast analysis.
Library | Whitelist | Summary only `.py` | Summary only `.py` tests | Summary only `.py` without tests | Summary only `.ipynb` |
---|---|---|---|---|---|
astropy | ini | csv | csv | csv | csv |
dask | ini | csv | csv | csv | csv |
ipython | ini | csv | csv | csv | csv |
ipywidgets | ini | csv | csv | csv | csv |
matplotlib | ini | csv | csv | csv | csv |
numpy | ini | csv | csv | csv | csv |
pandas | ini | csv | csv | csv | csv |
pyarrow | ini | csv | csv | csv | csv |
pymapd | ini | csv | csv | csv | csv |
pymc3 | ini | csv | csv | csv | csv |
pytorch | ini | csv | csv | csv | csv |
requests | ini | csv | csv | csv | csv |
scikit-image | ini | csv | csv | csv | csv |
scikit-learn | ini | csv | csv | csv | csv |
scipy | ini | csv | csv | csv | csv |
statsmodels | ini | csv | csv | csv | csv |
sympy | ini | csv | csv | csv | csv |
tensorflow | ini | csv | csv | csv | csv |
Since many namespaces were checked we will highlight only some of the
results. First for NumPy the
unsurprising function calls: numpy.array
, numpy.zeros
,
numpy.asarray
, numpy.arange
, numpy.sqrt
, numpy.sum
, and
numpy.dot
. There are
plans
to deprecate numpy.matrix
and this seem possible since it
numpy.matrix
is not in the top 150 functions calls. Numpy testing functions were
the expected testing.assert_allclose
, testing.assert_almost_equal
,
and testing.assert_equal
.
SciPy acts as a glue for many algorithms
needed for scientific and numerical work. The usage of scipy
is
surprising and also possibly the most accurate results of the
following analysis. This is due to the fact that scipy
tends to be
function wrappers over lower level routines and less class instance
methods which are harder to detect as discussed above. The sparse
methods are heavily used along with several high level wrappers for
scipy.interpolate.interp1d
and scipy.optimize.minimize
. I was
surprised to find out one of my favorite SciPy methods,
scipy.signal.find_peaks
, is rarely used! Only a small fraction of the
scipy.signal
functions are used and these include:
scipy.signal.lfilter
, scipy.signal.fftconvolve
,
scipy.signal.convolve2d
, scipy.signal.lti
, and
scipy.signal.savgol_filter
.
scikit-learn is a popular library for data analysis and offers some of the traditional machine learning algorithms. Interestingly here we order the most used models.
sklearn.linear_model.LogisticRegression
sklearn.decomposition.PCA
sklearn.ensemble.RandomForestClassifier
sklearn.cluster.KMeans
sklearn.svm.SVC
pandas is another popular data analysis
library for tabular data that helped drive the popularity of
Python. One of the huge benefits of pandas
is that it allows reading
many file formats to a single in memory pandas.DataFrame
object. Unsurprisingly the most popular pandas
functions are
pandas.DataFrame
and pandas.Series
. Here we rank the most popular
pandas.read_*
functions.
pandas.read_csv
pandas.read_table
pandas.read_sql_query
pandas.read_json
pandas.read_pickle
requests makes working
with HTTP requests easier to work with than the stdlib
urllib.request
and is one of the most downloaded
packages. Looking at the
data for usage of requests
, three functions are primarily used
(everything else is used 3-5x less): requests.get
, requests.post
,
and requests.Session
with headers
being the most common argument.
Overall it is clear that libraries are being used differently within
either a package, tests, or notebooks. Notebooks tend to prefer high
level routines such as scipy.optimize.minimize
, numpy.linspace
,
matplotlib.pyplot.plot
which can be used for demos. Additionally
notebook function usage would be a good metric for material that is
worthwhile to include in introduction and quick-start
documentation. The same goes for testing and development documentation
that is equally informed as to what functions are used in tests and in
packages. Further work is necessary to generalize this tool as it
could be useful for the Python ecosystem to better understand through
analytics how the language is being used.
Comments