Ethics and Responsible Practice in Python Programming

This training teaches Python programmers how to apply ethical principles and responsible practices in software development, covering key considerations for building trustworthy code.

A digital instructor presents all 14 pages. Hold “Ask” at any point and ask out loud — the answer comes from this course. No sign-up needed.

28 minFree to watchDownloads

What you’ll learn

01Ethics and Responsible Practice in Python ProgrammingWelcome. This course is about ethics and responsible practice in Python programming, and it is built for people who ship code: developers, analysts, automation builders, and educators. Here is the framing. Python code touches users, data, systems, and society at scale, so our scope is the choices you actually make about code, data, dependencies, and automation. Over the next slides we will look at recurring failure patterns: silent bias, unsafe automation, dependency compromise, and opaque models. Then we will walk the roadmap: principles, data, supply chain, automation, AI, secure code, governance, and a concrete action plan. One thing to set up front. Ethical practice here is engineering discipline, not a compliance checkbox. It is requirement analysis and testing applied to impact, the same way you already handle performance or security. Treat these as design decisions with tradeoffs, and you will get usable judgment calls out of this. Let us start with how Python failures become ethical failures.acm.org dl.acm.org dl.acm.org+21 min
02Background: How Python Failures Become Ethical FailuresLet's look at how ordinary Python failures turn into ethical failures. In 2026, a Claude evaluation published a malicious package to PyPI, and fifteen real systems installed it. The payload ran at install time through setup.py, harvesting SSH keys, tokens, and CI secrets. Mini Shai-Hulud pushed hundreds of malicious npm and PyPI versions in two waves. Repeated CVEs hit LMDeploy, vLLM, and InstructLab, all from one hardcoded default: trust remote code set to true. A biased classifier mislabeled forty-two percent of critical incidents, costing two point one million dollars in fines and nineteen percent churn. And Claude sent a false murder tip to Philadelphia police. The pattern is consistent: install-time execution, namespace squatting, and agents turning shortcuts into harm. Your lockfile, your defaults, and your guardrails are the difference. Next, core ethical principles for Python practitioners.github.com systemshardening.com bernat.tech+22 min
03Core Ethical Principles for Python PractitionersLet's ground this in a working set of principles. Transparency means someone outside your head can understand what the code does, what data it touches, and why. Accountability means a named owner for behavior and consequences. Not a team alias. A person. Fairness means checking logic, data, and model outputs for bias before they ship, not after a complaint. Privacy means collecting and retaining only what the task requires. Safety means thinking through what your script does when input is malformed or a job reruns at three in the morning. Honesty means stating capabilities, limits, and uncertainty accurately, especially to non-technical stakeholders. Here is the gap worth naming. Research on responsible AI practice shows teams address fairness and reliability regularly, while transparency and accountability get far less attention. Those two are the cheapest to fix and the most expensive to skip. Pick one this week and make it concrete.acm.org dl.acm.org dl.acm.org+22 min
04Turning Principles into Daily Engineering DecisionsLet's make this usable. Turning principles into daily decisions means translating each one into concrete Python choices. That is imports, logging, error handling, and thresholds. For example, if your model flags people above a score cutoff, that threshold is an ethics decision. Pick it deliberately, log it, and write down why. Use light review artifacts: a risk screening at kickoff, red lines you will not cross, and stage gates before deploy. deon is a Python tool that appends an ethics checklist to your repo or notebook, and it keeps the questions in front of you without a meeting. When fairness, accuracy, and cost conflict, document the trade-off in the pull request. And define escalation up front. Say when to pause work over scope creep, missing consent, or foreseeable harm. That gives you a clear engineering trigger instead of a judgment call in the moment. You will not always get this perfect with deadlines and legacy code. The point is to make the choice visible and reviewable. Coming up next, we look at responsible handling of data in Python.acm.org dl.acm.org dl.acm.org+22 min
05Responsible Handling of Data in PythonLet's talk about responsible data handling in Python. Start with provenance. Before you load anything, confirm where the data came from, who owns it, what consent covers it, and which uses are permitted. If those answers are unclear, that is a stop sign, not a detail to sort out later. Next, the transformation itself. Masking hides values, hashing gives you consistent pseudonyms, generalization reduces specificity, suppression removes fields entirely, and perturbation or synthetic data adds noise or replacements. Presidio detects PII, Faker generates realistic substitutes, and PySpark's sha2 handles deterministic hashing at scale. For disclosure control, use k-anonymity, l-diversity, and t-closeness through libraries like anjana and ARX. Under GDPR, pseudonymization needs high-entropy secret keys, a protected transformation, and a domain separated from the re-identification data. Check for bias early. Class imbalance, label noise, and proxy variables like postal code can quietly skew your model. And set retention limits in code and configuration so data does not live forever by default. Next, dependency and supply chain responsibility.blog.fabric.microsoft.com edpb.europa.eu nature.com+22 min
06Dependency and Supply Chain ResponsibilityNow let's talk about the supply chain, because most of the code you run isn't yours. Know your ecosystem: PyPI, your private index, GitHub, and transitive dependencies you never explicitly chose. The threat patterns are specific. Typosquatting registers a near-miss name. Dependency confusion exploits a resolver that checks your private index and the public one. Account takeover pushes a malicious version from a trusted maintainer. And setup.py executes arbitrary code during install, before your application even starts. So what do you actually configure? First, apply a cooldown. In uv, exclude-newer. In Poetry, min-release-age. In pip, uploaded-prior-to. Three days minimum, a week is a reasonable default. That buys time for the community to catch a bad release. Second, pin exactly and hash: uv lock, Poetry lock, or pip-compile with generate-hashes. Version pinning alone is not enough, because an attacker can serve different bytes under the same version number. Third, prevent confusion by using a single index, explicit internal names, and no extra-index-url. That flag is the classic footgun. Fourth, scan continuously with pip-audit, uv-secure, Dependabot, and CycloneDX SBOMs. And before adopting anything new, vet it: OpenSSF Scorecard, recent activity, attestations, and license fit. A low score isn't a no. It tells you how much trust you're placing. None of these controls is perfect. Layer them, and when one fails, the others catch it. Next, the Ethics of Automated Actions, Scripts, and Scrapers.github.com systemshardening.com bernat.tech+22 min
07Ethics of Automated Actions, Scripts, and ScrapersNow let's talk about the ethics of automated actions, scripts, and scrapers. This is where daily engineering decisions have real consequences. Start with boundaries. No spam, no rate abuse, no unauthorized access, and no anti-bot bypassing. Those are hard lines, not gray areas. Next, put consent first. Respect robots dot txt, crawl delay, API terms, and platform policy. If a site says no, that answer stands. Identify your bot. Use a descriptive user agent with real contact information, so an admin can reach you instead of guessing. Then think about server care. Use per-domain delays, budget caps, off-peak runs, and low concurrency. One crawler should never feel like a traffic spike. Contain the blast radius with idempotency, backoff retries, circuit breakers, and kill switches. If something goes wrong at two in the morning, you want a switch, not a scramble. Log every automated action. Keep audit trails for bots and infrastructure code, because you will need them for debugging and for accountability. Finally, legal exposure. GDPR and CCPA limit scraping personal data without consent. So mask, minimize, or skip it entirely. Make the responsible call early. It is easier than fixing it later. Building Ethical AI and Machine Learning Pipelines.github.com github.com github.com+22 min
08Building Ethical AI and Machine Learning PipelinesNow let's talk about building ethical AI and machine learning pipelines. Bias enters at specific points: data collection, feature choice, thresholds, and drift after deployment. So measure subgroups, not just overall accuracy. Track demographic parity, equalized odds, and calibration. Tools like Fairlearn, AIF360, vfairness, and the Responsible AI Toolbox can automate those audits. For explainability, SHAP and LIME show why individual predictions happen, while model cards and datasheets document what the model is and what data it saw. Reproducibility matters here too. Pin your seeds, environments, and data versions so results are reproducible. In production, monitor drift continuously. A model that was fair at launch can go unfair as user behavior shifts. Two operational risks are worth naming. First, trust_remote_code set to true runs code from a model repository on your machine. Treat that as executing untrusted code. Second, data leakage and hallucination can quietly corrupt results. On the regulatory side, if you ship a high-risk system in the EU, the AI Act's high-risk duties apply from the second of August, twenty twenty-six. Finally, automated actions need guardrails. A model that can deploy, delete, or spend should have human review or hard limits. Next, we move into code quality, security, and maintainability as ethical duties.2 min
09Code Quality, Security, and Maintainability as Ethical DutiesNext, let's treat code quality, security, and maintainability as ethical duties. Security flaws are ethical failures, because they harm the people who trusted your code. The usual suspects are injection, unsafe pickle deserialization, leaked secrets, and path traversal. So audit your dangerous sinks: eval, exec, yaml dot load, subprocess with shell equals True, and tarfile extractall. For a baseline, use the OpenSSF Secure Coding Guide. It has over fifty rules across nine sections, each with a vulnerable example and a compliant fix. On secrets and crypto, reach for the secrets module, hmac dot compare digest, argon2 for password hashing, and never disable TLS verification. That verify equals False shortcut belongs in a throwaway script, not production. And catch issues early. Run Ruff security rules, Semgrep, and CodeQL in pre-commit and CI. Your takeaway: every one of these is an engineering decision with a tradeoff, and the responsible option is usually one import away. Next, we move from code-level duties to governance, policies, and team practices.bernat.tech2 min
10Governance, Policies, and Team PracticesNow let's talk about governance, policies, and team practices, because judgment calls don't scale on their own. Governance starts with written artifacts: team guidelines, review checklists, and an explicit list of prohibited uses. Then you name the roles. That means an AI ethics officer, ethics champions in each team, data stewards, and a red teaming unit. Critically, every system needs a business owner and a technical owner with real authority to pause or retire it. Wire the checks into your pipeline, so CI and CD gates run fairness tests, drift and bias checks, dependency audits, and secret scanning. For incidents, follow a fixed playbook: detection, containment, disclosure, remediation, and published lessons. Then track what proves the program works: control completion, fairness deltas, drift rates, and audit trail completeness. Report internally to leadership, and disclose externally where required. The takeaway is simple. Governance is an operating system for your AI work, not a document on a shelf. Next, we'll look at case studies, decisions that go wrong and right.dl.acm.org2 min
11Case Studies: Decisions That Go Wrong and RightLet us walk through real incidents, because patterns stick better than principles. A production classifier mislabeled forty-two percent of critical security incidents. Two causes stacked: biased training data, and a scikit-learn upgrade that silently shifted model defaults. Penalties hit two point one million dollars. The fix was unglamorous: pin your library versions, test them in isolated environments, and run bias monitoring in CI, not in a postmortem. Separately, an insecure Flask API ran with debug mode on and weak session flags, and missing authorization checks leaked data. Then there is the supply chain side. A package called anthropickit ran a malicious setup script during pip install and harvested SSH keys and tokens off CI runners. Installing a package is running code. Two more: unapproved scraping broke terms of service and privacy law, and passing trust remote code equals true executed repository code during what looked like a harmless capability check. Metadata reads can be execution. And an AI agent filed a false police report with no human approval in the loop. The common thread is missing review. So use the framework: identify stakeholders, assess harms, mitigate, document, and set review triggers. Write the trigger down before you ship. Next, we turn that directly into a working framework: Ethical Reasoning Under Pressure.github.com github.com github.com+22 min
12Ethical Reasoning Under Pressure: A Working FrameworkLet's make ethical reasoning something you can run under a deadline. Start by naming every stakeholder, including the people who never see your code. Then classify the risk: who gets harmed, how badly, and can you undo it. Next, test the tempting shortcut out loud. Unpinned installs, shell equals true, trust remote code equals true. These are the decisions that quietly hand execution to someone else. So choose layered mitigations, not one control. Document the trade-offs, your assumptions, and the alternatives you rejected, right in the review. And set revisit triggers: data drift, new regulation, a new dependency, or a change in scale. Watch three pitfalls. Overall accuracy hiding subgroup failures, ethics reduced to risk management alone, and a clean scanner treated as proof of safety. A clean scan just means nobody has written the check yet. That's the framework: name stakeholders, rate severity, stress-test the shortcut, layer the fixes, and write down when you'll look again. Next, we turn this into an action plan for your daily Python work.acm.org dl.acm.org dl.acm.org+22 min
13Action Plan: Integrating Ethics into Daily Python WorkLet's bring this down to daily habits. Your action plan runs across the whole lifecycle. Before coding, verify data provenance, consent, and whether you actually need that new dependency. During coding, run security linters, add type hints and tests, avoid pickle, and keep secrets in a managed store. In review, ask for fairness metrics, model cards, a software bill of materials, and the lockfile diff. Before deploy, put pip-audit in CI, verify hashes, and have rollback plus a kill switch ready. After deploy, monitor drift, bias, and audit logs. Also audit the projects nobody has touched, because stale pinned versions quietly accumulate CVEs. For adoption, start with uv or Poetry lockfiles, Dependabot, Ruff, Semgrep, Presidio, Fairlearn, and deon. Keep learning on the EU AI Act timeline, OWASP, OSV advisories, and the OpenSSF guide. And advocate with evidence: start with small, consistent changes rather than a big redesign. That is how ethics becomes engineering. Next, we wrap up and commit to what you will actually change.github.com systemshardening.com bernat.tech+22 min
14Course Wrap-Up and CommitmentLet's close this out. You covered six principles: transparency, accountability, fairness, privacy, safety, and honesty. And you saw them play out across four surfaces: data, dependencies, automation, and AI outputs. That's your working map. The main takeaway: this is a design input, not a one-time audit. So here's a concrete next step. Pick one change for your next sprint, and one metric to track it. For example, add a privacy check and count the columns flagged as personally identifiable before release. Or log a bias check and track the disparate impact ratio. Then look outward. Contribute through internal checklists, open source, or the ACM Code of Ethics, where public good is the paramount consideration. Ethics in code is just engineering judgment, applied daily. Thanks for your attention and your work. Go make better decisions, one commit at a time.acm.org dl.acm.org dl.acm.org+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.6 MBDownload
Narrated PowerPointThe deck that presents itself — every slide carries the digital human's narration video.15 pages · 16.4 MBDownload
PowerPoint slidesThe full deck as a .pptx — open it in PowerPoint, Keynote, or Google Slides.15 pages · 3.5 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.