Machine Learning with Python

This training teaches Python developers how to implement and evaluate core machine learning models using popular libraries. Learners will build practical skills in data preprocessing, model training, and performance assessment.

My workspace28 minFree to watchDownloads

What you’ll learn

01Python Machine LearningWelcome. If you're a Python developer looking to step into machine learning, you already have a serious head start. Python remains the central platform for AI and ML work, not because it's the fastest language, but because the ecosystem around it is unmatched. In 2026, that ecosystem has matured into four clear layers: data handling, classical machine learning, deep learning, and deployment. Throughout this course, we'll work through an end-to-end ML workflow, from raw data to a monitored production model. You'll learn how to build systems that actually ship, not just notebooks that run. The goal is to equip you to build and deploy production-grade machine learning systems using Python's modern stack. Let's dig in, starting with a look at the 2026 Python ML landscape.aijourn.com github.com uvik.net+21 min
02The 2026 Python ML LandscapeNow let’s zoom out and look at the machine learning landscape in 2026. Think of the Python ecosystem as four distinct layers: data handling, classical machine learning, deep learning, and deployment. Each layer has its own tools and its own job. Confusing them is where most technical debt gets born. A few structural shifts are worth your attention. Rust-powered tooling has quietly raised Python's performance ceiling. Tools like Polars and pydantic are built on it, giving you order-of-magnitude speedups without leaving Python. Scikit-learn remains the unchallenged standard for tabular and classical work. For structured data, a well-tuned gradient-boosting model often beats a neural network on cost, speed, and interpretability. With deep learning, PyTorch dominates research. And Hugging Face has become the gateway to over two million pretrained models, letting you fine-tune or run inference on bleeding-edge architectures with a few lines of code. The takeaway: match the layer to the problem, and you’ll ship faster. Next, we’ll examine the core data libraries that anchor the entire stack.aijourn.com github.com uvik.net+21 min
03Core Libraries: NumPy, pandas, and PolarsLet’s talk about the three libraries you’ll actually reach for daily. NumPy is the foundation; it gives you n-dimensional array objects and vectorized math that runs in C. Every serious numerical library in Python builds on it. If you’ve done any data work, you know pandas as the standard way to wrangle tabular data. It is still the default in a lot of pipelines, and honestly, it’s a reasonable one for datasets that fit into memory. The newer player is Polars. It’s built in Rust with a multi-threaded engine, and it runs common workloads five to twenty times faster than pandas on large data. It also lazy-evaluates queries, which can make your code both faster and more readable. A big reason to care about both pandas and Polars is that their DataFrames feed directly into scikit-learn and PyTorch. That means you start with familiar code and you go all the way to model training without any magic wrappers. One more thing worth noting: somewhere between a quarter and a third of new native packages on PyPI are now started in Rust rather than C. That trend is pushing the performance ceiling of Python up without you rewriting your logic. Which brings us to scikit-learn, the workhorse for classical machine learning. That’s next.aijourn.com github.com uvik.net+21 min
04Scikit-learn: The Classical ML WorkhorseNow let's talk about the workhorse of classical machine learning in Python: scikit-learn. It has a consistent fit, predict, and transform API, which means once you learn one model, you can apply that same mental model to dozens of others. It handles classification, regression, clustering, and preprocessing with equal ease. But the real strength is how it handles real-world workflows. Pipelines and ColumnTransformer let you chain preprocessing and modeling into a single, robust object. That is critical, because it prevents data leakage. Here's the classic trap: if you fit a scaler on your full dataset before splitting into training and test sets, information from the test set leaks into your model and inflates your performance estimates. Using a pipeline ensures every transformation is fitted only on the training fold in each cross-validation split. This keeps your results honest and reproducible. And one more point worth stressing: for many business problems involving tabular data, scikit-learn beats deep learning approaches on cost, speed, and interpretability. Model pipelines with XGBoost or LightGBM often outperform neural networks on structured data. That's not a controversial statement in 2026. A well-tuned scikit-learn pipeline is still one of the most reliable tools you can have on hand. Now, when your problem calls for unstructured data like images or text at scale, that is when the deep learning frameworks take over. Let's look at those next.aijourn.com github.com uvik.net+22 min
05Deep Learning: PyTorch, TensorFlow, and KerasNow let's talk about the deep learning frameworks you'll actually encounter in the wild. PyTorch has become the default for research and custom architectures. Most cutting-edge papers and open-source implementations use it, especially for anything involving Hugging Face models. On the other side, TensorFlow with Keras remains strong in production deployment, mobile, and edge environments. Its serving infrastructure is mature and battle-tested. What's interesting is Keras three point zero. It lets you write your model once and run it on a PyTorch, TensorFlow, or JAX backend. That flexibility removes the fear of locking your team into one framework. Here's the practical takeaway: don't pick a framework based on hype. Match it to your task. Research or novel model design? PyTorch. Large-scale serving or edge deployment? TensorFlow. Team already knows one well? That's often the best reason to stick with it. The gap between frameworks is narrowing every year, so your team's expertise matters more than minor technical differences. Understanding the strengths of each will help you choose wisely. Next, we'll look at defining success before you start modeling.aijourn.com github.com uvik.net+22 min
06Defining Success Before ModelingNow let’s talk about defining success before you write any modeling code — and I mean before. The metrics you choose are how you’ll judge every experiment from here on, so they need to align directly with your business goals. For classification, that usually means precision, recall, and the F1 score; for regression, mean absolute error or root mean squared error. Accuracy alone is a poor compass. It doesn’t reflect the real cost of a wrong answer, especially when your classes are imbalanced or when false positives and false negatives carry different consequences. Choose metrics that mirror the actual trade-offs your project faces. Start with a baseline — a simple heuristic or a trivial model — because that sets the minimum viable performance bar. If your fancy model can’t beat the baseline, you haven’t built value. One more critical point: be suspicious of optimism in your metric selection. Data leakage — where information from the test set sneaks into training — produces overly optimistic scores that collapse in production. The general rule is that test data should never influence training. Use pipelines so your preprocessing, feature selection, and scaling all fit only on the training data. Winning on a leaked metric isn’t winning in the real world. With your success metrics locked in, the next step is building a validation strategy that doesn’t leak. Let’s move to splitting data without leakage.scikit-learn.org sklearn.org dataschool.io+22 min
07Splitting Data Without LeakageNow let’s talk about splitting data without leakage. This is where many models quietly go wrong. Data leakage happens when information from the test set reaches the model during training. The result is an overly optimistic performance estimate that falls apart in production. The golden rule is simple: never fit on test data. Split your data before any preprocessing. Fit your scalers and transformers only on the training set, then apply the same transform to both. For example, when normalizing, the mean and standard deviation must come from the training split alone. If you include test data in that calculation, you are peeking into the future. For time series, use TimeSeriesSplit to prevent lookahead bias. And when you have imbalanced classes or grouped observations, use stratified or group-based splits to keep those structures intact. A practical habit: use scikit-learn Pipelines inside cross-validation, because they enforce the correct fit and transform sequence automatically. Up next, we’ll see how pipelines make preprocessing and modeling reproducible from start to finish.scikit-learn.org sklearn.org dataschool.io+21 min
08Pipelines: Reproducible Preprocessing and ModelingNow let’s talk about pipelines, because they’re the backbone of reproducible preprocessing and honest model evaluation. The core problem we’re solving is data leakage: when information from the test set sneaks into training, your accuracy looks great in the lab but collapses in production. A pipeline prevents this by ensuring that every fit happens only on the training data and every transform is applied correctly to both sets. In practice, you’ll often use a ColumnTransformer inside that pipeline to apply different preprocessing to different columns: one-hot encoding for categoricals, scaling for numerics, all in a single atomic unit. Another practical tip: if you pass a memory parameter to your pipeline, fitted transformers are cached. That saves serious compute when you run grid search tuning, because the same preprocessing steps don’t need to be recomputed for every parameter combination. When you need to inspect what happened, steps are accessible through named_steps, which keeps debugging and reuse straightforward. The key takeaway is this: when you combine pipelines with cross-validation, you get an honest estimate of how the model will behave on truly new data. Keep the whole workflow inside the pipeline, and your evaluation procedure becomes a reliable simulation of reality. Now, let’s shift to cross-validation and model selection to see how this plays out in practice.scikit-learn.org sklearn.org dataschool.io+22 min
09Cross-Validation and Model SelectionNow let’s talk about cross-validation and model selection. The core idea is simple: train on part of your data, test on the rest, and repeat. K-fold cross-validation splits your data into several folds, trains on all but one, and evaluates on the held-out fold. You average the scores across folds to get a more reliable estimate of performance than a single train-test split would give you. But here is where it gets tricky. If you apply preprocessing like scaling or imputation before splitting, you risk leaking information from the test set into your training procedure. That gives you overly optimistic scores that won’t hold up in production. The fix is to wrap your preprocessing and model in a scikit-learn Pipeline. When you pass that pipeline to cross_val_score, it guarantees each fit only sees the training fold, and the transform is applied consistently. For hyperparameter tuning, nested cross-validation is the honest approach. The inner loop picks parameters, the outer loop evaluates generalization. And don’t forget your data structure. Use KFold for independent samples, GroupKFold when samples belong to the same group or subject, and TimeSeriesSplit for chronological data. Split first, transform after, and your evaluation will reflect reality. Next, we’ll look at hyperparameter tuning with grid and random search.scikit-learn.org sklearn.org dataschool.io+22 min
10Hyperparameter Tuning with Grid and Random SearchNow let's talk about tuning. Once your pipeline is solid, the next step is finding the best hyperparameters. GridSearchCV evaluates every combination in a grid you define. That's thorough, but it gets expensive fast. If your search space is large, switch to RandomizedSearchCV, which samples candidates randomly and covers broad ranges much more efficiently. Here's a key detail: when you tune inside a pipeline, parameters are referenced with a double underscore, like classifier__C. This lets you tune preprocessing and model parameters together. Why does that matter? Because your preprocessing choices and model hyperparameters interact, and tuning them separately can lead to suboptimal results. More importantly, pipelines prevent data leakage during cross-validation. If you scale or select features before splitting, the test fold's statistics influence your training data, and your performance scores become overly optimistic. The pipeline keeps your transforms fit only on training folds. And if you want something smarter than random search, consider tools like Optuna, which uses Bayesian optimization to search more intelligently. Next, we'll look at how to evaluate your model beyond just accuracy.scikit-learn.org sklearn.org dataschool.io+22 min
11Evaluation Beyond AccuracyNow let's talk about why accuracy alone can lead you astray. In imbalanced datasets, accuracy can look impressive while the model fails at its actual job. Instead of leaning on a single number, you want a fuller diagnostic picture. For classification, precision and recall tell you where the errors are. F1 gives you a balanced summary, and ROC-AUC shows how well the model separates classes across thresholds. For regression, MAE tells you the average error in original units, MSE penalizes larger mistakes, RMSE brings that back to interpretable scale, and R-squared shows how much variance your model explains. Diagnostics matter just as much as metrics. A confusion matrix reveals which classes get confused. Learning curves show whether your model is overfitting. And remember, metrics only tell the truth if your evaluation procedure is honest. That means no data leakage, proper splitting, and using a pipeline. So the takeaway here is simple: choose metrics that match your business problem, and dig into diagnostics to understand your model's weaknesses. Now let's look at how to save, share, and version your trained models.scikit-learn.org sklearn.org dataschool.io+22 min
12Serializing and Versioning ModelsNow let’s talk about saving your work so it survives beyond the notebook. The first rule of serialization: save the entire pipeline, not just the model object. If you trained with a scaler or an encoder, it has to travel with the model, or your predictions will be silently wrong. For scikit-learn pipelines, joblib is the standard choice because it handles large numpy arrays efficiently. For PyTorch, you will use torch.save. Whichever format you pick, do not stop at the model file. Embed sidecar metadata: training date, evaluation metrics, and the exact order of input features. Six months from now, you will need to know which dataset produced that model and why its accuracy was what it was. A JSON sidecar answers those questions. As your project grows, graduate to a model registry like MLflow, which tracks versions, metrics, and artifacts in one place and gives you rollback at the click of a button. One hard warning before we move on: never load serialized model files from untrusted sources. Both pickle and joblib can execute arbitrary code during deserialization. Treat a model file like an executable, not data. With that foundation, let’s see how to put that model behind a real API using FastAPI.machinelearningmastery.com kargin-utkin.com mgrowtech.com+21 min
13Serving Models with FastAPINow let’s talk about serving your model with FastAPI. The core idea is simple: load the model once when the application starts, not on every request. Reading a joblib file from disk and deserializing it can take seconds, while a single prediction takes milliseconds. If you load inside the predict function, you make your API hundreds of times slower than it needs to be. Load once, predict many times. FastAPI also gives you automatic validation through Pydantic. Define a request schema with typed fields, and if a client sends a string where you expect a float, FastAPI returns a clear 422 error before your code ever runs. That turns potential crashes into clean, structured feedback. For deployment, Docker gives you reproducibility—same image, same behavior—whether you are running locally or in the cloud. On the infrastructure side, you have solid patterns to choose from. Cloud Run scales from zero, but watch cold starts with larger models. Kubernetes gives you rolling updates with zero downtime. Serverless works well for bursty or low-traffic workloads if you can tolerate the spin-up time. Whichever path you take, the pattern stays the same: serialize your full pipeline with joblib, load it once at startup, validate every request, and keep your model serving logic separate from your deployment concerns. Next, we’ll look at monitoring and maintaining production models.machinelearningmastery.com kargin-utkin.com mgrowtech.com+21 min
14Monitoring and Maintaining Production ModelsWe've covered how to build and deploy a model, but the work doesn't end at deployment. Once your model is live, you need to watch it closely. Two things can go wrong: data drift, where the incoming data shifts from what you trained on, and concept drift, where the relationship between features and outcomes actually changes. Both can silently degrade your model's performance. So, set up monitoring. Log every prediction and input. Track latency and error rates with a tool like Prometheus. Use health checks to ensure your service is alive, and plan for rolling deployments to update without downtime. Establish baseline metrics when you first deploy, so you have something to compare against. When drift is detected, retrain on fresh data and roll out the new model carefully. This is how you keep your model reliable, not just for today but for the long run. Thanks for sticking with this course. You now have the full picture, from training to serving to maintaining. Go build something that lasts.machinelearningmastery.com kargin-utkin.com mgrowtech.com+22 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

PDF handoutEvery slide page, ready to print or share.15 pages · 3.8 MBDownload
Narrated PowerPointThe deck that presents itself — every slide carries the digital human's narration video.15 pages · 15.8 MBDownload
PowerPoint slidesThe full deck as a .pptx — open it in PowerPoint, Keynote, or Google Slides.15 pages · 3.7 MBDownload

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.