Brian is a software engineer, podcaster, and author. We discuss recent tooling changes in Python, using AI effectively, inverting the traditional testing pyramid, and more.
🔗 Links
🎥 YouTube
This episode is brought to you by Six Feet Up, the Python, Django, and AI experts who solve hard software problems. Whether it’s scaling an application, deriving insights from data, or getting results from AI, Six Feet Up helps you move forward faster.
See what’s possible at sixfeetup.com.
Will (00:00)
Hi, welcome to another episode of Django Chat. I'm Will Vincent joined by Carlton Gibson. Hey Carlton.
Carlton (00:05)
Hello Will, hello.
Will (00:07)
And we're very pleased to have Brian Ocken back on the show. Welcome Brian.
Brian (00:11)
Hey, welcome back. mean, I'm glad to be back.
Carlton (00:13)
Yeah, no, no, no, you host Brian. That's brilliant.
Will (00:16)
Yeah.
So for those that don't know, Brian hosts two different ⁓ podcasts and books, courses, we're going to get into all of it. But I'm really excited to lean on you, Brian, to find out about the broader Python ecosystem. So maybe I'll lead with that open-ended question. What do you see in 2026 in Python? Again, you sit much broader perch than we do.
Brian (00:38)
Okay, well, this is probably not going to be surprises. So we in 2024, we got UV came out and I can't believe it's only been that long. It just seems like that's the world now. And probably you guys, but definitely Michael and I and a lot of early adopters grabbed ahold of it. I probably not right away. I played with it right away, but I'm using UV even professionally, like in a corporate setting.
Probably the start of 2025, but by the end of 2025, I'm seeing like my whole company is like interested in it. So I do see I think I see see more corporations just and and corporate settings Using the UV tooling because it just makes sense I see that
Will (01:25)
Well, you don't know Carlton that
well then.
Carlton (01:28)
Tell us about the corporate setting because I don't work in what I would call a corporate setting so it's important to prefix any discussion of my my choices with that but Brian wait you tell us about your day job
Brian (01:39)
Well, okay. So day job, I'm well, I actually changed over the last year, but it's fun now. It's always been fun, but I work for, ⁓ I work for a road and Schwartz. It's a, ⁓ test and measurement. well, they do a lot of stuff, but I'm in the test and measurement side. And, so that's like electronic test equipment. And most of my career has been in cellular and, ⁓ and wireless and wifi test equipment. ⁓ and.
Carlton (01:46)
Good recovery there.
Will (01:48)
Ha
ha ha.
Brian (02:10)
These are fun boxes, but they're very complex instruments. the, ⁓ what am I going at? ⁓ a lot of the tooling around it, I think there might be some Python inside some of the boxes, but not the ones that I know of, that I work with. But we do a lot, like we do the testing with Python, do, and a lot of the utilities and all the day-to-day stuff, there's a lot of stuff that needs done and we use Python. ⁓
And because of that, we try to, you know, maintain best practices and ⁓ try to not jump on too many bandwagons, like because we could be changing directions too quickly. ⁓ But ⁓ UV just seems like a direction there. because of this, the time savings, mean, saving time is faster. But I also see that like actually the corporate pickup of
new stuff is happening faster than like say, five, 10 years ago. It used to take, it used to take like a year or two or more, you know, or even a few years for the best practices to really reach corporations because they kind of move slower. But, but I've seen that rapid, that uptick go quicker. So anyway, please.
Carlton (03:15)
if you could.
Have you got a little bit
theory as to what caused that? What's changed in the world such that corporations are able to move faster?
Brian (03:40)
I think Python Bites brings a lot of...
Carlton (03:42)
Ooh, good, good, I like it.
Will (03:43)
A lot of credibility
or information?
Brian (03:48)
I think a little of both. think it's a ⁓ common credibility and information, but also I actually, you know, it's as awful as it is. think AI is bringing a lot because, you know, there's, there's a lot of people that like to just do their job and don't they, they use what they learned in college or something and don't, don't pick up a lot of new stuff. ⁓ But, ⁓ and there's, you know, I was always reading blogs.
and listen to podcasts and stuff, but some people don't do that. And so the people that just sort of now they're they're asking chat bots and the chat bots are paying attention to stuff. So, ⁓ you know, the the the fear I get though is there's less and less of us blogging about it because there's no money in it anymore. yeah, I don't know where the new information is going to come from. So.
Carlton (04:46)
It's
going to come from the slop output. So they'll be feeding themselves their own product.
Will (04:50)
Well, now I feel like you're tempting me
because I've been on a little bit of a bugaboo about model collapse. Are you familiar with that term in the academic papers around that? I mean, yeah, basically you train on AI slop and it just degrades and becomes the variance shrinks so much. So there was an Oxford paper, 2024, showing both training it and the maths behind it that in the absence of other things, the models get worse over time.
Brian (04:58)
I can guess.
Will (05:18)
So then there's the argument of, okay, so we know that's the case. Maybe somehow the training gets better. Maybe synthetic data is better than we think it is. Maybe at scale, those things don't apply. mean, nobody knows, but I mean exactly in the same boat, right? Like I could plug in things and the LM will spit out something I wrote or you wrote if we prompt it correctly, but like the search is dead. The business model is dead. I don't feel any imperative to create that content nor do many other people. So.
How can they autocomplete the next word when they're training on worse and worse data? I don't know.
Brian (05:55)
Maybe we go back to books. don't know. ⁓
Will (05:58)
Well, with books,
I mean, don't get me
started on book. you know, like Amazon, like some big percentage of it is just AI generated stuff there too. So, I mean, I half wonder if the snapshot of like mid 2022 internet is like this canonical corpus. And then we like fill in recent things, but we rely on that corpus of largely human content for the variants that we need.
Brian (06:22)
I
just I I think I just I have to be positive and I I have optimism in the creativity of people and We'll come up with ways to spread creative people's ideas regardless of the the global Averager that is AI So
Will (06:42)
Yeah. Well,
I like our previous guest, Farhan, who's younger, we talking about AI usage, and he was mentioning how for him, he was making the distinction between people who love computer science and love to learn with AI are just super powered, but people who got a CS degree more for economic reasons or less for the love are less inspired to use AI and to keep up. But you just said maybe something of the opposite. Maybe it's actually easier for people who aren't quite as in love with it to keep up with AI.
Brian (07:06)
Maybe it's actually easier for people who aren't quite as in love with it. If you didn't love coding,
why would you get a CS degree? I just.
Will (07:14)
Money.
Carlton (07:16)
Well, you might fall out of love with it during the course of getting the CS degree as well.
Brian (07:17)
I don't buy it.
Maybe.
Will (07:25)
I mean, like three,
four years ago, it was like, you want six figures and you don't want to be a doctor? Like coding is the only game in town. And also if you're
Brian (07:33)
Okay. Well, maybe, maybe
it's okay to get rid of those people. Uh, but, uh, but I think that there's, mean, there's, there's, you gotta find your passion somewhere. I don't know. I, I, I couldn't work a job where I didn't enjoy it. Um, I really enjoy what I do. So, uh, I don't know. Uh, but the, and I think that like I'm writing a book, right? We're going to talk about that later, but I'm not doing it to get money. Cause like that's.
Will (07:36)
Okay.
Brian (08:00)
That's like if I wanted a few extra dollars, I could just go work at McDonald's up the street for a side job. I guess that'd be more cost effective than, ⁓ than writing a book right now. but, but I'm going to do it anyway. But anyway, ⁓ I don't need to transition into that anymore, but the one thing I do while we're talking about AI, I want to say, I think that, one of the neat things is that, ⁓ people code is using.
AI code assistants can go back to some of the old school good processes of come up with some ideas, generate a plan for how we're going to do that, generate a few designs, look at alternative solutions. Should we use that database or a different database? Should we use that front end or a different front end? Come up, bounce around those ideas and what are the trade-offs and why, and then iteratively build it up and put in some
Carlton (08:40)
Yeah.
Brian (08:58)
a top level API level testing for the system and build it up. That's what we thought good practices were, but it was too expensive. a lot of a lot of, you know, scrum houses and stuff and, and, and agile, it was agile slop that was churning out garbage. And I think it's cool that we can maybe do the old school good practices, but we can do it faster. doesn't take months anymore. takes.
days or weeks to go through that whole cycle.
Carlton (09:31)
This for me is definitely one of the things that have come out of the new LLMs and that is people are now actually keen to write the specs that you've been asking them to write for, you know, so can we have feature X? What do you mean by feature X? So how dare you ask me, let's just implement it was the sort of attitude before. Whereas now it's like, no, I will, I will write it out. Not because I'm going to implement it because I'm going to feed it to a machine, but at least it's like, yes, explain what you're after before you talk to the keyboard. That's progress.
Brian (10:00)
Exactly. But since it was so cheap to build the spec, we're not tied to it. the past, one of the big mistakes was the spec was golden and we can't touch it. And now we can go, oh, well, we're like 10 days into it and it sort of seems like a dumb idea now. Let's change direction. And we didn't do that before. We would just be like, well, we spent like two months rewriting this thing. We're going to have to build it now.
I think that we're actually getting the agility part of Agile, I guess, maybe.
Anyway, optimistic.
Carlton (10:42)
Good, good, good, good, good.
Brian (10:44)
And I'm having fun still ⁓ Yeah, you know what that's some sounds smug though as one of the what? People working software that stills a job. I I think that I think I'm still having fun. That's good. So ⁓
Will (11:02)
Well, we are.
mean, it's why we do this. I think step back from the like uncertainty. Like it's a really interesting time, right? Like with all the AI stuff and it's nice to kind of know a little bit, a little bit about what you're doing and then see how AI fits in for work. And I don't know for me, like I work at an IDE company, we're still sorting it out. I see lots. I mean, it's, more interesting than even I thought it would be without AI more, more tumultuous, but more interesting.
Brian (11:30)
Now, one of the things I just, I actually heard this from a video clip from Ben Affleck, and I don't have a link. I just saw it on social media somewhere. He was talking about AI ⁓ and having it be an averager. Like it turns out garbage, but it's average garbage. And if you are, if you're, if you're new at something, like if I was going to write some CSS average is fine for me because I'm a, ⁓ yeah.
Carlton (11:57)
Yeah, that's a basic level. ⁓
Brian (11:59)
⁓
So if I can have the AI bot generate average, that's way better than I can do by myself. So ⁓ for skills that I don't have, I'm going to lean on it. And maybe that's okay. ⁓ Yeah. And especially for projects that don't have a budget to hire experts in every field, why not? ⁓ So I don't know where I was going with that. ⁓
Carlton (12:26)
just a general
AI rambling that we have each week now.
Will (12:30)
Yeah. Well, let's yeah. Good.
Brian (12:30)
Yeah. But, ⁓ okay, one more thing is we talked about the podcast a little bit. ⁓ I started blogging about code and podcasting and writing, not because I wanted to, I mean, the little extra money is nice, but that is what I was burning out in CS and, and in coding and that involvement in the community is what turned it around. And I,
And I still do it not because I'm still making money. I'm doing it because it's keeping me from burning out. that's, yeah.
Carlton (13:06)
keeps a connection, it can be quite
isolated just sat at home behind your computer or sat at work at your computer.
Brian (13:13)
Exactly. And also I'm passionate about crap and a lot of the people I work with are not. And that is if you're in a setting where you really think you really want to love what you're doing, but you're not working with anybody that has any sort of, ⁓ like a heated feelings about it, then you gotta find the people that do so that you can talk with them. So anyway,
Will (13:36)
Definitely.
We talked about books. Can we talk about lean test-driven development?
Brian (13:41)
Yeah. So the book project I'm working on is LeanTDD and it is actually inspired by a lot of the AI stuff. I'm going to probably throw in some AI in there. There's no mention of AI in it right now, but I've got the first draft done. So Lean Test-Driven Development. I was way back in the early 2000s. A few books really helped me out. Pragmatic Programmer.
and then there was a book called lean software development and ⁓ And that was that was great those two those two books are great Especially for lean the lean software development especially the first actually the introduction the introduction is all you need to read it But like covers everything Yeah It no it's pretty beefy but that's the sort of the thing in the book industry is like your ideas only like 40 pages now you're gonna have to make it bigger and
Carlton (14:25)
rest of it.
Will (14:26)
I mean,
it's a lean book, right?
Brian (14:38)
they put, there's a bunch of stuff in the back that I don't, maybe it works for some people, maybe it doesn't. And to be fair, they said that they said the principles are what you need to know. The practices that we're going to fill out the last two thirds of the book are our interpretation of how you could fulfill the principles. So fair enough. And I like those, but I wanted to take that. So one of the, one of the things that lean gives you is an idea of how to analyze processes for waste and waste being
anything that doesn't directly add value to your customer. Not waste is in garbage, but waste is in like, like tests. I think all tests are waste, which is going to take a lot of people off. But that's true. Does a customer really care how you're testing? I don't know. Um, but think of it as like, what if you doubled it? If I doubled the number of tests, it's if the product's already perfect and I spent $10,000 more on testing, do you want me to? And they're like, no.
it's already good. So ⁓ incremental value sort of a thing. ⁓ Whereas like an extra feature value, ⁓ an extra test, if it doesn't test anything I care about not value. So anyway,
Carlton (15:50)
I'm chafing at the bit there, Brian. I've got to interrupt. I'm chafing at the bit because like, if I buy, you know, if I buy a product and two products that look identical on the shelf, but one has come from a ⁓ reputable fabric of Reptile Factory, who's got quality control and all those things, it's going to be more reliable. It's going to be, it's going to last longer. It's going to be something I can put my trust in and rely on. Whereas the thing that was put together in a sloppy manner is probably going to break within, you know.
Brian (15:52)
Are you?
Yes.
Carlton (16:18)
a small period of time and it'll break at a crucial moment. And software testing is that kind of quality control, right? It improves, it gives you a better product in that sense. So why is the customer might...
Brian (16:29)
Yes.
Yes. Those things, those qualities that you said that that's gonna it's not gonna break the things that you advertise is doing. It's actually gonna do those things. That's the actual value. How we get there is we put in place testing. ⁓ So I guess what I'm saying is like the we used to say it's cheaper just to have people manually test stuff than to automate it. Now the cycles are so fast that we can't rely on that.
because I want to be able to change a feature and ship it today. ⁓ So we have to have automated tests, but it isn't the automated tests that's the value. It's the value that those tests create, I guess. It looks like management activities. Like that's one of the things that Lean Software Development throws in there. And I think it's hilarious is all management activities waste. It's like, well, and I... ⁓
Carlton (17:22)
Developers
of the world unite.
Brian (17:27)
I was a manager for 10 years and I got, mean, there's a lot of activity that we do that is just dumb, but that's not what it's talking about. It's talking about that. There's, there's essential work that you have to be done. I guess think about it in a silly example. I'm going to cut circles out of a piece of paper. If I slow down and, like do the circles really close together, I can reduce the number of wasted paper so I can get the most circles out of a piece of paper.
but I have to slow down to do it. So is it worth it? You have to do trade-offs. Do I slow down or do I speed up? And there's either wasted time or wasted paper, and you have to do those trade-offs. And that's where testing and a lot of other stuff comes in.
Carlton (18:11)
almost everything, right?
Brian (18:13)
Yeah, there's trade-offs everywhere. really what I did is I'm using all those lean principles and focusing on the test-driven development process and looking at where the value comes from. And I think the real value in a lot of automated tests are in the customer-facing tests. The does this feature actually do what I want it to do? Those are valuable tests. So those are the ones we keep. The unit test, does it do the thing that the developer wanted it to do?
Only if the customer cares about it if it's just that ⁓ a developer thinks that a unit should do this because they're gonna reuse the Something on a new product less valuable those sorts of things so
Will (18:58)
But still
value, right? I got to push back slightly, right? Because there's also the value to the developer, right? Like, I don't feel comfortable hopping into a new code base with no tests, right? And I'm sure you're talking about this, right? There's some, but we can't have infinite tests, but like, I want to have some tests, even if the customer never sees them, just so I can move faster without breaking stuff inadvertently all the time.
Brian (19:07)
Well done.
I mean, that's what I mean. I spend my day half more or more than half my day writing tests. so I do find the value in tests, but it's the higher level ones. think, ⁓ the API level tests and the component level tests are way more valuable than, ⁓ do my getters and setters work for instance.
Will (19:39)
I think you've seen a
lot of time spent on unit tests. Like that's what I'm picking up, which is fair, right? Like maybe wasted time.
Brian (19:45)
Well,
I think I'm swinging the other direction because the test pyramid did so much damage. ⁓ Because the test pyramid said, gave the unit developers the permission to focus on unit tests and the rest of the pyramid is somebody else's problem. ⁓ And in most companies, there's nobody else to take the rest of the problem. ⁓
There's no dedicated QA team anymore. ⁓ There's who's going to write the component tests. It's a bunch of people building, trying to build houses with very thoroughly tested nails and pieces of wood and nobody to make sure that the house is to spec. And that's just the truth of it. And that's where we see, like we still see a lot of people focusing too much on does my little widget work? And I'm not, and I,
And there's, I write a lot of unit tests too, but it's focused ones of like this algorithmic bit that's confusing. Let's throw tests around it to make sure that it always works the way we think it does. Or if we're gonna throw a corner case in because we need it, or there's a bug fix, put a test around it so that nobody looks at it and goes, this is a weird algorithmic bit in the middle here that it'd be a lot faster if we took that out.
But if there's a reason for it there, throw a test around it so that it doesn't break later. So.
Carlton (21:16)
I use
unit tests as scaffolding for while I'm developing code quite often. So I'll have a rough idea of what I need to build and I'll have broken it down into logical steps. And I need a test for step one and okay, I've got step one's passing, I've got step one built. And that test remains useful while I'm building step two and step three and step four all the way to the end. But once I've built the feature and I've got a test around the whole feature, like an integration test around the whole feature,
It's questionable whether I need to maintain those unit tests or, and sometimes they can become a barrier because later on you want to come back and refactor that implementation. And you're kind of scared to because you've got all these tests that you're going to throw in a way. It's hang on, but they were just there for scaffolding while I was building it. They're not really, they're not adding the value as you're saying.
Brian (22:04)
Well, that's where the the rule of thumb is keep tests that test behavior, throw away tests that test implementation. ⁓ Because the scaffolding around your implementation doesn't help you if you try to dig. ⁓ So that like a lot of the thing with test server development was red, green refactor, but is the unit test again in the way of refactoring. ⁓ So if a unit test, if the behavior stays working and your unit test breaks, then it's the
Carlton (22:10)
Yeah, brilliant.
Yeah, exactly.
Brian (22:33)
The problem is you've got a unit test that shouldn't be there. ⁓ So that and there's I've seen too many projects not change things because they don't want to change a bunch of unit tests. And that's.
Carlton (22:46)
Yeah. Yeah, exactly.
Oh, we can't change that. tests will break. Yeah. No, no, no, no, no, no, no. Yeah. Okay. Good. So I've got what to let's tie back to the AI question because I think test driven development. So almost comes back into its own. If you've got a, you know, Claude code or a co-pilot CLI or a Gemini CLI or whatever your favorite one is, because you need something, you need the agent that's doing its thing to have some way of knowing if it's, if it's successful and without tests.
Brian (23:14)
Exactly.
Carlton (23:14)
it's just
gonna eyeball it and the last thing you want to trust is an LLM eyeballing it.
Brian (23:18)
So you want tests that you're actually willing to review. just like you'd have it, like maybe you'd work with Claude to come up with your ⁓ design plan. You'd review it to make sure that you agree with it, what it's gonna do before you build it. Same with your tests. If you're not willing to review the tests, then you shouldn't have the AI build it. ⁓ And I think at the high-level API level test is where we...
I'm, I'm willing to review those tests to make sure that the product I'm building actually does the thing I want it to. But if it's got some weird funky implementation down at the bottom, I'm not going to review the unit tests for that. ⁓ so, ⁓ I wouldn't even know what to review. And that's, that's the, that's the hard part as well, even with people, like not just, not just AI stuff, but people, if you're, if you're, how do you review somebody else's unit tests?
⁓ Whereas you can review the API level test pretty easy. You can go, yeah, that's testing the behavior of our system. Whereas lower level component, lower level stuff is harder to review somebody else's project, I guess.
Carlton (24:30)
Reading code, reading tests so that you understand them, so that you can give them a proper review. That's hard work, right? It's the first thing to acknowledge is this is not going to be easy. You're not going to get, you're not going to glance at the tests, suddenly understand them and be able to say where they work or not. You've got to go through them and really, well.
Brian (24:46)
Well, hopefully. I mean,
like you should try to get, you should write readable tests and if you're gonna have somebody else or some other bot write it, they need to be readable tests.
Carlton (24:57)
Yeah, okay. I think that's a nice thing to aim for,
Will (25:03)
If we can, I'll go ahead.
Brian (25:03)
And that
ties back to the first question, is what I do from a job. Right now I'm in a role to try to make sure all of the system level tests are at a highly readable level so that everybody in the project can read them.
Will (25:21)
Did I, feel like when I asked, I started off asking about Python ecosystem and 2024, you mentioned UV. Did we talk about 2025 and 2026? Did we get those in or did you have other things you wanted to mention there?
Brian (25:30)
⁓
Just I think we're going to see the bigger shift of just more people. Everybody's shifting to UV, whereas NPIP will be the corner case, even in corporation settings. then I think 2025 was the year of people ⁓ shared vibe coding. And I think 2026 is people actually using it as an assistant to make developers ⁓ do the right thing.
Maybe or or
Will (26:01)
Yeah, and maybe we'll
see how the business model holds up too.
Brian (26:06)
Yeah, well, ⁓ I have no idea about that one. That one just seems crazy. I don't, I don't know how you have a company valued so largely, so large that isn't making enough money to cover its bills. That's whatever. Not my problem, I guess.
Will (26:19)
Well, mean, to put
my jet brain's hat on and think about what I can say publicly, I think there was a sense of a lot of companies were like, we're going to build tools on top of LLMs and we're going to make money in, you know, extra money. Whereas now the sense is no, just to like keep, to be competitive, we have to integrate AI, but we have our existing business model. It's not that AI is like another chunk of revenue. It's just a necessary piece of the puzzle of our offering.
Brian (26:49)
Well, if you're already charging every developer on the planet $20 a month, and some of them $200 a month, how do you make more money? I don't know.
Will (27:00)
ads. That's the joke that was going around, right? Like they finally got AGI generate income.
Brian (27:04)
Yeah.
I'm gonna put ads in your code that I generate. By the way, check out Pepsi. ⁓ No thanks.
Carlton (27:17)
You're
a coke-man,
Will (27:21)
I'm going back to the memory, oh Carlton, you look like you wanted to say something.
Carlton (27:24)
Well, no, I mean, I was just going to ask about the... because Lean TDD is your new book, but we should talk about the old book. I was thinking to myself, we should talk about the second edition. But and then I thought that was just last year. And then I looked and it was actually 2022. And I was like, wow, how has it been three years since the second edition of... ⁓ OK, four years now coming up.
Will (27:43)
Four years.
Brian (27:45)
Okay, has it been
Will (27:47)
3,
Brian (27:47)
four years?
Will (27:47)
4, 3. Well, 2026. That depends how you count, but.
Brian (27:50)
Okay.
So that's Python testing with PyTest is what we're talking about. ⁓ it's actually still doing okay. It's down probably with the rest of the industry as far as sales go. But I keep up on it and I keep getting questions. So one of the great things about, ⁓ guess, I don't know, was it last year? Maybe it was last year or a year before. ⁓ Anyway.
⁓ I think it was 2024 where I went through the whole book and did the course. So there's a, the complete pie test course, just I walk through the entire thing and it there's a lot because it's, it's, it's a book. ⁓ it's not a big book, but to, go to walk through everything is takes a while.
Carlton (28:23)
Yes.
There's quite
a lot in it. you know, the first couple of chapters fly by easy, but then it's like, this goes on. There's more. There's depth. It's a substantial poem.
Brian (28:41)
⁓
and, I think I did a decent job that, ⁓ especially with the second edition of, of keeping it to things that are going to stay relevant even in future additions. So, I think the book is still valuable now. The, the, I, I am, I don't, I don't know if I'll do a third edition. The only problem right now isn't the content of how to use pie test. The problem right now is that the project that I used there, it was
It uses dependencies. So those dependencies are out of date and I have to go, I should go back and update the project to with the new updates from the dependencies that that'd probably be the, if I, if I were to do a third edition, the main thing I would do is take out the dependencies in the project and just, just do it, ⁓ not have any dependencies so that I don't, I have complete control over it and it'll always work. It just do stuff like that.
Carlton (29:40)
I see Will
nodding in the background there, he's sort of wincing, nodding.
Will (29:43)
I'm just, yeah,
I'm not, I feel your pain.
Brian (29:47)
And the dependencies are like not big deals. Like I use what? I use a database layer. It's just a silly, it's like mini DB or I can't even remember what I used. Tiny DB, that's it. And it's like Mongo, but like small scale. So it's a single file document database. And actually it's kind of fun if you're using it.
but it's got an old version in there. And ⁓ if I would redo it, I'd probably just go with like, what's that? The built-in SQLite. Yeah, I'd probably just have SQLite, because that's always going to be supported. ⁓ then I wasn't, I used like, I think I used Click in the first edition and then Typer for the CLI interface. And ⁓ again, both of those are great projects, but they're dependencies. So I'd probably just reimplement it in.
Will (30:26)
SQL 8.
Brian (30:48)
and whatever, yeah, ARCBARS, that's it. And I'm also better at, I mean, I'm better at testing with ARCBARS applications right now than I was when I did the second edition, so. ⁓ But I still, it was a good idea to write that book, and I'm glad that a lot of people have gotten value from it, so.
Carlton (31:15)
Yeah, it's
an absolute cornerstone, I think. You think through the classic works, the fluent pythons and things, and the PyTest book is going to be on there.
Will (31:25)
Well, you don't
have competition, which means you nailed it and we know it's not a small area. That's always the thing. like, it a tiny pond or am I a big fish? It's a bit of both, I'd say.
Brian (31:31)
Well, they're actually
One of the core developers did write a competing book ⁓ and that you don't remember it is a good sign for me. So.
Carlton (31:46)
You've seen them all.
Will (31:49)
Well, so let's see, we're coming up a little bit on time. I want to mention projects and books, but I want to get your hot take on what do you see as the Python web framework space? Because you're not a biased insider, you know? So there's Django, there's Fast, there's Flask, there's newer things. What do you make? Well, I'm still curious what you think. What do you make of what's going on?
Brian (32:07)
I think I'm too much of an outsider. think.
Well, like that. Okay. I have a project that's that's that I'm a side project that's using Django. ⁓ and so I'm hope I'm glad that Django staying is keeping up to date. And I, I actually think Django is a safe bet now. ⁓ it just looks like you don't have, it's kind you don't have to defend yourself if you're going to say, I'm going to use Django or fast API. ⁓ everything else I think you'd have to defend yourself as to why you were using, using that. ⁓ but that's just it.
⁓ I think it's interesting that Michael's rewriting a bunch of his stuff in court instead of something else. ⁓
Will (32:51)
Yeah, I mean, yeah,
I've talked to him about that.
Carlton (32:55)
Michael's
like the academic, he's got the free rein to do what interests him.
Brian (33:01)
Yeah.
Will (33:02)
PhD is Carlton, right? PhD has gone wild. This is a problem.
Carlton (33:05)
Yeah,
something like that.
Will (33:08)
Should we mention... sorry, go ahead.
Brian (33:09)
⁓
But I'm I'm nobody should take my advice for me because I'm not really a web developer so
Carlton (33:16)
I do want to ask how is your Django project going? Because last time you came on the show, you just started and you were like, still exploring your way in Django and that was a little while ago. So you found your feet and all happy.
Brian (33:21)
It's
no, no, no, it's still in the concept phase. ⁓ So ⁓ it's a perpetual concept project. But, ⁓
Carlton (33:34)
like a Pink
Will (33:35)
Well,
you could spec it out with AI and get going.
Carlton (33:35)
Floyd album.
Brian (33:37)
That's
the plan to get some help.
Will (33:40)
I mean, Django is great for it, right?
That's the thing I always have to remember with my blinders of Python Django, like that's as good as AI gets because it's so well-documented. Both are so well-documented, right? Some other fringe language or framework, like you're not going to get as good results.
Brian (33:54)
It's kind of like the book. So the LeanTD book is the book I've been wanting to write for 20 years. And so I'm finally doing it so that it's out of my head and it can, it's living rent free and it needs to pay its own way. And this side project that I want to do is the same sort of thing. It's a project I've wanted to do for probably 10 years. And I want to get it done so that it, and it just, doesn't have to make me a ton of money, but if
I need to either see that it sinks or swims and by swimming it just has to pay its own hosting fees. Yeah, exactly. And $20 a year for like, or whatever for its URL renewal. And that's about it. But yeah, I'm a newbie there. Yeah, we are running short on time. What do we do next?
Will (34:29)
posting costs. ⁓
Carlton (34:30)
Yeah.
Will (34:47)
well, so we we've gotten the habit of mentioning project in a book, which we sprung on you last minute. So Carlton, I are happy to go. if you feel inspired, ⁓ I'll start. So projects. I'm going to shout out Django packages dot org, which is not a new project that Jeff Triplett has taken over. But he just ⁓ re redesigned the whole thing. So this is like the best place to go if you want to search through the thousands of Django third party packages. And so the new redesign is really nice. He used a he's talking to he's talked about it.
Brian (35:12)
Nice.
Will (35:17)
Definitely check it out. Give it a new look. Carlton, you have one.
Carlton (35:22)
Okay, so the package I want to talk about is called Django MessageSpecField. So it's a JSON field subclass that uses the MessageSpec serialization tool or library to impose schemas and validation on the data you store in a JSON field. And what I like about it, there's several of these packages out there that using different options. What I like is it's another example of people in the Django community jumping onto these newer serialization options rather than just rest framework serializers.
forever and a day. So there's a Pydantic version, now it's a MessySpec version. And I think the more people in the Django community start using these things, the more they'll go, wow, this is actually a step up from what we're used to. So Django MessySpec field is my recommendation.
Will (36:07)
Well, you're used to doing, yeah, recommending things. Do you have something top of mind?
Brian (36:08)
I guess.
Well,
one of things I've been using a lot lately is kind of an old tool ⁓ is from ⁓ Ruff. ⁓ So it's another Astral tool. But the ⁓ check stuff is amazing. we like, I mean, we like linters in software ⁓ to check stuff. And linters really are just ⁓ static analysis tools.
Will (36:21)
Yeah, I was going to ask you about that actually.
Brian (36:38)
⁓ So static analysis tools are very powerful as a starting point before you even run things to test them. But the rough checks are amazingly thorough. It's not just ⁓ simple things like, if you use the variable or you have an import that you're not using, it'll check for that. But there's so many checks. So you should go check out the rules at ⁓ Astral for the rough rules.
And there's a lot of stuff you can turn on. There's Bugbear. even, I've been using a PyTest, ⁓ Flake8 PyTest extension that you can turn, you can just turn it on with Rough Check. ⁓ It's already built in. It's amazing. even if you've played with Rough before, go check it out. It keeps getting better.
Carlton (37:24)
Okay.
Will (37:31)
Books. Carlton, do you want to go first on books?
Carlton (37:32)
Yeah, I'll go
first. So I'm going to recommend the Python Polars, the definitive guide. So Polars is like a data frame library, a like pandas, right? But it's Polars. Yeah, it's the new hotness. So it's written in Rust and it's got Python bindings around it. And it's got an expressive lazy API and all sorts of things. And so it's worth investigating. Pandas has got a new version coming out and pandas is not by any means done and dusted, but Polars is, you know, another thing in that space. And it's a good book. ⁓
Will (37:42)
It's the new hotness, yeah.
Carlton (38:03)
It introduces everything very well and it's going to live on my desk for a long time now because it's got a very good reference section and kind of as you dig in, it explains the kind of methods and then you can keep it on the desk to dig into the details as you need them as you're using them. So Python Polar is the definitive.
Will (38:21)
Okay, I will mention not a programming book, but relevant, is How to Hide an Empire, which I actually read several years ago and I'm rereading. So it's a history of the greater United States. So without getting too political, the US has a long history of acting like an empire. And this book dives into that and talks about disabusing common myths that Americans tell ourselves about what we're doing. And it's timely, unfortunately.
Really well written, and I don't say that lightly. I'm a super snob with writing, and this is excellent, so strongly recommend it.
Brian (39:01)
Okay, another timely book and I am getting political ⁓ is the Little Brother series. ⁓ There's a series called that starts with Little Brother by Cory Doctorow. And it's an excellent series that ⁓ yeah, talks about a hypothetical world in America that just sort of looks predictive. I listened to the series on audio book and it was excellent.
Carlton (39:29)
So Little Brother must be a play on the idea of Big Brother, right?
Brian (39:32)
Yeah. ⁓
the other, and it's, it's a targeted towards CS people. like, or like, there's a lot of programmer that the heroes are all programmers, which is cool. Yeah. ⁓ another one, that I just, sorry, we're only just supposed to do one, but, my daughter had to, had to read a book. She's having to read a book for, ⁓ for English.
Will (39:43)
As it should be, right?
Carlton (39:44)
Good luck. Good luck.
No, you can do is you can keep going.
Brian (40:00)
called There There by Tommy Orange. And I listened to the audio book for that and it was phenomenally, ⁓ it was very hard. There's a lot of, it's not an easy thing to get through because it's talking about ⁓ the way we've treated the native population in America, ⁓ but from their perspective kind of, ⁓ yeah. But it's very relevant as well and I highly
Will (40:03)
yeah, yeah, yeah.
Brian (40:30)
recommend it.
Will (40:33)
I've heard great
things about that. It's on my list, so I'll have to push it up.
Brian (40:37)
Yeah, those are my recommendations.
Will (40:41)
Any as we go out or any things you want to mention we didn't ask you about you want to shout out I mean, of course people I think will have links to all your various projects podcasts and books, but anything else
Brian (40:53)
One of the, I just, reminder for people to have fun. ⁓ I assume people got into software to have fun and not just to make money. So I think just find out what you're still having fun with and double down on that.
Carlton (41:07)
Yeah, there's a lot in that. That's great advice.
Will (41:11)
Well, thank you for taking the time. Thank you for waking up early to accommodate our schedule. It's very early for you. ⁓ Yeah, yeah. Well, same. Carlton's done. He's going to go make dinner. Yeah.
Brian (41:17)
Yeah, now I get to go to work.
Carlton (41:20)
Well, hyper efficient day.
Brian (41:25)
So where, okay, quickly, where's everybody from? I can't remember.
Carlton (41:29)
Well, I'm from Britain, but I'm based in Spain. I'm, you know, quite a few hours in front. It's getting dark now and it's been dark all day because the weather's miserable.
Brian (41:32)
right, yeah.
Okay.
And I'm in Oregon and where's he, where are you at?
Will (41:39)
Yep, I'm
based in Boston, but I'm from Vermont. Big difference.
Brian (41:44)
Okay, but you're in Boston now. I love Boston.
Will (41:46)
Yeah.
Yeah, yeah, I like Boston. It's not Vermont, but as US cities goes, it's where I've decided to hang my hat. So.
Brian (41:54)
Actually, I-
Carlton (41:54)
I'm gonna get
you a t-shirt, Will. It's not for Mon.
Brian (41:59)
To be clear, I tried to see Boston and I couldn't find a parking spot, so I had to move on.
Will (42:04)
yeah, well, it's the most European of American cities, so you shouldn't have a car. You gotta walk.
Brian (42:11)
That's what I was told afterwards. They're like, why did you try to take a dark car into Boston? That's, that's just dumb.
Will (42:15)
Yeah, and Boston drivers,
it's like the aggressiveness of New York with a Byzantine one way streets that are not laid out in a grid. if you just see Boston through drivers, you're not going to like it.
Brian (42:28)
Yeah, well, I'm from the West Coast and the weather you can't you can't get anywhere without a car over here. So.
Will (42:34)
Yeah, yeah, try it again without
a car. think it's very, you can walk the whole city in a day. Carlton came to visit. We walked a lot of it, so.
Brian (42:40)
Well, I also want to thank you guys for keeping this up. I really enjoy the Django chat podcast and it was, it was, I always miss it when it's on a hiatus. So.
Carlton (42:40)
Yeah, it's very nice.
It's just over the summer, know, we have to keep our energy up.
Will (42:51)
Thank you.
Yes. Yeah. Well, again, thank you for coming on. are DjangoChat.com. We are on our YouTube channel and we'll see everyone next time. Bye bye.
Brian (42:55)
I appreciate it and I understand that.
All right, bye.
Carlton (43:05)
See you next time.
Bye bye.