A Mortgage lawyer had dream to work full time in technology and policy,
The journey started long ago with a new mum reading "Intellectual Property and Open Source: A Practical Guide to Protecting Code" by Van Lindberg, to her keep entertained during breastfeeding sessions.Then from meaning of library changing from being a room full of books to the screen full of gibberish code, from rebooting PyLadies Pune in Red Hat Pune office to working in Red Hat for the last 3 years. All of these seemed to pretty unreal at times.

And now I am starting my journey at the Red Hat OSAIPO team as the "Security Community and Compliance Architect". This will give me opportunity to to work with the intersection of law, technology, policy and community. The people I look up to, I admire, I will get a chance to work as my teammates. I so looking forward to the opportunity.

My journey till date has been a maneuver to hold on to the dream. The quote "Dreams are real, so chase them" sums up my journey to it&aposs core.

02 Jul 2026 8:16pm GMT

As EuroPython 2026 approaches and we prepare for another exciting edition, we'd like to thank our community and sponsors for their continued support.

We're also pleased to share some fantastic job opportunities from our sponsors. Take a look and perhaps you'll discover your next role.

ActiveCampaign

Software Engineer, Agent Development

About ActiveCampaign

ActiveCampaign is the autonomous marketing platform for people at the heart of the action. It empowers teams to automate their campaigns with AI agents that imagine, activate, and validate-freeing them from step-by-step workflows and unlocking limitless ways to orchestrate their marketing.

With AI, goal-based automation, and 1,000+ app integrations, agencies, marketers, and owners can build cross-channel campaigns in minutes-fine-tuned with billions of data points to drive real results for their unique business.

ActiveCampaign is the trusted choice to help businesses unlock a new world of boundless opportunities-where ideas become impact and potential turns into real results.

As a global multicultural company, we are proud of our inclusive culture which embraces diverse voices, backgrounds, and perspectives. We don't just celebrate our differences, we believe our diversity is what empowers our innovation and success. You can find out more about our DEI initiatives here.

About the job

ActiveCampaign is seeking a Software Engineer to join our Kraków Hub and build production-ready AI agents for autonomous marketing. Our platform empowers businesses to automate their customer engagement - and we are now extending that with intelligent, agentic workflows that can reason, act, and adapt on behalf of our customers. Our first wave of agents is already in production. This role will drive the expansion, building the next generation of autonomous experiences across the full breadth of the platform.

You &aposll work at the intersection of solid software engineering and applied AI - designing, building, evaluating, and operating agents that run at scale in a production marketing automation platform. This means engineering rigor comes first: agents need to be reliable, observable, performant, and safe before they are clever.Our Kraków Hub houses multiple engineering teams - Forms, Integrations, Ecommerce, Agency, CRM, Mobile, CampaignsUI, and Content - working across different product pillars with a shared focus on building agentic workflows into all core functionalities across the platform. You will collaborate closely with these teams, understanding their domains and building agents that integrate seamlessly into the broader system,This is not a pure research or ML role. We need engineers who can build - end to end - from prompt design through backend orchestration to frontend integration, and who can ship, measure, and iterate fast. Our environment moves quickly - we value high ownership, tight feedback loops, and close cross-functional collaboration. If you thrive in a hands-on, high-pace setting where you build, ship, and iterate rapidly, this role is for you.

What Your Day Could Consist Of

• Designing and building production-grade AI agents and autonomous marketing workflows across the ActiveCampaign platform
• Implementing multi-step agentic flows involving LLM orchestration, tool use, and integration with platform services
• Working with LLM APIs (prompt engineering, response handling, evaluation) and building reliable, testable agent pipelines
• Designing and running agent evaluations - building eval frameworks, defining quality metrics, and continuously measuring agent accuracy, reliability, and performance in production at scale
• Monitoring and optimizing agent performance - latency, cost, token usage, error rates - and iterating rapidly based on production dataIterating on agent behavior based on user feedback, observability data, and quality metrics
• Leveraging AI-assisted development tools and practices in your daily workflow - you don&apost just build AI features, you build with AI
• Writing production-quality code in Python for agent services and backend orchestration
• Contributing to PHP backend and frontend (React/Ember) integration points where agents interact with the core platform
• Building and maintaining APIs, data flows, and service interfaces that agents depend on
• Working iteratively - shipping code fast, learning from production, and improving continuously
• Ensuring code quality through testing, code review, and adherence to engineering standards
• Participating in on-call rotation for incidents related to agent services
• Working closely with Product, Design, and domain engineering teams to define agent capabilities and user experiences
• Engaging in pairing and code reviews across teams
• Contributing to documentation of agent architectures, patterns, and best practices
• Maintaining regular overlap with US-based teams (Chicago timezone) to ensure alignment and tight collaboration across the organization

What We&aposre Looking For

• 2-4 years of experience in a software engineering role
• Hands-on experience building and running AI agents or agentic workflows in a production environment - not just prototypes or side projects
• Experience with agent evaluation and performance optimization - you know how to measure whether an agent is working well and how to make it better
• Solid backend development skills in Python; working familiarity with PHP is a plus
• Understanding of how to build reliable, testable, and observable systems
• Active practitioner of AI-driven development - you use AI coding assistants and agentic development tools as part of how you work, not just what you build
• Ability to work iteratively and ship code fast - you&aposre comfortable with rapid release cycles and learning from production
• Familiarity with DB technologies: MySQL, DynamoDB, Redis
• Strong problem-solving skills and ability to work across multiple codebases and technologies
• Fluent in English (B2 minimum)
• Willingness to work flexible hours with regular afternoon availability to overlap with US Central timezone
• Experience with agentic AI frameworks or multi-agent orchestration patterns
• Familiarity with Model Context Protocol (MCP) or tool-use patterns for LLM agents
• Experience building eval pipelines or quality measurement systems for LLM-based features
• Frontend experience with React or EmberFamiliarity with AWS, CI/CD practices, and observability tooling
• Understanding of prompt engineering, evaluation methodologies, or LLM fine-tuningExperience in SaaS, marketing automation, or CRM domain

What We Offer

• A front-row seat in ActiveCampaign&aposs AI-first transformation - you&aposll build the autonomous marketing agents customers interact with
• Collaboration with experienced engineers across the Kraków Hub, including senior and staff-level technical leadership
• An environment that values ownership, fast iteration, and learning by doing
• Active investment in AI-first engineering practices and tooling
• Hybrid work model from our Kraków office with flexibility to adjust working hours for collaboration with US-based teams (Chicago timezone overlap)

This is an exciting time to join ActiveCampaign as we build out our new office in Poland. You will be a large part of developing our office culture in this new Krakow hub location.

Perks And Benefits

At ActiveCampaign, we prioritize employees' well-being and professional growth by cultivating a culture centered on collaboration and innovation. When you join our team, you'll not only have the opportunity to make a significant impact, but also enjoy a range of benefits tailored to support your personal and career development.

Here Are Some Of The Benefits We Offer

