At RUG, the standard data science curriculum ran on Stata, R, and SPSS. These tools have decades of academic inertia behind them, not necessarily because they are better, but because professors mastered them before Python became a serious data science platform and have not had time to switch. As a result, students graduate knowing tools that industry has largely moved beyond, while Python's better-maintained, faster, free, and more capable ecosystem goes untaught. Professors and other departmental staff have too much on their hands for a full curriculum redesign.

DataSafari started as a direct response to that gap. The hypothesis was simple: bring Python's best statistical and ML libraries together under a single interface that requires no configuration and produces plain-English output. That removes the adoption barrier for the person who most needs it: a researcher who knows their field, understands what a normality test is, but doesn't want to spend two hours reading scipy.stats documentation to run one. One import, one function call, and one readable report.

The iPhone analogy is imperfect but directionally useful. R is like Android: powerful, flexible, and beloved by people willing to configure it. DataSafari aims to provide an iOS-like layer on top of Python's underlying ecosystem.

That philosophy drove every product decision. It's why method='all' is the default rather than a required argument. It's why output is printed in plain English with interpretive tips instead of being returned as a raw matrix. It's why the function names are verbs such as explore, transform, evaluate, and predict. They describe what the user wants to do, not what the statistics are called. The target user was never a Python expert. It was someone who needed to do real data science work without letting the tooling become the hardest part of the day.

The hardest design constraint in DataSafari was self-imposed: a user should be able to call any function with just a DataFrame and a column list and get something genuinely useful back. No configuration, statistical expertise, or output parsing should be required. The library decides the rest.

Making that work means every function carries a significant amount of internal decision-making that the user never sees. explore_num() takes a single method parameter that defaults to 'all' — which means it runs correlation analysis, distribution analysis, three separate outlier detection algorithms (Z-score, IQR, and Mahalanobis distance), and a multicollinearity check in one call. The user passed two arguments. The library ran seven analyses and printed a structured plain-English report. That ratio — minimal input to maximal output — is the whole product.

But the API was also designed not to limit experts. Every function offers a full set of parameters for users who want to go deeper: method='outliers_iqr' to isolate a single analysis, output='return' to get structured DataFrames instead of printed text, and threshold_z=2 to tighten the Z-score cutoff for a stricter definition of an outlier. The one-liner is the entry point; the parameters are the escape hatches. Designing that layered experience, where simple stays simple and complexity remains possible, required thinking through every plausible user intent before writing a single line of logic, then ensuring the implementation served them all without conflict.

A Python traceback is the last thing a researcher wants to see at 11pm before a deadline. Every public function in DataSafari raises structured, specific errors before it does any computation — and the error messages are written for the person calling the function, not for the developer who wrote it.

The error handling layer sits entirely above the statistical logic. Before explore_num() touches a single column, it checks: is df actually a DataFrame? Is numerical_variables a list? Are the strings in that list real column names that exist in df? Are those columns actually numerical? Is the list non-empty? Is the DataFrame non-empty? Is method one of the seven valid options? Is output one of the two valid options? Is threshold_z a number? That's nine distinct failure modes caught and surfaced with a clear message and a correct-usage example — before a single line of analysis runs. Every one of those checks exists because someone, at some point during development and testing, made exactly that mistake.

The discipline behind this is that a library function has no UI. The error message is the UI. If a user passes a string where a list is expected and gets back TypeError: 'str' object is not iterable, that's a failed product moment — they have to reverse-engineer what went wrong from a generic Python exception. If they get back "explore_num(): The numerical_variables parameter must be a list of variable names. Example: var_list = ['var1', 'var2', 'var3']", they fix it in ten seconds and move on. That difference is entirely a writing problem, not a coding one, and it took as much time to get right as the statistical methods themselves.

The data science code, including the statistical methods, ML pipeline, and EDA logic, represents perhaps 20% of what it took to ship DataSafari. The other 80% consists of infrastructure decisions that tutorials rarely cover and that took weeks of research to get right.

The production configuration alone spans a dozen files beyond the package source itself:

• pyproject.toml: unified build, dependency, and tool configuration via Poetry and Setuptools
• bumpversion.cfg: automated semantic versioning with bump2version, wired to the CI pipeline to auto-increment on tagged releases
• tox.ini: multi-environment test runner across Python 3.9 to 3.12, so no version-specific regression ships undetected
• setup.cfg and MANIFEST.in: package inclusion rules to control exactly what ends up in the wheel and sdist
• pyproject.toml: Bandit config block, with the static security scan tuned to ignore specific false-positive patterns in the codebase
• LICENSE: GPL-3.0, chosen deliberately: use it freely, but derivatives stay open
• Sphinx's conf.py: the full documentation build configuration, including the Napoleon extension for Google-style docstrings, the Furo theme, and cross-reference resolution

Every one of those files required learning a tool I hadn't used before, reading its documentation, making it work with the others, and then making the entire stack reproducible in GitHub Actions. The CI pipeline didn't run cleanly on the first push or even the tenth. Over the development lifecycle, 136 issues were filed and closed, most of them documenting this kind of integration friction and its solution.

Documentation was another substantial layer of the work, especially the documentation users encounter inside the library: the docstrings. Every public function in DataSafari has a complete docstring with typed parameters, return types, raised exceptions, and a working code example that produces real output. More than 20 functions, including non-public ones, are documented to the point that help(ds.explore_num) gives a new user everything needed to use the function correctly without opening a browser. Writing that documentation took longer than writing some of the functions themselves.