January 26, 2026 , bY reuven
Python
🎉 Pandas 3 is out!
As of last week, saying “pip install pandas” or “uv add pandas” gives you the latest version.
What’s new? What has changed?
I’ve got a whole YouTube playlist, explaining what you need to know: https://www.youtube.com/playlist?list=PLbFHh-ZjYFwFWHVT0qeg9Jz1TBD0TlJJT
January 22, 2026 , bY reuven
Python
The AI revolution is here. Engineers at major companies are now using AI instead of writing code directly.
But there’s a gap: Most developers know how to write code OR how to prompt AI, but not both. When working with real data, vague AI prompts produce code that might work on sample datasets but creates silent errors, performance issues, or incorrect analyses with messy, real-world data that requires careful handling.
I’ve spent 30 years teaching Python at companies like Apple, Intel, and Cisco, plus at conferences worldwide. I’m adapting my teaching for the AI era.
Specifically: I’m launching AI-Powered Python Practice Workshops. These are hands-on sessions where you’ll solve real problems using Claude Code, then learn to critically evaluate and improve the results.
Here’s how it works:
In 3 hours, we’ll cover 3-4 exercises. That’ll give you a chance to learn two skills: Python/Pandas AND effective AI collaboration. That’ll make you more effective at coding, and at the data analysis techniques that actually work with messy, real-world datasets.
Each workshop costs $200 for LernerPython members. Not a member? Total cost is $700 ($500 annual membership + $200 workshop fee). Want both workshops? $900 total ($500 membership + $400 for both workshops). Plus you get 40+ courses, 500+ exercises, office hours, Discord, and personal mentorship.
I want to encourage lots of discussion and interactions, so I’m limiting the class to 20 total participants. Both sessions will be recorded, and will be available to all participants.
Questions? Just e-mail me at reuven@lernerpython.com.
January 21, 2026 , bY reuven
Python
Many years ago, a friend of mine described how software engineers solve problems:
In other words: You can be the person writing the code, and solving the problem directly. Or you can manage people, specifying what they should do. Or you can invest in teams, telling them about the problems you want to solve, but letting them set specific goals and managing the day-to-day work.
Up until recently, I was one of those people who said, “Generative AI is great, but it’s not nearly ready to write code on our behalf.” I spoke and wrote about how AI presents an amazing learning opportunity, and how I’ve integrated AI-based learning into my courses.
I’ve recently realized that my perspective is oh-so-last year. Because in 2026, many companies and individuals are using AI to write code on their behalf. In just the last two weeks, I’ve spoken with developers who barely touch code, having AI to develop it for them. And in case you’re wondering whether this only applies to freelancers, I’ve spoken with people from several large, well-known companies, who have said something similar.
And it’s not just me: Gergely Orosz, who writes the Pragmatic Engineer newsletter, recently wrote that AI-written code is “mega-trend set to hit the tech industry,” and that a growing number of companies are already relying on AI to specify, write, and test code (https://newsletter.pragmaticengineer.com/p/when-ai-writes-almost-all-code-what).
And Simon Willison, who has been discussing and evaluating AI models in great depth for several years, has seen a sea change in model-generated code quality in just the last few months. He predicts that within six years, it’ll be as quaint for a human to type code as it is to use punch cards (https://simonwillison.net/2026/Jan/8/llm-predictions-for-2026/#6-years-typing-code-by-hand-will-go-the-way-of-punch-cards).
This is mind blowing. I still remember taking an AI course during my undergraduate years at MIT, learning about cutting-edge AI research… and finding it quite lacking. I did a bit of research at MIT’s AI Lab, and saw firsthand how hard language recognition was. To think that we can now type or talk to an AI model, and get coherent, useful results, continues to astound me, in part because I’ve seen just how far this industry has gone.
When ChatGPT first came out, it was breathtaking to see that it could code. It didn’t code that well, and often made mistakes, but that wasn’t the point. It was far better than nothing at all. In some ways, it was like the old saw about dancing bears, amazing that it could dance at all, never mind dancing well.
Over the last few years, GenAI companies have been upping their game, slowly but surely. They still get things wrong, and still give me bad coding advice and feedback. But for the most part, they’re doing an increasingly impressive job. And from everything I’m seeing, hearing, and reading, this is just the beginning.
Whether the current crop of AI companies survives their cash burn is another question entirely. But the technology itself is here to stay, much like how the dot-com crash of 2000 didn’t stop the Internet.
We’re at an inflection point in the computer industry, one that is increasingly allowing one person to create a large, complex software system without writing it directly. In other words: Over the coming years, programmers will spend less and less time writing code. They’ll spend more and more time partnering with AI systems — specifying what the code should do, what is considered success, what errors will be tolerated, and how scalable the system will be.
This is both exciting and a bit nerve-wracking.
The shift from “coder” to “engineer” has been going on for years. We abstracted away machine code, then assembly, then manual memory management. AI represents the biggest abstraction leap yet. Instead of abstracting away implementation details, we’re abstracting away implementation itself.
But software engineering has long been more than just knowing how to code. It’s about problem solving, about critical thinking, and about considering not just how to build something, but how to maintain it. It’s true that coding might go away as an individual discipline, much as there’s no longer much of a need for professional scribes in a world where everyone knows how to write.
However, it does mean that to succeed in the software world, it’ll no longer be enough to understand how computers work, and how to effectively instruct them with code. You’ll have to have many more skills, skills which are almost never taught to coders, because there were already so many fundamentals you needed to learn.
In this new age, creating software will be increasingly similar to being an investor. You’ll need to have a sense of the market, and what consumers want. You’ll need to know what sorts of products will potentially succeed in the market. You’ll need to set up a team that can come up with a plan, and execute on it. And then you’ll need to be able to evaluate the results. If things succeed, then great! And if not, that’s OK — you’ll invest in a number of other ventures, hoping that one or more will get the 10x you need to claim success.
If that seems like science fiction, it isn’t. I’ve seen and heard about amazing success with Claude Code from other people, and I’ve started to experience it myself, as well. You can have it set up specifications. You can have it set up tests. You can have it set up a list of tasks. You can have it work through those tasks. You can have it consult with other GenAI systems, to bring in third-party advice. And this is just the beginning.
When ChatGPT was first released, many people quipped that the hottest programming language is now English. I laughed at that then, less because of the quality of AI coding, and more because most people, even given a long time, don’t have the experience and training to specify a programming project. I’ve been to too many meetings in which developers and project managers exchange harsh words because they interpreted vaguely specified features differently. And that’s with humans, who presumably understand the specifications better!
As someone said to me many years ago, computers do what you tell them to do, not what you want them to do. Engineers still make plenty of mistakes, even with their training and experience. But non-technical people, attempting to specify a software system to a GenAI model, will almost certainly fail much of the time.
So yes, technical chops will still be needed! But just as modern software engineers don’t think too much about the object code emitted by a compiler, assuming that it’ll be accurate and useful, future software engineers won’t need to check the code emitted by AI systems. (We still have some time before that happens, I expect.) The ability to break a problem into small parts, think precisely, and communicate clearly, will be more valuable than ever.
Even when AI is writing code for us, we’ll still need developers. But the best, most successful developers won’t be the ones who have mastered Python syntax. Rather, they’ll be the best architects, the clearest communicators, and the most critical thinkers.
So, how do you prepare for this new world? How can you acquire this VC mindset toward creating software?
Learn to code: You can only use these new AI systems if you have a strong understanding of the underlying technology. AI is like a chainsaw, in that it does wonders for people with experience, but is super dangerous for the untrained. So don’t believe the hype, that you don’t need to learn to program, because we’re now in an age of AI. You still need to learn it. The language doesn’t matter nearly as much as the underlying concepts. For the time being, you will also need to inspect the code that GenAI produces, and that requires coding knowledge and experience.
Communication is key: You need to learn to communicate clearly. AI uses text, which means that the better you are at articulating your plans and thoughts, the better off you’ll be. Remember “Let me Google that for you,” the snarky way that many techies responded to people who asked for help searching the Web? Well, guess what: Searching on the Internet is a skill that demands some technical understanding. People who can’t search well aren’t dumb; they just don’t have the needed skills. Similarly, working with GenAI is a skill, one that requires far more lengthy, detailed, and precise language than Google searches ever did. Improving your writing skills will make you that much more powerful as a modern developer.
High-level problem solving: An engineering education teaches you (often the hard way) how to break problems apart into small pieces, solve each piece, and then reassemble them. But how do you do that with AI agents? That’s especially where the VC mindset comes into play: Given a budget, what is the best team of AI agents you can assemble to solve a particular problem? What role will each agent play? What skills will they need? How will they communicate with one another? How do you do so efficiently, so that you don’t burn all of your tokens in one afternoon?
Push back: When I was little, people would sometimes say that something must be true, because it was in the newspaper. That mutated to: It must be true, because I read it online. Today, people believe that Gemini is AI, so it must be true. Or unbiased. Or smart. But of course, that isn’t the case; AI tools regularly make mistakes, and you need to be willing to push back, challenge them, and bring counter-examples. Sadly, people don’t do this enough. I call this “AI-mposter syndrome,” when people believe that the AI must be smarter than they are. Just today, while reading up on the Model Context Protocol, Claude gave me completely incorrect information about how it works. Only providing counter-examples got Claude to admit that actually, I was right, and it was wrong. But it would have been very easy for me to say, “Well, Claude knows better than I do.” Confidence and skepticism will go a long way in this new world.
The more checking, the better: I’ve been using Python for a long time, but I’ve spent no small amount of time with other dynamic languages, such as Ruby, Perl, and Lisp. We’ve already seen that you can only use Python in serious production environments with good testing, and even more so with type hints. When GenAI is writing your code for you, there’s zero room for compromise on these fronts. (Heck, if it’s writing the code, and the tests, then why not go all the way with test-driven development?) If you aren’t requiring a high degree of safety checks and testing, you’re asking for trouble — and potentially big trouble. Not everyone will be this serious about code safety. There will be disasters – code that seemed fine until it wasn’t, corners that seemed reasonable to cut until they weren’t. Don’t let that be you.
Learn how to learn: This has always been true in the computer industry; the faster you can learn new things and synthesize them into your existing knowledge, the better. But the pace has sped up considerably in the last few years. Things are changing at a dizzying pace. It’s hard to keep up. But you really have no choice but to learn about these new technologies, and how to use them effectively. It has long been common for me to learn about something one month, and then use it in a project the next month. Lately, though, I’ve been using newly learned ideas just days after coming across them.
A big question over the last few years has been: If AI makes senior engineers 100x more productive, then why would companies hire juniors? And if juniors can’t find work, then how will they gain the experience to make them attractive, AI-powered seniors?
This is a real problem. I attended conferences in five countries in 2025, and young engineers in all of them were worried about finding a job, or keeping their current one. There aren’t any easy answers, especially for people who were looking forward to graduating, joining a company, gradually gaining experience, and finally becoming a senior engineer or hanging out their own shingle.
I can say that AI provides an excellent opportunity for learning, and the open-source world offers many opportunities for professional development, as well as interpersonal connections. Perhaps the age in which junior engineers gained their experience on the job are fading, and that participating in open-source projects will need to be part of the university curriculum or something people do in their spare time. And pairing with an AI tool can be extremely rewarding and empowering. Much as Waze doesn’t scold you for missing a turn, AI systems are extremely polite, and patient when you make a mistake, or need to debug a problem. Learning to work with such tools, alongside working with people, might be a good way for many to improve their skills.
Beyond skill development, AI-written code raises some other issues. For example: Software is one of the few aspects of our lives that has no official licensing requirements. Doctors, nurses, lawyers, and architects, among others, can’t practice without appropriate education and certification. They’re often required to take courses throughout their career, and to get re-certified along the way.
No doubt, part of the reason for this type of certification is to maintain the power (and profits) of those inside of the system. But it also does help to ensure quality and accountability. As we transition to a world of AI-generated software, part of me wonders whether we’ll eventually need to feed the AI system a set of government- mandated codes that will ensure user safety and privacy. Or that only certified software engineers will be allowed to write the specifications fed into AI to create software.
After all, during most of human history, you could just build a house. There weren’t any standards or codes you needed to follow. You used your best judgment — and if it fell down one day, then that kinda happened, and what can you do? Nowadays, of course, there are codes that restrict how you can build, and only someone who has been certified and licensed can try to implement those codes.
I can easily imagine the pushback that a government would get for trying to impose such restrictions on software people. But as AI-generated code becomes ubiquitous in safety-critical systems, we’ll need some mechanism for accountability. Whether that’s licensing, industry standards, or something entirely new remains to be seen.
The last few weeks have been among the most head-spinning in my 30-year career. I see that my future as a Python trainer isn’t in danger, but is going to change — and potentially quite a bit — even in the coming months and years. I’m already rolling out workshops in which people solve problems not using Python and Pandas, but using Claude Code to write Python and Pandas on their behalf. It won’t be enough to learn how to use Claude Code, but it also won’t be enough to learn Python and Pandas. Both skills will be needed, at least for the time being. But the trend seems clear and unstoppable, and I’m both excited and nervous to see what comes down the pike.
But for now? I’m doubling down on learning how to use AI systems to write code for me. I’m learning how to get them to interact, to help one another, and to critique one another. I’m thinking of myself as a VC, giving “smart money” to a bunch of AI agents that have assembled to solve a particular problem.
And who knows? In the not-too-distant future, an updated version of my friend’s statement might look like this:
January 21, 2026 , bY reuven
Python
Want to analyze data? Good news: Python is the leading language in the data world. Libraries like NumPy and Pandas make it easy to load, clean, analyze, and visualize your data.
But wait: If your colleagues aren’t coders, how can they explore your data?
The answer: A data dashboard, which uses UI elements (e.g., sliders, text fields, and checkboxes). Your colleagues get a custom, dynamic app, rather than static graphs, charts, and tables.
One of the newest and hottest ways to create a data dashboard in Python is Marimo. Among other things, Marimo offers UI widgets, real-time updating, and easy distribution. This makes it a great choice for creating a data dashboard.
In the upcoming (4th) cohort of HOPPy (Hands-On Projects in Python), you’ll learn to create a data dashboard. You’ll make all of the important decisions, from the data set to the design. But you’ll do it all under my personal mentorship, along with a small community of other learners.
The course starts on Sunday, February 1st, and will meet every Sunday for eight weeks. When you’re done, you’ll have a dashboard you can share with colleagues, or just add to your personal portfolio.
If you’ve taken Python courses, but want to sink your teeth into a real-world project, then HOPPy is for you. Among other things:
Want to learn more? Join me for an info session on Monday, January 26th. You can register here: https://us02web.zoom.us/webinar/register/WN_YbmUmMSgT2yuOqfg8KXF5A
Ready to join right now? Get full details, and sign up, at https://lernerpython.com/hoppy-4.
Questions? Just reply to this e-mail. It’ll go straight to my inbox, and I’ll answer you as quickly as I can.
I look forward to seeing you in HOPPy 4!
December 23, 2025 , bY reuven
Python
Can you believe that 2025 is almost over? It was full of big events for me, and yet it also whizzed past at breakneck speed.
And so, before we start 2026, I want to share a whole bunch of updates on what I’ve done over the last 12 months — and where I plan to go in 2026, as well.
The biggest thing for me this year was the new LernerPython site. This site supports functionality that was previously impossible — and because it’s mine, it also allows me to fix problems and customize things more easily. I look forward to extending and customizing it even more in the coming months. Thanks to everyone who sent me bug reports about the site and course content during this transition period.
Among other things, the site automatically integrates with our private Discord server, which is our hub for not only questions and discussions, but also calendar invites to live Zoom sessions. It’s also where I save recordings from our Zoom meetings.
The site is also integrated with Bamboo Weekly, ensuring that LernerPython+data members get a complimentary subscription without the need for manual intervention.
In 2025, I held live office hours on Zoom nearly every month for Python subscribers, and separate office hours nearly every month for Pandas subscribers. I really enjoy those sessions! Keep bringing your questions, thoughts, and stories.
I also held special, members-only lectures just about every month. These ranged in topic from the Unix shell to Marimo to dataclasses to concurrency. Thanks to those of you who attended, and especially those who suggested lecture topics. Recordings from these sessions are in the “meeting recordings” channels on Discord.
This year marked my start as a preferred partner with the Python Institute, a certification agency for Python. Members of LernerPython get discounts on their exams, making it easier (I hope!) to get good jobs in the Python world. In 2026, I plan to start a special monthly session of office hours to help you prepare for these exams.
With the new LernerPython.com now ready, I’ll record some new courses in 2026, as well as re-record some of the older, existing ones.
I’ll also bump up visibility of my Personal Python Coaching program, for people who just want an hour of my time for strategy, code review, or a clearer understanding of Python, Git, and Pandas topics.
My best, longest, and most intensive course is PythonDAB, the Python Data Analytics Bootcamp. Over four months, participants learn Python, Git, and Pandas, meeting twice each week, solving exercises, and digging into the nuts and bolts of Python and Pandas. Cohort 8 started earlier this month, and the sessions are (as always) full of insightful questions and comments. I expect to open PythonDAB 9 in late May or early June of 2026 — and if you think it’s a good fit for you, I hope that you’ll apply, or at least ask me about it!
This year marked the start of a new class: HOPPy, Hands-on Projects in Python. HOPPy is about learning through doing, building a project that’s meaningful to you — but within the general theme of that specific HOPPy cohort. People created some amazing applications, from a communications system for heatlh clinics to a personal blood-pressure monitor to a bank status summarizer.
HOPPy is open (for an additional fee) to LernerPython members, and is included in the price for PythonDAB participants. I will be running 4-5 HOPPy cohorts in 2026, including one in January about data dashboards. More info is coming soon — but if you’ve always wanted to learn more in a mentored environment, and as a bonus add a new product to your personal portfolio, then HOPPy is just what you’re looking for.
I gave a good deal of training classes at companies in 2025, including at Apple, Arm, Cisco, Intel, and Sandisk. (I also gave a number of online classes for O’Reilly’s platform.) These range from “Python for non-programmers” to intro and advanced Python, to intro Pandas, to my “Python Practice Workshop” and “Pandas Practice Workshop” one-day courses.
If your team wants to level up its Python skills, let’s chat! I’d love to hear more about your team’s needs, and what kind of custom class would work best for you.
A number of companies also joined LernerPython using my team membership feature, allowing a manager to control the allocation of seats.
I can’t get enough of Python conferences, which combine serious learning with friendly people. This year, I attended a number of conferences in person:
I also spoke at a number of online user groups, meetups, and regional conferences, including Python Ho (in Ghana) and the Marimo user community.
If you run a user group or conference, and would like to have me speak, please don’t hesitate to reach out!
I’ve already signed the contract to sponsor PyCon US 2026 in Long Beach, and I’ve submitted several talk and tutorial proposals. I hope to see you there!
When I finished Pandas Workout last year, I wasn’t sure if I really wanted to write another book. So of course, I found myself working on two books this year:
As you might know, I publish three weekly newsletters:
This year, I published a new, free e-mail course about uv, called “uv crash course,” taken from some recent editions of Better Developers. You can check it out at https://uvCrashCourse.com .
If you’re enjoying one or more of my newsletters, please tell others about them and encourage them to subscribe!
And if there are specific topics you would like me to cover? I’m always happy to hear from readers.
I’ve been especially active on YouTube this year, at https://YouTube.com/reuvenlerner, with about 60 new videos published about Python, Pandas, Git, Jupyter, and Marimo.
My most recent addition is a new playlist about Pandas 3. I’m adding new videos every day, and hope to get a good collection in place before Pandas 3 is released in the near future.
I also put the entire “Python for non-programmers” course (15 videos) and “Ace Python Interviews” course (50 videos) on my YouTube channel.
I’ve mainly been posting to Bluesky and LinkedIn, but I’ll often mirror postings to X (aka Twitter), Threads, and Fosstodon.
My blog has taken a back seat to other channels over the last few years, but I did find some reasons to post in 2025. Among my more interesting postings:
I believe that I only appeared on two podcasts this year — and both were episodes of Talk Python! I appeared on episode 503 in April, about PyArrow and Pandas (https://talkpython.fm/episodes/show/503/the-pyarrow-revolution), and more recently appeared on a panel discussion reviewing the year in Python news (https://www.youtube.com/watch?v=PfRCbeOrUd8) .
The last two years have been difficult in Israel. I’m relieved that the war with Hamas (and related conflicts with Hezbollah, Yemen, and Iran) are largely over. And I hope that we can now work to bring about peace, prosperity, freedom, and coexistence between Israelis and our neighbors, most especially the Palestinians.
The missile alerts and attacks, which regularly woke us up for the better part of two years, and which caused untold death, injury, and destruction, were one of the more terrifying periods I’ve ever lived through. Of course, I know that things were also bad for many Palestinian civilians.
My family donates to Israeli organizations that promote the rule of law, democracy, religious pluralism, and peacemaking with our neighbors — and while it’s easy to give up hope that things will improve, I refuse to do so. We can and should try to make a difference in the world, even if it’s just a small one.
I appreciate the very large, warm outpouring of care and support that I received throughout the last two years from so many of you. It really means a lot.
Beyond Israel, I’ve been watching developments in the US with concern. In particular, it’s quite upsetting to see the wholescale destruction of science, engineering, and medical research in the US. As a regular consumer of US government data (for Bamboo Weekly), the degree to which that data is no longer considered the most reliable and nonpartisan in the world is a grave disappointment — and a professional frustration.
If you’re reading this, then the Trump administration’s policies have affected you, too: The Python Software Foundation recently turned down a $1.5 million grant for increased Python security. That’s because the grant required the PSF give up its efforts to make Python available to everyone, no matter who they are.
If you’ve gotten $100 of value out of Python in the last year, then I ask that you join the PSF as a paid member. If even 5 percent of Python users were to join the PSF, that would reduce or eliminate Python’s dependence on any one government or organization, and allow it to concentrate on its goals. Joining the PSF also give you the right to vote in annual elections, which means choosing the people who will set Python’s priorities over the coming years.
Thanks again for your subscriptions, support, friendly notes, and bug reports. I look forward to a new year of learning even more new things, of meeting more interesting, smart people, serving your learning needs, and to helping make our world just a bit friendlier, closer, and peaceful.
Best wishes for a great 2026!
Reuven
December 8, 2025 , bY reuven
Python
30 years! It’s hard to believe, but it was in December 1995 (i.e., 30 years ago) that I went freelance, giving up a stable corporate paycheck. And somehow, I’ve managed to make it work: During that time, I’ve gotten married, bought a house, raised three children, gone on numerous vacations, and generally enjoyed a good life.
Moreover, I’m fortunate to really enjoy what I do (i.e., teaching Python and Pandas to people around the world, both via LernerPython.com and via corporate training). And why not? I earn a living from learning new things, then passing that knowledge along to other people in order to help their careers. My students are interesting and smart, and constantly challenge me intellectually. At the same time, I don’t have the bureaucracy of a university or company; if I have even five meetings in a given month, that’s a lot.
Of course, things haven’t always been easy. (And frequently, they still aren’t!) I’ve learned a lot of lessons over the years, many of them the hard way. And so, on this 30th anniversary of my going freelance, I’m sharing 30 things that I’ve learned. I hope that some or all of these can help, or just encourage, anyone else who is thinking of going this route.
Finally: I couldn’t have made it this far without the help of my family (wife, children, parents, siblings — especially my sister), and many friends who gave me support, suggestions, and feedback over the years. Thanks to everyone who has supported me, and allowed me to last this long without a real job!
[Note: I also published this on LinkedIn, at https://www.linkedin.com/pulse/30-things-ive-learned-over-years-business-reuven-lerner-rxu4f/?trackingId=SSgKz7QDFlH3oCZp9uVghQ%3D%3D.]
November 3, 2025 , bY reuven
Python
You’ve probably heard about uv:
But using uv isn’t just about learning a few commands. It’s about changing how you think about packaging, and what commands you run on a regular basis.
That’s why I’ve created a free uv crash course. Every day, for 12 days, you’ll get insights into how to (and how not to) use uv in your workflow. Every article includes oodles of examples, context, and ideas for switching to uv from other tools.
Check it out, for free: https://uvcrashcourse.com
October 21, 2025 , bY reuven
Python
I’ve been teaching Python and Pandas for decades — in companies, at conferences, and on YouTube — and I keep hearing the same frustrations everywhere I go:
That’s why I’ve spent the last few months completely rebuilding LernerPython.com. It’s a complete, structured learning experience, not just a set of courses.
Instead of leaving you on your own, here’s the system I’ve built:
✅ Dozens of courses on Python, Pandas, and Git, from “Python for non-programmers” to “Advanced Python objects.” Each course includes exercises and downloadable Jupyter notebooks.
✅ Hundreds of exercises to help everything “click,” plus new real-world data challenges every Wednesday from my Bamboo Weekly newsletter.
✅ Live mentorship: twice-monthly Zoom office hours and a private Discord where you can ask me anything.
✅ Members-only lectures on topics chosen by the community, from the Unix shell to pytest, from plotting to uv.
✅ Exclusive member perks: You’ll get discounts on Python certification, as well as access to any new courses I produce. Upcoming courses include FastAPI, PyArrow, concurrency, modern Pandas, and machine learning.
LernerPython.com isn’t just about videos. It’s about learning, practice, and personal guidance from someone who teaches this every day.
Here’s what some people have said:
“Reuven is one of the top five best teachers I’ve ever had! His clarity of expression and sense of humor make learning from him worthwhile and fun.”— Norman Eliaser, Business Systems Analyst
“I’ve gotten tremendous insight into how Python works. A great blend of not just how to do things, but why?”— Ahmed, Sr infrastructure engineer
“Reuven takes complicated subjects and makes them simple. There is a TON of fantastic material in a LernerPython subscription and more is always being added to it. It is one of my favorite and most valuable sources of Python educational materials.”— Michael Dahlberg, Systems Administrator
👉 Start your free two-week trial today, and see why learners around the world are becoming more confident with Python and Pandas. Check it out at https://LernerPython.com !
August 28, 2025 , bY reuven
Python
Want to use uv effectively? Take my free, 12-part “uv crash course,” at https://uvCrashCourse.com/ .
Like many others in the Python world, I’ve adopted “uv“, the do-everything, lightning-fast package manager written in Rust.
uv does it all: For people who just want to download and install packages, it replaces pip. For people who want to keep multiple versions of Python on their computer, it replaces pyenv. For people who want to work on multiple projects at the same time using virtual environments, it handles that, too. And for people who want to develop and distribute Python software, it works for them, also.
Here’s the thing, though: If you’re using uv as a replacement for one of these tools or problems, then you’re probably using it wrong. Yes, uv is a superset of these tools. But the idea is to sweep many of these things under the rug, thanks to the idea of a uv “project.” In many ways, a project in uv allows us to ignore virtual environments, ignore Python versions, and even ignore pip.
I know this, because I’ve used uv the wrong way for quite a while. It was so much faster than pip that I started to say
uv pip install PACKAGEinstead of
pip install PACKAGEBut actually, that’s not quite true — I use virtual environments on software projects, but 99% of my work is teaching Python via one-off Jupyter notebooks, which means I don’t have to worry about package and version conflicts. This being the case, I would just install packages on my global Python installation:
uv pip install --system PACKAGEWhich works! However, this isn’t really the way that things are supposed to be done.
So, how are we supposed to do things?
uv assumes that everything you do will be in a “project.” Now, uv isn’t unique in this approach; PEP 518 (https://peps.python.org/pep-0518/) from way back in 2016 talked about projects, and specified a file called pyproject.toml that describes a minimal project. The file’s specifications have evolved over time, and the official specification is currently at https://packaging.python.org/en/latest/specifications/pyproject-toml/.
For many years, Python programs were just individual files. A bunch of files could be put together into a single folder and treated as a package. The term “project” was used informally at companies and working groups, or among people who wrote Python editors, such as PyCharm and VSCode.
Even without a formal definition, we all kind of know what a package is — a combination of Python and other files, all grouped together into one whole, to solve one set of problems.
A pyproject.toml file is meant to be the ultimate authority regarding a project. TOML format is similar to an INI configuration file, but with Python-like data structures such as strings and integers. It also supports version numbers and comparison operators, allowing us to indicate exact, approximate, “not less than” and “not more than” versions for dependencies.
The minimal, initial pyproject.toml file looks like this:
[project]
name = "myproj"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.13"
dependencies = []As you can see, it only defines a “project” section, and then a number of name-value pairs. You can see that I called this project “myproj”, and that I created it using Python 3.13 — hence the “requires-python” line. It doesn’t do anything just yet, which is why it has an empty list of dependencies.
How and when do you create such a project? How does it intersect with Python’s virtual environments? How does it intersect with a Python version manager, such as pyenv, about which I’ve written previously?
Here’s the secret: To use uv correctly, you ignore pyenv. You ignore pip. You ignore venv. You just create and work with a Python project. If you do that from within uv, then you’ll basically be letting uv do all of the hard work for you, papering over all of the issues that Python packaging has accumulated over the years.
The thing is, uv does offer a variety of subcommands that let you work with virtual environments, Python versions, and package installation. So it’s easy to get lulled into using these parts of uv to replace one or more of them. But if you do that, you’re missing the point, and the overall design goals, of uv.
So, how should you be using it?
First: You create a project with “uv init”. It is possible to retroactively use uv on an existing directory of code, but let’s assume that you want to start a brand-new project. You say
uv init myprojThis creates a subdirectory, “myproj”, under the current directory. This directory contains:
Once the project is created, you can write code to your heart’s content, adding files and directories as you see fit. You can commit to the local Git repo, or you can add a remote repo and push to it.
So far, uv doesn’t seem to be doing much for us.
But let’s say that we want to modify main.py to download the latest edition of python.org and display the number of bytes contained on that page. We can say:
import requests
def main():
print("Hello from myproj!")
r = requests.get('https://python.org')
print(f'Content at python.org contains {len(r.content)} bytes.')
if __name__ == "__main__":
main()If you run it with “python main.py”, you’ll find that it works just fine, printing a greeting and the number of bytes at python.org.
But you shouldn’t be doing that! Using “python main.py” means that you’re running whatever version of Python is in your PATH. That might well be different from what uv is using. And (as we’ll see in a bit) it likely has access to a different set of packages than uv’s installation might have.
Rather, you should be running the program with “uv run python main.py”. Running your program via “uv” means that it’ll take your pyproject.toml configuration file into account.
Why would we care? Because pyproject.toml is shared among all of the people working on your project. It ensures that they’re in sync regarding not only the version of Python you’re using, but also the libraries and tools you’re using, too. (We’ll get to packages in just a moment.) If I make sure to configure everything correctly in “pyproject.toml”, then everyone on my team will have an identical environment when they run my code. It also means that if we install our code on a project system, it’ll also use things correctly.
So, what happens when I run it?
❯ uv run python main.py
Using CPython 3.13.5 interpreter at: /Users/reuven/.pyenv/versions/3.13.5/bin/python3.13
Creating virtual environment at: .venv
Traceback (most recent call last):
File "/Users/reuven/Desktop/myproj/main.py", line 1, in <module>
import requests
ModuleNotFoundError: No module named 'requests'As we can see, “requests” is not installed. But wait — we just saw that it’s installed on my system. Indeed, we got a response back from the program!
This is where anyone familiar with virtual environments will start to nod their head, saying, “Good! uv is ensuring that only packages installed in the virtual environment for this project will be available.”
And indeed, you can see that uv noticed a lack of a venv, and created one in a hidden subdirectory, “.venv”. So “uv run” doesn’t just run our program, it does so within the context of a virtual environment.
If you’re expecting us to start using “activate” and “pip install” within a venv, you’ll be sadly mistaken. That’s because uv wants to shield us from such things. Instead, we’ll add one or more files to pyproject.toml using “uv add”:
❯ uv add requestsHere’s what I get:
Resolved 6 packages in 42ms
Installed 5 packages in 13ms
+ certifi==2025.8.3
+ charset-normalizer==3.4.3
+ idna==3.10
+ requests==2.32.4
+ urllib3==2.5.0These packages were installed in .venv/lib/python3.13/site-packages, which is what we would expect in a virtual environment. But you can mostly ignore the .venv directory. That’s because the most important file is pyproject.toml, which we see has been changed via “uv add”:
[project]
name = "myproj"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.13"
dependencies = [
"requests>=2.32.4",
]We now have one dependency, requests with a version of at least 2.32.4.
In a traditional venv-based project, we would activate the venv, pip install, run, and then deactivate the venv. In the uv world, we use uv to add to our pyproject.toml and to run our program with “uv run”. In both cases, the venv is used, but that usage is mostly hidden from view.
But wait a second: It’s nice that we indicated what version of requests we need. But what about the packages that requests requires? Moreover, what if our program also requires NumPy, which has components that are compiled from C? How can we be sure that everyone who downloads this project and uses “uv run” is going to use precisely the same versions of the same packages?
The answer is another configuration file, called “uv.lock”. This file is written and maintained by uv, and shouldn’t ever be touched by us. It should, however, be committed to Git and distributed to everyone running the project. When you use “uv run”, uv checks “uv.lock” to ensure that all of the needed packages are installed, and that they are all compatible with one another. If it needs, it’ll download and install versions that are missing, too. And “uv.lock” includes the precise filenames that are needed for each package, for each supported architecture and version of Python — for the packages that we explicitly list as dependencies, and those on which the dependencies themselves rely.
If you adopt uv in the way it’s meant to be used, you thus end up with a workflow that’s less complex than what many Python developers have used before. When you need a package, you “uv add” it. When you want to run your program, you “uv run” it. And so long as you make sure to check “uv.lock” into Git, then anyone else downloading, installing, and running your program via “uv run” will be sure that all libraries are installed and compatible with one another.
July 27, 2025 , bY reuven
Python
I love conferences. I enjoy everything about them — the nonstop stream of learning, the chance to see old friends and meet new ones, and just generally to be around a lot of interesting, smart, and fun people. And yes, as a trainer, I also enjoy getting a chance to teach — which is fun and exciting for me to do, and allows me to share what I’ve learned with the general Python community. Plus, it gives people a chance to see what my teaching style is like, and thus (if they want) sign up for my LernerPython site and/or for corporate training.
Indeed, I just returned last week from Euro Python 2025, held in Prague. This was my seventh time attending Euro Python, my seventh time presenting, and my second time volunteering. Which means that I’m now in the “in” crowd — I know many people, I’m familiar with how the conference works, and I (sadly) have too little time to speak with the people I know.
But I remember all too well attending my first conferences, and feeling very different: I didn’t know anyone, wasn’t sure who to talk to (or about what, or where, or how), and generally felt a bit “out.” And even after I did meet people, it took me a while to figure out what I should spend time over the 3-4 days of a conference.
So, in no particular order, here are some thoughts about making the most out of a Python conference.
Page [tcb_pagination_current_page] of [tcb_pagination_total_pages]