• Comprehensive Health & Wellness: Top-tier benefits package that includes medical and dental benefits paid 100% by ActiveCampaign for you and 50% for your dependents, and reimbursements on vision expenses. In addition, employees receive complimentary access to telehealth services, and a free subscription to Calm.
• Growth & Development: Access to LinkedIn Learning, professional development programs, and career growth opportunities in a fast-growing organization.
• Generous Paid Time Off: Recharge and take the time you need to maintain work-life balance.
• Total Rewards: Pension scheme with matching up to 1.5% of your contribution, MultiSport Plus card to support your active lifestyle, home office stipend to cover your commuter or work from home expenses, and a four-week paid sabbatical with bonus after five years.
• Collaborative Culture: Work alongside brilliant, passionate colleagues in an environment that values innovation, teamwork, and mutual support.

ActiveCampaign is an equal opportunity employer. We recruit, hire, pay, grow, and promote no matter of gender, race, ethnicity, sexual orientation, marital status, political opinion, national origin, social origin, parentage, workers union membership, economic status, religion, age, health condition, disability or any other grounds protected by law.

Our Employee Resource Groups (ERGs) strive to foster a diverse inclusive environment by supporting each other, building a strong sense of belonging, and creating opportunities for mentorship and professional growth for their members.

We may use artificial intelligence (AI) tools to support parts of the hiring process, such as reviewing applications, analyzing resumes, or assessing responses and identifying potential inconsistencies or verification signals in application materials based on available information. These tools assist our recruitment team but do not replace human judgment. Final hiring decisions are ultimately made by humans. If you would like more information about how your data is processed, please contact us.

Compensation details listed in this posting reflect the base rate only and do not include bonus, equity, sales incentives or other role specific compensation that the role may be eligible for. ActiveCampaign believes in and is committed to equitable compensation practices. The salary range provided above is a good faith estimate of the pay range determined by the location associated with the job posting. The actual salary depends on a candidate's skills, experience, and work location.

Job site: https://www.activecampaign.com/careers/software-engineer-agent-development_3e093aec-8540-49c7-93f1-719727c1191d

Apply here: https://jobs.lever.co/activecampaign/3e093aec-8540-49c7-93f1-719727c1191d/apply

Apify

Software Engineer for Fraud Prevention (TypeScript)

About Apify:

Apify is the largest marketplace of tools for AI. 40,000 Actors helping people and agents get real-time web data, track competitors, generate leads, or integrate their apps. Actors are built by a global creator community that now earns more than $1M every month.

Software Engineer for Fraud Prevention (TypeScript)

Job description:

As our Fraud Engineer, you will design and build systems to stop bad actors in real time. You&aposll investigate new attack patterns, deploy quick fixes, and create internal tools to handle incidents. It&aposs a hands-on role where you will work with security and product teams to keep our AI platform safe without slowing down legitimate users.

How to apply: https://jobs.ashbyhq.com/apify/7c93886a-9f1d-4ed9-ba71-d753c8f34c82?utm_source=career_page_apify

BCG X

Forward Deployed AI Engineer

Who We Are

Boston Consulting Group partners with leaders in business and society to tackle their most important challenges and capture their greatest opportunities. BCG was the pioneer in business strategy when it was founded in 1963. Today, we help clients with total transformation-inspiring complex change, enabling organizations to grow, building competitive advantage, and driving bottom-line impact.

To succeed, organizations must blend digital and human capabilities. Our diverse, global teams bring deep industry and functional expertise and a range of perspectives to spark change. BCG delivers solutions through leading-edge management consulting along with technology and design, corporate and digital ventures-and business purpose. We work in a uniquely collaborative model across the firm and throughout all levels of the client organization, generating results that allow our clients to thrive.

We Are BCG X

We&aposre a diverse team of more than 3,000 tech experts united by a drive to make a difference. Working across industries and disciplines, we combine our experience and expertise to tackle the biggest challenges faced by society today. We go beyond what was once thought possible, creating new and innovative solutions to the world&aposs most complex problems. Leveraging BCG&aposs global network and partnerships with leading organizations, BCG X provides a stable ecosystem for talent to build game-changing businesses, products, and services from the ground up, all while growing their career. Together, we strive to create solutions that will positively impact the lives of millions.

What You&aposll Do

Our BCG X teams own the full analytics value-chain end to end: framing new business challenges, designing innovative algorithms, implementing, and deploying scalable solutions, and enabling colleagues and clients to fully embrace AI. Our product offerings span from fully custom-builds to industry specific leading edge AI software solutions.

Our Forward Deployed AI Engineer and Senior Forward Deployed AI Engineer are part of our rapidly growing engineering team and help to build the next generation of AI solutions. You&aposll have the chance to partner with clients in a variety of BCG regions and industries, and on key topics like climate change, enabling them to design, build, and deploy new and innovative solutions. Additional responsibilities will include developing and delivering thought leadership in scientific communities and papers as well as leading conferences on behalf of BCG X.

We are looking for dedicated individuals with a passion for software development, large-scale data analytics and redefining organizations into AI led innovative companies. Successful candidates possess the following:

• Apply software development practices and standards to develop robust and maintainable software
• Actively involved in every part of the software development process
• Experienced at guiding non-technical teams and consultants in best practices for robust software development
• Optimize and enhance computational efficiency of algorithms and software design
• Motivated by a fast-paced, service-oriented environment and interacting directly with clients on new features for future product releases
• Enjoy collaborating in teams to share software design and solution ideas
• A natural problem-solver and intellectually curious across a breadth of industries and topics
• Fluency in both Italian and English

What You&aposll Bring

Requirements:

• Master&aposs or PhD degree program in Computer Science, Data Science, Statistics, Operations Research, or related field

Technologies

• Programming: Python, Java/Scala
• Frameworks/Libraries: TensorFlow, PyTorch, Scikit-learn, Keras
• Data Processing: NumPy, Pandas, Apache Spark, Dask
• Cloud Platforms: AWS (SageMaker, EC2), GCP (AI Platform), Azure (ML Studio)
• DevOps: Docker, Kubernetes, Terraform, Jenkins
• Data Visualization: Matplotlib, Seaborn, Plotly/Dash, Tableau
• Tools: Jupyter Notebooks, Google Colab, Git (GitHub/GitLab), MLflow, TensorBoard
• Deployment: Flask, FastAPI, TensorFlow Serving, Streamlit

Apply: https://careers.bcg.com/global/en/job/55983/Forward-Deployed-AI-Engineer-Italy-BCG-X

Bloomberg

Senior Software Engineer - AI App Enablement & Observability

📍Location: Dublin

Description & Requirements

Platform Engineering builds the core platforms, tooling, and paved roads that Bloomberg engineers rely on to ship reliable, secure, and high-performing systems at scale.The AI App Enablement & Observability team accelerates how AI products are built across Bloomberg Industry Group. Our mission is to make AI systems reliable, performant, cost-efficient, and continuously improving through platform tooling, deep observability, and automated feedback loops.We build developer-facing platforms and workflows that enable teams to experiment, deploy, and operate AI and agent-based systems with confidence. This includes LLM gateways, agent platforms, benchmarking systems, telemetry pipelines, and self-improving infrastructure that closes the loop between observability and action. We emphasise strong developer experience, intuitive APIs/SDKs, and end-to-end ownership.

What's in it for you?

You will help define how Bloomberg Industry Group builds and operates AI systems at scale by working on platforms that:

• Accelerate AI product development through reusable tooling and paved roads
• Provide end-to-end observability across AI systems (models, agents, pipelines, applications)
• Enable self-improving systems through telemetry-driven feedback loops
• Optimise cost, performance, and reliability of AI workloads
• Support both production AI systems and internal engineering agents

You'll collaborate across AI product, infrastructure, and platform teams to deliver foundational systems.

We'll trust you to:Platform & Enablement

• Build and evolve AI platform tooling (e.g., developer workflows, benchmarking systems)
• Design developer-friendly APIs, SDKs, and interfaces
• Contribute to systems across the Model Development Lifecycle (experimentation, deployment, evaluation)

Observability & Telemetry

• Build and operate observability platforms and telemetry pipelines (logs, metrics, traces, events)
• Provide visibility into latency, token usage, cost, quality, drift, and reliability
• Define instrumentation standards, schemas, and conventions
• Implement distributed tracing using modern approaches (e.g., OpenTelemetry)

AI System Insights & Debugging

• Enable end-to-end debugging of AI and agent workflows (model calls, tool usage, retrieval, orchestration)
• Build benchmarking, regression detection, and performance analysis capabilities
• Support observability for both production systems and internal engineering agents

Closed-loop Optimization & Automation

• Develop systems that turn telemetry into action (automated experimentation, regression detection, alerting)
• Build feedback loops that continuously improve model quality and system behavior
• Enable self-healing and self-optimising workflows

Cost, Performance & Reliability

• Build tooling for cost visibility, forecasting, and optimization
• Define SLOs, alerting, and performance tuning practices
• Improve reliability and scalability of AI infrastructure

Ownership & Collaboration

• Own projects end-to-end (RFCs, architecture, implementation, rollout, production support)
• Partner with AI teams to drive adoption of platform tooling and standards
• Produce high-quality documentation and improve developer experience

You'll need to have:

• Demonstrated experience building production software or platform systems
• Strong engineering fundamentals with distributed systems or backend platforms
• Experience or strong interest in observability and debugging complex systems
• Experience or strong interest in AI/ML systems, LLMs, or agent-based architectures
• Strong ownership mindset and ability to drive ambiguous problems to production
• Hands-on experience with modern agentic coding tools and multi-model workflows
• Working knowledge of agent architecture internals (context engineering, tool loops, sub-agent orchestration)

We'd love to see:

• Experience with OpenTelemetry and modern observability ecosystems, including instrumentation, collectors, exporters, and tools like Prometheus, Grafana, and tracing/log systems
• Experience designing and operating telemetry pipelines, including sampling, retention, cardinality, and cost tradeoffs, as well as integrating observability into CI/CD and developer workflows
• Familiarity with AI/agent frameworks, including instrumentation of LLM calls, tool usage, workflows, and evaluation signals (quality metrics, benchmarking, regression detection)
• Experience building cost monitoring, forecasting, and optimization systems for AI workloads
• Familiarity with cloud and infrastructure tooling (e.g., AWS, Azure, Kubernetes, Terraform)
• Experience with agentic infrastructure concepts such as MCP servers, hooks, skills, subagents, sandboxing, and persistent memory patterns
• Active engagement with the agentic engineering frontier, including emerging patterns (e.g., harness vs. model, review debt, feedback loops)
• Demonstrated agent-native development practices (iterating with agents using testing, verification, and feedback loops)
• Strong security awareness for autonomous systems, including sandboxing, prompt injection risks, credential exposure, and guardrails

If indicated, please note that years of experience are a guide; we will consider applications from all candidates who can demonstrate the skills necessary for the role.Discover what makes Bloomberg unique - watch our podcast series for an inside look at our culture, values, and the people behind our success.

Apply here: https://bloomberg.avature.net/careers/Public?jobId=18854

Hudson River Trading (HRT)

Quantitative Latency Engineer

📍Austin, TX, United States; Chicago, Illinois, United States; London, United Kingdom; New York, NY, United States; Singapore

Hudson River Trading (HRT) is seeking curious, thoughtful engineers who enjoy working with data and solving real-world technical problems to join our growing Market Structure Analysis team. In this role as a Quantitative Latency Engineer, you'll apply data-driven methodologies to understand and optimize trading technology and real-time interactions with financial markets across the globe, spanning traditional and crypto exchanges. No prior finance experience is needed!

Responsibilities

• Analyze time series network and exchange protocol captures
• Become familiar with the details of specific markets, attend presentations and liaise with exchange counterparts
• Research exchange features, capabilities, and architecture
• Automate collection and visualization of metrics that quantify efficacy of exchange communication
• Formulate and conduct controlled experiments that measure impact of calculated changes to HRT's trading infrastructure
• Communicate ideas, requirements, and results across disparate teams
• Improve fill rate of our hardware-based trading strategy
• Reduce incidence of cancel-reject responses
• Investigate and report details of various latency-sensitive exchanges

Profile

• You possess a degree in Data Analytics or a related field
• You can collect and interpret network and/or financial market data
• You have professional experience in latency reduction, preferably in finance
• You have a basic understanding of proprietary trading and exchange technologies

Skills

• Proficiency in data analytics including statistics, data visualization, and working with large data sets
• Basic understanding of TCP and UDP network protocols
• Extensive experience with Python and relevant data libraries (Pandas, Numpy/Scipy)
• Some familiarity with the details of modern computer systems and networks
• Experience with real time exchange market data and order entry a plus

The estimated base salary range for this position is 200,000 to 300,000 USD per year (or local equivalent). The base pay offered may vary depending on multiple individualized factors, including location, job-related knowledge, skills, and experience. This role will also be eligible for discretionary performance-based bonuses and a competitive benefits package.

Culture

Hudson River Trading (HRT) brings a scientific approach to trading financial products. We have built one of the world&aposs most sophisticated computing environments for research and development. Our researchers are at the forefront of innovation in the world of algorithmic trading.

At HRT we welcome a variety of expertise: mathematics and computer science, physics and engineering, media and tech. We're a community of self-starters who are motivated by the excitement of being at the cutting edge of automation in every part of our organization-from trading, to business operations, to recruiting and beyond. We value openness and transparency, and celebrate great ideas from HRT veterans and new hires alike. At HRT we're friends and colleagues - whether we are sharing a meal, playing the latest board game, or writing elegant code. We embrace a culture of togetherness that extends far beyond the walls of our office.

Feel like you belong at HRT? Our goal is to find the best people and bring them together to do great work in a place where everyone is valued. HRT is proud of our diverse staff; we have offices all over the globe and benefit from our varied and unique perspectives. HRT is an equal opportunity employer; so whoever you are we'd love to get to know you.

Please be advised: Use of AI tools during interviews or assessments is strictly prohibited, unless otherwise instructed or agreed upon. We employ various methods to evaluate the authenticity of candidate responses. If we determine that AI assistance was used during any stage of the hiring process, we reserve the right to immediately disqualify your candidacy or rescind any job offers extended.

Apply here: https://www.hudsonrivertrading.com/hrt-job/quantitative-latency-engineer/

Modal

The production cloud for AI. Run inference, training, batch processing and sandboxes with sub-second cold starts, instant autoscaling across thousands of GPUs and a developer experience that feels local.

Member of Technical Staff - Python SDK

AI needs a new infrastructure layer. We&aposre building it at Modal.

Every era of computing brought new workloads that previous infrastructure couldn&apost support: mainframes, databases, and the cloud. Each time, the company that rebuilt the layer underneath defined the decade. AI is no different, except it touches everything instead of one slice, and the window to build the layer underneath it is open right now.

Our customers include category-defining companies like Lovable, Ramp, Cognition, DoorDash, and Suno. They rely on Modal for instant GPU access, sub-second container starts, and native storage, so it&aposs simple to serve low-latency inference, fine-tune models, and access production-ready sandboxes at scale.

We recently raised a $355M Series C at a $4.65B valuation, led by General Catalyst and Redpoint Ventures. We&aposve crossed $300M+ ARR and grown fivefold since September.

Our team includes creators of popular open-source projects (e.g.,Seaborn, Luigi), academic researchers, international olympiad medalists, and experienced engineering and product leaders with decades of experience.

The Role:

We're looking for strong engineers with experience building developer tools that users love to work with. Our ideal candidate is someone with a demonstrated drive to build beautiful interfaces that enhance developer productivity.

Requirements:

• 5+ years of experience developing high-quality Python libraries with broad user-bases, ideally including some experience maintaining open-source software.
• Knowledge of advanced Python features, especially async programming.
• A strong product sense that manifests as a focus on developer ergonomics and productivity.
• A high level of customer empathy, good communication skills, and an openness to working directly with our users to help solve their problems.
• Ability to participate in on-call rotation and respond to production incidents.
• Ability to work in-person in our NYC or Stockholm office.
• Any of the following would be a plus:
  • Familiarity with modern data / ML / AI tools and workflows
  • Experience with Typescript, Go, or Rust

How to apply:

https://jobs.ashbyhq.com/modal/265d6127-dd34-433b-819a-1f935572c7d8

Numberly

SRE - Site Reliability Engineer

📍Hybrid - Paris

Numberly is recognized as one of the world&aposs leading data marketing specialists with nearly 500 employees and 11 offices worldwide serving more than 300 clients (L&aposOréal, Campari, Colgate, Nestlé, HSBC...). By putting technology to work for brands and consumers, Numberly is at the heart of business growth and everyone&aposs desire for more sustainable and relevant marketing. Numberly leverages the latest advances in data processing, analysis and activation, incorporating artificial intelligence technologies. This approach is part of a virtuous circle in which business competitiveness goes hand in hand with greater respect for privacy and data protection.

To achieve this, Numberly has always mastered, developed, and operated its own on-premise technical platforms thanks to the expertise of its in-house teams, without overlooking the Cloud when relevant. From development to datacenter hosting and network connectivity, everything is designed, built, maintained, and secured by our teams and we are proud of it.

Numberly is looking for a Site Reliability Engineer to design, operate, and improve the reliability of its infrastructure in order to always better serve its clients.

SRE Responsibilities

• Design, build, and operate highly available, robust, and scalable system architectures.
• Ensure the availability, performance, and reliability of production services.
• Know how to leverage existing tools (open-source or internal) and develop new solutions when relevant.
• Collaborate with other technical teams to proactively anticipate and resolve scaling challenges.
• Participate in the continuous improvement of operations practices (automation, monitoring, observability, incident management).

Qualifications

• Master's degree (Bac +4/+5) from a university, engineering school, or equivalent.
• 3 to 5 years of experience in operating production systems.
• Strong troubleshooting and problem-solving skills.
• Good communicator, capable of popularizing their work, defending their ideas, and listening to others.
• Willingness to grow and help others grow, both technically (meetups, internal training) and humanly.
• Strong understanding of Linux internals.
• Fluent in French and proficient in English.

Technical Environment

• Physical infrastructure: 3 datacenters located in the Paris region
• Servers: +500
• Automation: Ansible, Terraform
• CI/CD: GitLab
• Virtualization: Proxmox
• Containers: Kubernetes (on-premises Kubespray and Talos, AWS EKS, Azure AKS)
• Load-balancing: HAProxy, OpenResty (nginx), Envoy
• Monitoring: Prometheus, Thanos, Kafka, Elasticsearch, Graylog
• Tracing: Sentry
• Languages: Python, Go, Rust
• Server OS: Ubuntu / Debian
• User OS: Windows / MacOS / Linux
• APIs: REST
• Cloud: AWS, Azure
• Databases: PostgreSQL, Hadoop, MSSQL, ScyllaDB, MongoDB

Security Tools & Frameworks

• MDM: Intune, Iru (Kandji)
• Logs: Kafka, Graylog, Vector, CrowdSec
• IDS/IPS: Falco
• EDR: HarfangLab, Microsoft Defender for Endpoint
• Scanning: Ivre, Burp Suite
• SAST: GitLab SAST, Semgrep, etc.
• KMS/PKI: HashiCorp Vault
• Containers: Kyverno, Harbor

Additional information

• At Numberly, we share a passion for transmission: weekly internal talks, meetings with expert professionals in their field, continuous learning.
• Fast and powerful onboarding, in particular thanks to: the mentor assigned to each newcomer; to Live my life in different teams; Happy Meetings: monthly internal meetings to meet up with all our teams around the world and share group news.
• We cultivate freedom of speech which allows everyone to participate in the development of the group.
• We act positively on our ecosystem through 1000mercis impacts and via our activities which create value in the Open Internet and contribute to the enrichment of Open Source.
• Numberly is an actor of diversity with a gender equity score of 97/100.
• Numberly is ISO/IEC 27001:2023 certified; this certification recognizes compliance with the highest standards in information security.
• Numberly is an international environment with more than 30 nationalities in our teams.
• Offices in the image of each of the teams, a generous library, a large fully equipped music studio, two cats, vermicomposting, the possibility of bringing your pet and space for bicycles! In each kitchen: coffee, tea, unlimited infusions and also mystery lunches, Wellpass (ex-Gymlib) partnership, sports classes and parties (often in disguise).
• Possible remote working days.
• Swile card (meal vouchers).
• Possible mobility in our various offices abroad.
• Numberly welcomes people with disabilities.

Apply here: https://joinus.numberly.com/en/jobs/7917284-sre-site-reliability-engineer/8883340c-f258-444b-8e58-88905eb7702c

Revolut

Mid/Senior Software Engineer (Python)

📍Remote: Cyprus · Czech Republic · Poland · Porto · Portugal · Romania · Serbia · Spain · Sweden · UAE · UK

About Revolut

People deserve more from their money. More visibility, more control, and more freedom. Since 2015, Revolut has been on a mission to deliver just that. Our powerhouse of products - including spending, saving, investing, exchanging, travelling, and more - help our 75+ million customers get more from their money every day.

As we continue our lightning-fast growth,‌ 2 things are essential to our success: our people and our culture. In recognition of our outstanding employee experience, we&aposve been certified as a Great Place to Work™. So far, we have 13,000+ people working around the world, from our offices and remotely, to help us achieve our mission. And we&aposre looking for more brilliant people. People who love building great products, redefining success, and turning the complexity of a chaotic world into the simplicity of a beautiful solution.

About the role

Our Technology team builds the systems and experiences that keep Revolut moving. From the infrastructure behind our innovative app to the features used by millions of people around the world, they bring sharp thinking, speed, and a focus on meaningful impact to everything they do.

We're looking for a Python Engineer who can write high-quality code and build innovative solutions for heavily regulated financial systems.

Whether designing our own chatbot or creating automated financial crime quality controls in just a few weeks, our engineering projects are varied. You'll collaborate on a product team with Data Scientists, Analysts, Engineers, Product Owners, and Operations Managers to deliver the most value to our customers.

Up to shape what&aposs next in finance? Let&aposs get in touch.

What you'll be doing

• Building APIs and jobs and data pipelines, making sure they&aposre properly designed and scaled according to business needs
• Writing event consumers to build data models for new flows and processes

What you&aposll need

• 5+ years of experience as a Software Engineer
• 3+ years of experience engineering with Python as your primary language
• An academic background in STEM
• Fluency in Python, SQL, and other OOPLs
• Experience with API development and integration
• A practical understanding of distributed systems
• The ability to write concurrent code in IO/CPU bound situations
• Experience with Docker, K8s, Ansible, Teamcity, monitoring, and alerting

Nice to have

• Experience with prototyping and sketching
• Multiple side projects or open source contributions
• Exposure to GCP

How to apply: https://revolut.la/EuroPython2026_MidSeniorSoftwareEngineerPython

02 Jul 2026 6:36pm GMT

Phew, PyCon US 2026 is a wrap! Now it's time to share about everything security that happened in case you weren't able to attend (or you just want to reminisce). Subscribe to the PyCon US channel on YouTube so you're notified as soon as recordings for each talk are published. This blog post will also be updated with links once all talks are available.

Hala Ali on generating SBOMs directly from the Python runtime

Juanita Gomez and Seth Larson were the chairs of the first talk track dedicated to security at PyCon US: Trailblazing Python Security! We're excited to share the recordings for each talk featured in the track:

• Anatomy of a Phishing Campaign by Mike Fiedler
• Zero Trust in 200ms: Implementing Identity-Per-Transaction with Python and Serverless by Tristian McKinnon
• Rust for CPython by Emma Smith
• Asleep at the Wheel: SBOMit for Python builds by Sanchit Sahay and Abhishek Reddypalle
• Post-Incident Runtime SBOM Generation from Python memory by Hala Ali
• GitHub Actions Security in Python Packages by Andrew Nesbitt
• Breaking Bad (Packages): Why Traditional Vulnerability Tracking Fails Supply Chain Attacks by Shelby Cunningham and Madison Ficorilli

Thanks so much to the speakers and volunteers who helped make this inaugural track a success. For several of the talks above the room was standing-room only! The support and interest in security topics from the Python community was incredible to see and we're hoping to see you all again next year to continue learning and sharing ideas.

"Security isn't free!"

Following Amanda Casari's amazing keynote, Mike Fiedler and Seth Larson took the stage to give a brief update of the past year of security work at the Python Software Foundation (PSF).

Overall 2026 was the year of more, both good and not-so-good. More packages than ever and being published to the Python Package Index (PyPI), but also more malware and specifically watering-hole attacks targeting PyPI users. The double-edged sword of being a popular and widely-used programming language also makes Python and its users a more interesting target for attackers.

The slides for this presentation are available for download via speakerdeck.

For the fourth year in a row Seth Larson hosted a security-themed Open Space at PyCon US. This year the open space was titled "Security for Open Source project maintainers" with the goal of "gather with fellow open source project maintainers to discuss current challenges with open source security".

A handful of Open Source maintainers were present to discuss security issues. The format was open-ended discussion with a few prompts to start the discussion off including vulnerability handling and CI/CD security.

Following the many watering-hole attacks on established Open Source projects involving CI/CD pipelines, hardening project CI/CD pipeline definitions was the first discussion topic. The overwhelming recommendation was to use Zizmor with its --fix mode and a GH_TOKEN. Other tools came up such as gha-update, pinact, Dependabot, Renovate, and using lock files like pip-compile to lock dependencies in your CI/CD workflows. Dependency Cooldowns were also a popular concept for dependencies involved in builds and publishing.

The most recent resource published for all-in-one repository security was a blog post by William Woodruff on open source security at Astral that details CI/CD security and how to configure repositories.

The bulk of the discussion was about vulnerabilities and challenges around handling the volume of reports from reporters using LLMs. The prevailing theme is that the volume of reports has increased substantially, with anec-data being that vulnerability handling "previously was ~20% of time spent on a project" and is now "almost all" the time spent. Many reports are duplicates, verbose, extremely low quality due to the use of LLMs but the number of valid or almost-security issues has increased, too.

This "almost all" number is particularly frightening, many Open Source contributors didn't get into this line of volunteering because they wanted to work on security-related tasks.

There was some side discussion about how to judge whether handling a vulnerability in private was still a useful thing to do if the vulnerability is trivially discoverable using a publicly available LLM. The conversation referenced the Linux kernel's discussion of the same topic.

Talking about ways to mitigate the negative effects of LLMs and agents on security work lead to a discussion of security policies and threat models. Few projects, especially smaller ones, have tried this approach of documenting their threat model to see if this has a meaningful impact on the quality or quantity of reports received.

Python, Django, Node, and curl were given as good examples of threat models to copy and learn from for your own projects.

There was an issue of discoverability, some documentation is in CONTRIBUTING.md, or on a website, but not checked into source control for the actual project, or used an organization-wide .github/SECURITY.md. Some projects didn't use an AGENTS.md (and didn't want to, for fear of inviting even more LLM-driven contributions), and it was difficult to tell whether any particular documentation was having an effect. There's also the difficulty of models changing or becoming more capable over time. More testing is necessary here!

A separate meta-conversation through the previous topics was about having a way to signal that a particular contributor or security researcher had a high "contributor quality". The value of such a signal would tell maintainers where to focus their limited time, such as reports from someone more likely to engage with the process and follow instructions. "Talking with an LLM, indirectly" was mentioned multiple times as a negative but unfortunately common experience of maintainers interacting with first-time contributors.

gh-profiler from Eric Matthes was referenced during the discussion, and a few maintainers tested this on their own profiles and profiles of low-quality contributions they'd received recently. There was an interest in finding metrics or signals that are tougher to automate or fake. The group identified that as soon as such a signal was widely used that agents would simply "route around" the barrier.

Thanks to Alpha-Omega for sponsoring security at the PSF. Their support funds two roles: the Security Developer-in-Residence, held by Seth Larson, and the PyPI Safety & Security Engineer, held by Mike Fiedler. Seth and Mike delivered a joint update on their work at PyCon US 2026.

The over-arching theme of the update was the impact of higher volumes of reports, vulnerabilities, malware, and supply-chain attacks are having on the Python ecosystem along with work done to mitigate some of the hockey-stick graphs we're seeing.

Seth detailed the Python Security Response Team (PSRT) governance and process changes detailed in PEP 811. These changes aim to improve the capacity of the PSRT ahead of an increasing workload triaging and remediating security vulnerabilities reported to Python and pip.

Mike detailed work for mitigating malware and supply-chain attacks to PyPI, especially novel attacks such as the Shai-Hulud worm that targets and exploits insecure CI/CD pipelines and developer API tokens to propagate malware.

If you are interested the full set of slides is available for download via speakerdeck.

02 Jul 2026 3:48pm GMT

import typer

app = typer.Typer()


@app.command()
def hello(name: str):
    print(f"Hello {name}")


if __name__ == "__main__":
    app()

02 Jul 2026 4:00am GMT

Weeknotes (2026 week 27)

The last entry in this series was published 10 weeks ago so it really is time for another review of the releases I did during this time.

Releases

feincms3-forms

The feincms3-forms forms builder has gained a documentation page on the wonderful Read the Docs service. The 0.6.1 release doesn't contain any code changes, just pyproject.toml updates and the mentioned documentation rework.

django-imagefield

django-imagefield 0.23 is still in alpha. The handling of image fields when using libvips is optimized to use less memory hopefully. We'll see. I also added some tests to verify that .mpo files are handled properly.

feincms3

The Vimeo embed now always sets the dnt=1 parameter on the <iframe>, which asks Vimeo to not track the user.

django-mptt

I wrote about the somewhat annoying maintenance again. The library is still officially unmaintained, but I did a lot of work either just closing issues or also fixing them. The docs also contain many clarifications. I only released 0.19rc1 for now.

feincms3-sites and feincms3-language-sites

Last time I mentioned that default HTTP/S ports are now stripped so that the host matching can determine the correct site. Now a new case appeared where trailing dots weren't stripped. The normalization of hosts has been extended. I'm sure we're still missing some exotic cases where we should do more normalization, but we'll cross that bridge when we get there.

django-prose-editor and django-js-asset

Various upgrades to the editor and especially the importmaps rework in both packages - the importmap infrastructure should now be CSP-compatible! I wrote more about that in the last post The 2026 way of using importmaps in Django.

django-content-editor

Minor bugfixes and a major version bump because of the rework of the JavaScript code into multiple ES modules. The content editor now uses importmaps as well.

django-fhadmin

Small bugfix so that links aren't underlined in the app groups list when they shouldn't be, matching how the Django admin itself behaves.

django-cabinet

The cabinet / prose editor integration for the file (or image) picker is final and released as a stable version.

django-json-schema-editor

This small release only contains more correct German translations of strings.

Honorable mention: django-debug-toolbar

I didn't actually create this release, but I contributed various changes to it. The changelog for 7.0 is here.

01 Jul 2026 5:00pm GMT

I once needed the SLA for an endpoint my dashboard leaned on, so I asked the team that owned it. Their lead came back with 200ms ± 500ms. Read that literally and the fastest responses arrive 300ms before the request is even sent. The number wasn't malicious - it came straight out of the standard formulas. The formulas were wrong for the data, and that mistake is everywhere.

30 Jun 2026 10:00am GMT

As I have discussed in previous posts, "AIs" can make mistakes. In fact, they do make mistakes, and their mistake-making patterns are such that where and how they will make mistakes is both uncertain and constantly changing.

Thus, in any scenario where you want to attempt to make "productive" use of "AI", you must have a system in place for checking every result. Not checking some results; checking every result. If each result might have a consequence for you (and if it didn't have a consequence, why bother automating it?) and you cannot predict in advance which kinds of results will need verification, then verification is always required.

The verification often ends up being just as expensive as doing the work in the first place, which means that if you want your usage of "AI" to be personally profitable, you have to find someone else to externalize the cost of verification onto. This person becomes your adversary, and, if you are successful, your "AI's" victim.

The Ladder-Climber And Their Reverse-Centaur Rungs

One way that this constellation of facts can straightforwardly assemble themselves into a dystopian nightmare is the phenomenon, described by Cory Doctorow, of the reverse centaur. This is when your employer non-consensually turns you into the verification system. The "AI" does the fun part of initially performing the work, and then you do the boring part where you check if the robot is right and clean up its messes, even if everyone already knows that it would, in aggregate, be cheaper for you to do the work in the first place.

Reverse centaurs can be made from any automation, not only "AI" automation. I think that there is a reason that this term happens to have emerged in the "age of AI", though, and not with earlier automation technologies (even those which were considerably more viscerally horrific). That reason is: the wrongness of "AI" output is not merely a technical feature that must be compensated for, it is a generalized externality.

As I mentioned above, if you are responsible for the entirety of the work, both extruding the "AI" output and checking it, it's usually cheaper to have humans do the entirety of the work to begin with. When humans do the writing directly, we can check as we go, and thus verification doesn't need to be as comprehensive.

When "AI" coding advocates say "code review is the bottleneck", what they are observing is that the LLM is still rolling the dice for each PR, and a human is still necessary to verify that each of those rolls is a winner. But calling this process "code review" is a bit of a misnomer; it's not really "code review" in the traditional sense, it's human understanding.

Before the advent of "AI", the human understanding was implicit in the process of writing the code in the first place¹, and the code review was a way of diffusing and extending that understanding. Now that the code can be authored with no initial understanding taking place, that cost has not gone away, it has moved.

Human understanding was always the bottleneck.

However, this is taking a collaborative view of a software project, where satisfying the needs and solving the problems of your customers are the goals. We can see that "AI" is a bad tool to satisfy those goals, because all it's doing is converting the first half of the work, that of understanding the code as you write it, to understanding the agent's output as you read it.

What if, instead, we were to take the view that every software company is a Hobbesian nightmare, red in tooth and claw? In this view, the only goal of a software project is for the individual developers to make their promo cycles and get their bonuses. Given that there is only a certain amount of money to go around, this is a zero-sum game where each programmer wants to look more productive than their colleagues.

Pretty much every organization finds it easy to reward "productivity" as expressed by lines of code emitted, but the benefits of doing thorough and thoughtful design, analysis, and code review very difficult to reward. In this world, an LLM is an invaluable tool for the sociopathic ladder-climber, particularly if your legacy organization is still structuring their workflows as if the person prompting the bot is "writing" the code, and then they get to foist off the act of "reviewing" the code onto someone else.

Here, the prompter effectively externalizes the cost of the LLM's failures but internalizes any benefits. The prompter will vibe-code a big feature, so large that the assigned reviewer can't possibly comprehend it all effectively. When this happens, the reviewer will, eventually, be pressured to approve it, even if they can try to spot a few problems along the way. The reviewer has their own work to get back to, after all, the obligation to review the prompter's (read: the bot's) code is a drain on their time that they are not going to get rewarded for.

If this feature is a big success, the prompter gets a promotion. If it causes a big issue, well, the reviewer must not have been careful enough.

This is why LLMs are "good for coding", and also why their biggest promoters keep having outages.

The Generative Gish Galloper

Coding is the biggest "success story" of this type of adversarial communication, but it is by far not the only instance of such a thing. LLMs create a new form of leverage that can turn Brandolini's law from a linear advantage into an exponential one. If you are engaged in a political debate where you want to overwhelm the other side in nonsense, an LLM can generate bullshit faster than it is physically possible for a human being to type, let alone respond thoughtfully. There is an asymmetry to the utility of this weapon as well: only one side of the political spectrum wants to flood the zone and destroy trust in institutions and the concept of truth. There's a good reason that the fascists love it.

Straightforward Spam and Fraud

This is kind of obvious, but LLMs can generate lightly-customized, plausible-looking text much more quickly than any human being. This facilitates their use in fraud, spam, and scams. In a spamming or fraudulent interaction, once again, the costs are externalized onto the victim: the recipient of a spam message has to do all the work of "checking" the LLM's output. Spammers already expect very low hit rates from boilerplate, and if the LLM can increase those percentages from 1% to 5% the technology will pay for itself; they don't need anything like reliable accuracy.

Customer "Support"

If you have any kind of commercial relationship with a company, I probably don't even need to mention this: customer "support" bots are a misery. Everybody knows it at this point. But customer support is usually conceptualized by businesses as an adversarial interaction, because it is a cost center. They maintain internal metrics on time-to-resolution and try to optimize them. Implicitly, this creates a dynamic where the goal of the customer service agent's job is not to solve your problem, but to emit noise that will cause you to think your problem is resolved, or to give up, as fast as possible. Unsurprisingly, LLMs can emit this noise faster than humans can, getting those customers off the phone. But those customers will remember those interactions, and the story outside the TTR metrics is horrible.

Similarly to the situation in software development, LLMs can look very good on paper for customer support, but mostly what they are doing is illuminating the problems with the industry's existing metrics, by turning "winning the metrics battle against the customer" into a more obvious and immediate defeat for the company's long term reputation.

"Education"

In 2026 it is sadly a fact of life that students cheat all the time using "AI", and that this cheating is very successful, in that the teachers find it very hard to detect.

LLMs are great for cheating on schoolwork because the student is externalizing the work of the checking onto the teachers, who are often starting at a disadvantage to begin with, at least in the US.

My view is that this is happening because of a divergence in the way that students vs. teachers (or, more accurately, "the broader educational system") view grading.

When a student is asked to write an essay, the teachers see the effort as both intrinsically worthwhile for the student, as well as useful as a pedagogical tool to evaluate and react to the student's progress. The student, by contrast, sees a stumbling block designed to knock them off the path to success and into a permanent underclass. It is no wonder that the student sees "AI" as useful to their own goals and has no compunction about deploying it.

There is a bitter irony that the ability to understand the inherent value of actually writing the essay on their own is the sort of thing that students can really only learn by writing a bunch of essays. There's no way that I can think of which makes the benefit legible as long as a shortcut is available.

The net effect here is a downward spiral, where the already-wobbling educational system is sustaining an attack that it doesn't have the resources to recover from. The individual students' attacks against their teachers and their schools' grading systems might appear to momentarily succeed, but they will win the battle and lose the war.

Spamming "For Good"?

Usually when we talk about someone unilaterally choosing to enter into an adversarial relationship, that's an "attack" and for good reasons we have a negative impression of the attacker. However, I would be remiss if I did not point out that there are some cases where the relationship was already adversarial; just because you're the attacker doesn't mean that you are evil.

For example we might imagine use-cases like automatically filing appeals for prior authorizations against health insurance. It's relatively well-known at this point that the main way for-profit insurers maintain their margins is by denying claims right up to the line of the policies themselves being fraud, so using a spamming tool to fight them might be entirely justifiable² in that case.

Similarly, using an LLM could be justified in a fight against a company refusing to honor a warranty. One could imagine using an LLM to immediately generate replies and escalations.

However, even in imagined cases like these, the underlying problem is that the insurers and the vendors already have a tremendous amount of structural power, so it is more likely that they will have the advantage in deploying a communications weapon like an LLM, as well as enacting policies to simply ignore any LLM-based communication that you might submit. Worse, if these strategies were to become widespread, they might provide an excuse to reject any communications by feeding them into an unreliable "LLM detector" and issuing an automated "computer says no" even to hand-written correspondence.

It is also worth stressing that these cases are imagined, as compared to the very real coworker-abuse, spam, scam, fraud, and disinformation campaigns being waged in real life today.

Therefore, while legitimate uses might exist, it's hard to imagine that there's anywhere they would be genuinely valuable and sustainable. In the best case "AI" will provide a temporary advantage for underdogs that will provoke an arms race which the resource-advantaged adversaries will win in the long run, in the worst case the arms race itself will cement permanent structural change that will make things worse.

"Search" By Stealing

Most of the adversarial utility of "AI" is on the "write" side, since write-amplification is more obviously aggressive than reading. But the "read" side of LLMs - summarization and question-answering - can be a form of attack as well.

To begin with, the act of reading itself is currently enormously destructive, but that's arguably not a fundamental aspect of this technology. They could set reasonable rate-limits and respect things like robots.txt, as search engines have for decades now. They could also refrain from committing criminal levels of copyright infringement. But, today, using "AI" tools does suborn this sort of out-of-control crawling.

More insidiously, consider the scenario described in this YouTube video. The LTT Bros decided to try Linux again, and in the course of so doing, they had problems. When trying to solve these problems, they were faced with a choice: they could consult Reddit, or they could ask an LLM. Asking an LLM would "gaslight the heck out of" them, but they still found it preferable, because they would at least get an answer without getting yelled at.

Initially this sounds great. But it also means that you want to extract knowledge from a community, while mechanically eliding any values or norms that the community may want to impart as part of offering that knowledge. As someone who spent many years in a community tech support role, this is worrying. Many requests for support are people asking how to do things that will momentarily solve a superficial problem but create a long-term reliability problem or even an immediate security risk, that the question-asker doesn't want to hear about. Consider the question "I'm tired of entering my password so much, how do I make it so my laptop unlocks automatically". An obsequious chatbot will helpfully tell you how to do this without pushback.

But, this is also a sort of ethically murky area. The Linux community is somewhat famously, for many years now, a toxic cesspool of general hostility, misogyny, etc. It is certainly a good thing that people can get access to this knowledge without subjecting themselves to abuse. But it also means that the people with the power and the privilege to change the community for the better can just quietly withdraw, rather than fixing the problems. It also means that the positive elements of culture cannot be transmitted, and people will have no opportunity to learn about unknown unknowns.

In this case, the "adversarial" communication is with society. The thing that using an LLM for search lets you do is withdraw from society and avoid forming any personal connections. There are some personal connections which are painful and annoying, and so that can feel like a momentary balm. But the need to make connections in general is, like, the concept of society itself.

Who Am I Hurting?

LLMs are good at adversarial communication. They are so good at it, relative to their other benefits, that they will tend to make communications adversarial if you are not remaining vigilant about the possibility that it might do so. My request to you, dear reader, if you are going to use such tools, is to always ask yourself, "who might I be hurting, if I use an LLM for this?"

If you're using an "AI", who is its adversary? If you haven't given it one yet, who might the "AI" turn into an adversary? Who might you overwhelm with an asymmetric amount of output, or, if you're receiving information and not sending it, who are you taking that information from without consulting?

Figure out the answers to these questions and conduct yourself accordingly; the answer might be "yourself".

Acknowledgments

Thank you to my patrons who are supporting my writing on this blog. If you like what you've read here and you'd like to read more of it, or you'd like to support my various open-source endeavors, you can support my work as a sponsor!

23 Jun 2026 8:06pm GMT

Codecov's unreliability breaking CI on my open source projects has been a constant source of frustration for me for years. I have found a way to enforce coverage over a whole GitHub Actions build matrix that doesn't rely on third-party services.

09 Jun 2026 12:00am GMT

Let's say you're writing a Python library.

In this library, you have some collection of state that represents "options" or "configuration" for a bunch of operations. Such a set of options is a bundle of potentially ever-increasing complexity. Thus, you will want it to have an extremely minimal compatibility surface, with a very carefully chosen public interface, that is either small, or perhaps nothing at all. Such an object conveys state and might have some private behavior, but all you want consumers to be able to do is build it in very constrained, specific ways, and then pass it along as a parameter to your own APIs.

By way of example, imagine that you're wrapping a library that handles shipping physical packages.

There are a zillion ways to do it ship a package. There are different carriers who can ship it for you. There's air freight, and ground freight, and sea freight. There's overnight shipping. There's the option to require a signature. There's package tracking and certified mail. Suffice it to say, lots of stuff.

If you are starting out to implement such a library, you might need an object called something like ShippingOptions that encapsulates some of this. At the core of your library you might have a function like this:

1
2
3
4
5

async def shipPackage(
        how: ShippingOptions,
        where: Address,
    ) -> ShippingStatus:
    ...

If you are starting out implementing such a library, you know that you're going to get the initial implementation of ShippingOptions wrong; or, at the very least, if not "wrong", then "incomplete". You should not want to commit to an expansive public API with a ton of different attributes until you really understand the problem domain pretty well.

Yet, ShippingOptions is absolutely vital to the rest of your library. You'll need to construct it and pass it to various methods like estimateShippingCost and shipPackage. So you're not going to want a ton of complexity and churn as you evolve it to be more complex.

Worse yet, this object has to hold a ton of state. It's got attributes, maybe even quite complex internal attributes that relate to different shipping services.

Right now, today, you need to add something so you can have "no rush", "standard" and "expedited" options. You can't just put off implementing that indefinitely until you can come up with the perfect shape. What to do?

The tool you want here is the opaque data type design pattern. C is lousy with such things (FILE, pthread_*_t, fd_set, etc). A typedef in a header file can easily achieve this.

But in Python, if you expose a dataclass - or any class, really - even if you keep all your fields private, the constructor is still, inherently, public. You can make it raise an exception or something, but your type checker still won't help your users; it'll still look like it's a normal class.

Luckily, Python typing provides a tool for this: typing.NewType.

Let's review our requirements:

1. We need a type that our client code can use in its type annotations; it needs to be public.
2. They need to be able to consruct it somehow, even if they shouldn't be able to see its attributes or its internal constructor arguments.
3. To express high-level things (like "ship fast") that should stay supported as we add more nuanced and complex configurations in the future (like "ship with the fastest possible option provided by the lowest-cost carrier that supports signature verification").

In order to solve these problems respectively, we will use:

1. a public NewType, which gives us our public name...
2. which wraps a private class with entirely private attributes, to give us an actual data structure, while not exposing the constructor,
3. a set of public constructor functions, which returns our NewType.

When we put that all together, it looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

from dataclasses import dataclass
from typing import Literal, NewType

@dataclass
class _RealShipOpts:
    _speed: Literal["fast", "normal", "slow"]

ShippingOptions = NewType("ShippingOptions", _RealShipOpts)

def shipFast() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts("fast"))

def shipNormal() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts("normal"))

def shipSlow() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts("slow"))

As a snapshot in time, this is not all that interesting; we could have just exposed _RealShipOpts as a public class and saved ourselves some time. The fact that this exposes a constructor that takes a string is not a big deal for the present moment. For an initial quick and dirty implementation, we can just do checks like if options._speed == "fast" in our shipping and estimation code.

However, the main thing we are doing here is preserving our flexibility to evolve the related APIs into the future, so let's see how we might do that. For example, let's allow the shipping options to contain a concrete and specific carrier and freight method:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

from dataclasses import dataclass
from enum import Enum, auto
from typing import NewType

class Carrier(Enum):
    FedEx = auto()
    USPS = auto()
    DHL = auto()
    UPS = auto()

class Conveyance(Enum):
    air = auto()
    truck = auto()
    train = auto()

@dataclass
class _RealShipOpts:
    _carrier: Carrier
    _freight: Conveyance

ShippingOptions = NewType("ShippingOptions", _RealShipOpts)

def shipFast() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts(Carrier.FedEx, Conveyance.air))

def shipNormal() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts(Carrier.UPS, Conveyance.truck))

def shipSlow() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts(Carrier.USPS, Conveyance.train))

def shippingDetailed(
    carrier: Carrier, conveyance: Conveyance
) -> ShippingOptions:
    return ShippingOptions(_RealShipOpts(carrier, conveyance))

As a NewType, our public ShippingOptions type doesn't have a constructor. Since _RealShipOpts is private, and all its attributes are private, we can completely remove the old versions.

Anything within our shipping library can still access the private variables on ShippingOptions; as a NewType, it's the same type as its base at runtime, so it presents minimal¹ overhead.

Clients outside our shipping library can still call all of our public constructors: shipFast, shipNormal, and shipSlow all still work with the same (as far as calling code knows) signature and behavior.

If you need to build and convey some state within your public API, while avoiding breakages associated with compatibility churn, hopefully this technique can help you do that!

Acknowledgments

Thanks for reading, and thank you to my patrons who are supporting my writing on this blog. If you like what you've read here and you'd like to read more of it, or you'd like to support my various open-source endeavors, you can support my work as a sponsor.

22 May 2026 12:33am GMT