Django Board Member Jeff Triplett joins us to discuss the results from the Django Survey, highlighting key trends, packages, and actionable ideas.
🔗 Links
📦 Projects
📚 Books
🎥 YouTube
This episode was brought to you by Buttondown, the easiest way to start, send, and grow your email newsletter. New customers can save 50% off their first year with Buttondown using the coupon code DJANGO.
William Vincent
Hello, welcome to another episode of Django chat podcast, vodcast actually on the Django web framework. I'm Will Vincent joined by Carlton Gibson. Hey Carlton. Hello Will. And we are very pleased to have Jeff Triplett, of the show back on to talk about the Django survey. Welcome Jeff. Thanks. Good to be back. Yes. Good to have you. Good to have you. So we're going to talk about, let me pull it up here. The, whoop, is it on? Yep.
the Django Developer Survey 2024 results. We're gonna go through this, talk about what it means for the past, present, and future of Django. But first, this episode sponsored by Hacksoft, your Django development partner, Beyond Code. We'll talk about them later in the show.
Before we get to the survey, Jeff, you just, we were both at Django con us and your former president of Daphna that runs Django cons. And I know you just had a recap. Is there anything you wanted to mention about Django con us and how it went for people who couldn't attend? Yeah, it was a wonderful year. think, if I was putting it overall, that 11 years I've been around, I'd say it was on par with like a San Diego experience. you could argue it was better because I think this is the first time, if you're not in the U S like sports.
It was magical because you had like three or four different professional sports. It's the one week of the year where everything overlaps. So people could go watch US football, Monday night football even, which is really rare to have. People were going to baseball games, the Cubs, women's professional basketball. The last game of the season was the same week. And so there were people taking boat tours. were people, Chicago Bears. I think what is the women's game? The sky maybe? Chicago sky seems like that's right.
There was just a lot of like interesting things going on outside of the conference to conference was great If you couldn't find, know, four or five talks that you really liked then You need to look inside Yeah, it wasn't us No, it was good. It was a really great venue. It was downtown Chicago, which made everything really accessible You could walk by the river. Most people don't realize Chicago has a river wouldn't swim in it, but it was
William Vincent (02:15.414)
It's pretty, pretty cool. People just did though, right? They just for the first time in like 100 years, they had a swim, I still wouldn't do it. But people did hop in and I don't think they were all, you know, getting sick after. keynotes were especially good. I think it kicked off a lot of interesting topics this year discussions that will go on outside the conference that you will be covering for months on your show, I suspect. And also, we will be back in Chicago next year, September 14, I think through the 18th.
And, definitely right now has a call for proposals. We can probably get out, which is going to be looking for where Django con us will be in 2027 and 2028. So I think that runs through mid January, but submit sooner than later. So it was good. Yeah. I mean, the only thing missing was Carlton from my experience, but you know, in a way, maybe that freed me up because it forced me outside of my comfort zone. So I ended up spending.
a little bit time with you, Jeff, a bunch of time with with Natalia and Jacob, the fellows and hallway tracking. I think the only thing I would say that is unavoidable with the space is it was on two floors. So there's a bit of up and down. But I think that also increased interactions. You'd run into people in the hallway or in the stairwell. And there was that really nice big facility upstairs where you could watch games and stuff after. So, yeah, I got to.
I got to hang out the facilities after a day or two. Yeah, it was a really weird layout to start with. But once you understood like elevators are hidden in places that weren't obvious. like it kind of took like the first couple of hours that you're there the first time you change from one room to another people pick up on it. Carlton it was like we were in a basement on the 14th level. And then the 15th level was like sunlight and very open. And you were like, middle of Chicago scene skyscrapers and stuff. It was really surreal to like
give a presentation and see like a huge building and the river beside you. yeah, that's kind of cool. Yeah, we and we feature there are a number of good recaps with photos of the conference. Maybe I'll put a couple of them in. Katie did one. I did one. I'm sorry, a bunch of people did ones that we'll link to. All right. Anyways, let's talk about the survey. So let me pull up the window.
William Vincent (04:35.118)
So Jeff, you're your current board member among other things. What's the board perspective on the survey? like how, I don't know, there any take, let me rephrase that. Were there any things that jumped out you as, oh, that was a surprising result in the survey? And then we'll get into the details. Hit me with a good one from the start. I can give one if you want. I think I've had some bias for a while about HTMX and kind of pushing people.
And so I'm in a unique position with DjangoCon US. I usually write like a blog post and say like, I would really like you to talk about these subjects. So HTMX and seeing that rise is confirms my bias to what I've been seeing as a consultant for the last four years. So I think there's also with surveys, you get people who like to fill out surveys. And I think that is also useful metric, but I view it from that lens of what do I see with clients and what do they want and what works well for them.
And so seeing that crowd either catch up or kind of confirm that is really useful for me. And I think for the board too, think what I don't know if you want to talk about now or later, I think there's going to be a push to maybe get the survey out early next year. And so we're going to get data that's a little more because right now a 2024 survey when it's almost 2026. want to catch up. Yeah, was end of think it was was November to January. But yes, definitely. You and I and
The PyCharm team have been working on this. plan is for sure to get out early next year and have the results in the survey, ideally by the summer. So I think that's very doable. yeah, it's worth mentioning it's all a little time lagged, the results here. Yeah, HGMX was really good. The C, I think there's a whole lot of like AI growth we're not going to see here yet because of that delay. Well, there's still some, we'll get to that. but more.
general experience level two of developers and seeing, know, who, again, who likes filling out surveys was, uh, was it 40, 4,500 people filled it out. that's almost overlaps with our Django news newsletter amount. But yeah, yeah. I mean, I'll just say something Carlton and then want your hot take. I mean, because here, here goes podcast bingo because I work at PyCharm. I also helped out and was involved with the Python survey.
William Vincent (06:59.916)
that JetBrains runs for the Python Software Foundation, the PSF. And so I took a lot of looks at that. And one of the striking things was over half of the respondents had less than two years of experience. So that one had 30,000 people respond, but it was pretty much polar opposites of responding. know, the Python survey, if anything, I felt was a little more towards people who, you know, who hadn't coded much.
and then this Django one, the biggest bucket by far was people with, think 13 plus years of experience. So there's some self-selection, but I think also it makes sense. Django is like, you don't jump to Django, you go to Python first and the Django community is. I would say has beginners, but a lot of experienced people like, I don't know, the three of us who I'm sure all filled out the survey. Go ahead, Carlton. Well, time and again, you hear people, why are you using Django? It's like, well, cause of the stability, cause long-term.
you know, long-term nature of my project and that's proven dividends over the years. We chose it and we stuck with it. And you know, these kinds of stories are the bread and butter of Django. so, yeah. No one gets fired for using Django, right? Well, and if you're on, if you're on the orange site, Hacker News, no one's, you know, like once or twice a year, it's like, Oh, Django is still there and great, but it's not, it doesn't get any of the buzz amongst, you know, college kids or whatever out there. Um, I think, I, yeah.
Just with the survey, like with the sampling, there's always going to be a sampling. So when you read the Python survey results, it's OK, take that 50 % and think, OK, that's an interesting tale on how the respondent base was skewed. Well, OK, it doesn't invalidate the survey at all, but you need to hold it in mind. And the same here, I think. We'll come on to the which version are you using question. And it's like, well, we need to.
We know that doesn't quite correspond to what the user base are using because we've got the PyPI download stats. you know, this is that this is a much more engaged than average responder base. Now that's okay, but we need to bear that in mind. Yeah. Well, maybe let's, let's finish up on HTML and Alpine JS. So for those who don't know Carson Gross, who's the creator of HTML gave the opening day keynote and Alpine JS, know, you don't have to use
William Vincent (09:15.106)
You don't have to use htmx with it, but often if you want to go to the next level to manage your state, you do. mean, one thing I think about is that a lot of Django people are small, medium shops in a way where it's really valuable that you can single-handedly do full stack. If you're at a huge company, you're sort of by definition going to be doing a single page application. And a lot of the time that's who writes the blog posts and people see online, you know, what's open AI doing. And, but that's not the reality for.
many developers. So I think it's also worth saying that Django skews towards, I mean, even at the conference, there were people from big companies there, but there's a lot of small medium consultants using Django to do really high scale websites, but with a minimal amount of developer time. So that's probably another reason why HTML is so valuable, right? I mean, if I was a professional react developer, I probably wouldn't be as excited about HTML as I am as a Django developer who's like, maybe I don't need react as much as I thought.
Yeah, no, I mean, I talked about this in my API, maybe talk from last year was that starting with HTML X and Alpine, I've been able to do things that pre two, three years ago, I would have been like, well, I need a front end developer as well. I need two teams. I need to build an API and I need to front end team to build on front of that. And I, I've hardly got a JSON response in the entire application two and a half, nearly three years in. It's like, it really has changed the world. and you know, I made the argument that
post zero interest rates, that gives us back a nice advantage in that we can make a business case for a much tighter approach in terms of financial well. And Jeff, the trend I've seen for a while too. Sorry, go ahead. Sorry, slight lag. I was just going to ask if clients ask you to use HTMX or you present it to them. We've got two trends. One is AI changes everything.
And so people do care about JSON right now and they will continue to the bulk of the clients I've had the last couple of years. They wanted to get out of like maybe they're smaller or they're bigger, but they want to move faster. They don't want to like have parallel, like why are you doing all the work with rest and then having other developers do all the work with JSON and or say like a react framework or JavaScript frameworks. So for them it was mostly like, what are our options? What is the size of this? Especially if they're dealing with like
William Vincent (11:41.102)
you know, their internal tools for their companies, that has a different user experience than here's a portal I'm going to use for managing my SaaS application. And so it kind of depends on how much bells and whistles that they want. So most of the time, they're just coming in and saying, what can you build for us? What's the timeline going to look like? And if I give them a like, yeah, sure, it'll be two months with React. I need a month or I need two weeks to do all the JSON APIs. I'm going to hand it to you and then your team's going to run for a month to do React.
and then bring it back to me. Or I can say, why don't I just do this with HTML and we just do this as a, and Carlton's Neapolitan is a great tool to use for these crowd apps. I can get it done two weeks. Which one would you take? Because it's significantly cheaper too. So most clients get it and they seek that out. And it just depends on team size too. know, bigger teams may have a whole fleet of react apps or react developers. We have one now that's doing that hundreds of models and
you know, we'll develop APIs for them and let them slice that data up the way they want it.
William Vincent (12:49.921)
Well, number two on our list, may we, and with apologies to Carlton, we're not turning into an AI podcast, but it was clear even a year ago, AI usage is growing. I believe the stats here, let me pull it up. Where are we with our stats?
AI usage. Oops, I should have had this ready. Yeah, and for people who didn't see the last little bit, HTMLX was on kind of a nice growth curve, maybe plateauing a little bit, and React's kind of dropping amongst usage. Yep, for sure.
Apologies, here we go. So this was the section, so on AI, and it led with which of the following tools have you ever used? Again, a year ago, almost, 69 % said ChatGPT, 34 % Co-Pilot, 15 % Claude, 9 % JetBrains, AI Assistant, and then Cursor. I would have to assume that all these numbers are gonna go up, and I would suspect Claude in particular is gonna go up.
Um, I don't know, Jeff, what do you make of this? I mean, actually, can we mention you're, you're, you're an AI influencer now you get flown out to the West coast to sign. Yeah. I don't even know what the hell that means. Um, yes. Uh, AI is we, you could, we could do a whole show on AI. So I'll try to keep it brief. Yeah. Um, AI is not going away. Um, people have feelings, which I respect about the bubble. Uh, we could get into that in a lot of detail at a different show.
I think AI is very good at writing Django code. And if you vibe code, because of the way Python code has been consumed, Django code, the documentation for Django lends itself to be something that if you like vibe coding or not, AI is very good at vibe coding Django apps. I think Django is very important to these companies as well. I've seen a couple of awards and I forget the names of them where there's coding competitions and they're saying, we won a gold medal for...
William Vincent (14:57.568)
are testing. And if you look at what they're testing and what they're doing, 42 % of the test results are coming from Django code and fixing Django bugs and problems with Django. And so even if these companies aren't like building applications with Django, they sure as well are like helping Django in contribution. Yeah. And I want to get there. That's part of what we're doing with the fundraising work group and the DSF now. But Django is heavily influencing AI, even if they're not building it with Django.
They're testing it and they're bragging about getting, you know, patting themselves on the back for these coding competitions that they're winning and saying how successful these are. So when you see that Anthropic or OpenAI says, we are doing very well. are 82 % with these programming, you know, this level, 42 % that is how well it's, it's dealing with bugs and what it's fixing the problems it's solving with Django. And so I think it's very significant to us and you know, try vibe coding sometime with a Django application. It is really good at it.
switch to another framework like FastAPI and it's okay at it, but there's just 20 some years of knowledge of Django and documentation and blog posts that's compiled in.
Carlton. I don't have too much to say. Yeah, everyone's using it. It seems handy. I don't have too much to add. OK. I mean, one thing I would, the only other thing I would add on this is, again, It seems that even as there's new models coming out all the time, so Sonnet 4.5 came out, I'm sure there'll be other ones.
The trend seems to be slowing. seem to be, really good, but they seem to be, you know, not these huge emergent leaps that we had and more and more tools, IDEs. So PyCharm, but all the other IDEs are giving users the option to select whatever model you want for chat or for agentic use. And that's pretty interesting in terms of maybe it's going to be a little more commoditized or maybe the pendulum swings towards users deciding. But I think most users are not, you know, you Jeff or even me.
William Vincent (17:05.483)
or even Carlton a little bit, like they just want something that works. And so the current encyclopedia of choices and changes is completely overwhelming. And I suspect we will get to a place where there's sort of defaults or can do things like scan your code base and say, Hey, you to use a local model? we, we think that this local model given your laptop is a good choice, you know, cause right now it is kind of crazy. It's like, it's like the everything store of models and
most people can't make heads or tails of it other than most of them are pretty good. Yeah. And I think like, if you look at how accelerated it's been, I know there's this, I'm not sure what your expectation level is, but like we've had two major anthropic model releases in the last like 60 days and each one has raised that bar by like two to 3%. And so if you look at how much we're gaining year over year, it's quite a bit.
But now that we're getting like within 80 some percent, meaning most problems you throw out of it can just solve and do. it's kind of hard to gauge, but we've also had like open AI has released a couple of big models in the last 60 days. Some of the like deep seek, two one or three one, I think it's two one. I've been playing with it. through the 600, the 600 billion parameter one. Yeah, it's, amazing. And so some of these models, it's, really getting to a good point. And so if you're just trying it out now, I think it's interesting.
What the survey misses though is a lot of the CLI tools, which I think is where AI is really good I I don't have a lot like using copilot and cursor in an IDE. I It just doesn't do it for me. But when you get to the CLI based apps I feel like those are really good and more effective And we will make this an AI podcast. Yeah, I'll just say the promise of you know, for example, PyCharm has Juni is that we can use analysis of the project that we have through the IDE to be more efficient with the
tokens and so you can have equal if not better performance and lower cost. I think that's what all the ID companies are going towards. That's what we're going towards. So there's something to that because Claude code and and Copilot, they're happy to just infinite tokens, infinite cost and not worry about all that. But people who use these heavily, you can easily spend $100, $200 a day if you're slamming a big code base. So I think that will decline. But anyways, I'm curious what the...
William Vincent (19:29.772)
survey we'll say next year on this for sure. So we touched upon Django developers being more experienced. Number four on our list and Carlton, you're on the Steering Council, Typehints. So there was again, survey respondents, but it wasn't even close in terms of response for Typehints. I know this is something the Steering Council has been talking about. What is there to update on that? Well, so again,
that the cohort is like a more engaged leading edge cohort. So an innovators leading edge type, early adopter type. So, okay, we need to take that with a grain of salt. But yes, there's lots of people using type hits. There's lots of people wanting to see type hints in play. The question is how? And so, it's something we're gonna talk about, we'll have talked about by the time this comes out at Django in the med.
going to get Simon Charette in the room who's got ideas about the ORM. And I've got ideas about types safe serialization. I don't know who else is going to be there. There must be approaches that we can take. But Django being Django, we're not just going to be able to whiz through, rewrite the ORM in some totally type safe way. It is.
dynamic Python at its best. And, you know, as it says in the MyPy doc somewhere, there are patterns, there are dynamic patterns in Python that are simply not expressible with Python's type system. so Django fits right into that description and, or Django as historically written and the ORM is the key bit, right? Is, you know, if you're in your view, how are you going to, how are you going to get type safe things out of it? That's the big challenge. And if we can,
we can add a type safe layer on top of the ORM, then that would feed into the model objects that you're consuming, not model objects, but that query layer objects that you're consuming in your views being type safe. And then, your views could start being type safe. You're like, OK, we could have the query parameters come in. Those given known types, could have any of these things we could start to introduce. But there's some hard questions to be answered first.
William Vincent (21:54.284)
And then with Django, it's a question of how do we get those into the code base? Because we've got the stability guarantees, we've got the API stability, we've got the long-term support policies. We can't just rip it up and start again.
Don't know. But I think it's an exciting time. And I think typing in Python has come on a long way from five or six years ago when the Steering Council then last looked at it. It's a lot better. And a lot of the rough edges have disappeared. And so I think I'm optimistic that we can make progress. And there's new types. mean, just this year, right, Astral put out Ty.
Jeff, you would know there's another, another one came out to Facebook, open out as well, I believe, or meta put out one. So it's, mean, the one thing I would say is I, I, and I don't think this is the direction people are saying is I just wouldn't want it to be required because one of the powers of Python is that, you know, you can ramp on, but we're not, if we turn it into Java and C plus plus, it's kind of not what Python is to me. So
The original peps here about typing, said that Python types will never become even by convention required, right? And it's that bit of the original peps have kind of not, they kind of are required. It has become conventionally the case that you do need type hints, but dynamic Python is still a valuable thing. But there are some core cases where you want to know
I mean, I know, take the, take the data types coming out of a form. So you go clean data and you get an untyped, totally untyped dictionary there and you get no help from your IDE and you get nothing. Whereas even if you've got a typed dick, dick out of clean data, so that the type checker could go, you know what? I was expecting a name field, not a new field. cause I mistyped it. Right. Well, but this is the concerns of an experienced developer and in a beginner, right. But yes, but if, if Django just gave you a typed it.
William Vincent (24:05.378)
typed state instead of an untyped app from say your form is one example. Then as a beginner, you would just get that type thing back and VS code everybody might be using. Well, it will tell you by default, hang on, there's a key error here because we're expecting you to use name not new. yes, it's a typo. And that can't be picked up without typing in place. Well, Jeff, you would say just Pydantic, right?
big on Pydantic? I like it. I think it is the next Django level framework for Python. And if you look at Pydantic AI, it's good for AI. I think data classes, I think there's a lot of built ins that are fine. There's probably three or four libraries out there competing specs, but Pydantic is the one that I like. I feel like it's optimized. It's just a nice developer experience. As far as typing goes, if you look at kind of this next generation of tools that are using typing by default,
they look very different than what we do with Django. Now, this isn't like raw or dinosaur, Django's old, but look at like the Python typing library. It really changes in typing. I don't like the name of it, but basically it's a way that you can use type hints on your Python application so that you can expose options and arguments to the command line. So you can write really good command line apps with it. So if you want to boolean, you don't have to figure out arg parse. You can just say, I want a verbose colon bool and give it a default.
And it will know, like when you run your application dash dash help, it will show you that, you know, you can do that gesture of votes. And this is true. You can use type hints with it in a way that feels very natural. You get all the benefits and you don't have to write code. makes you look at Python and go, why hasn't it always been like this? And so I kind of see the future and I see like we're in a good place if we can start there. Now trying to slap that on Django that's been around for 20 years, this is the raw dinosaur part. That's tough. And I agree with all the reasons Carlton is saying.
Whether this becomes a new layer or maybe somebody like there's the nano Django project, which is trying to make a, you know, like a more lightweight version of Django or Flask experience for Django. Maybe somebody comes up with something that utilizes types by default. We've seen this a little bit with Django Ninja and APIs, but I don't think they quite go into it enough. I see a world where somebody writes this and the pattern becomes more obvious. And then it's not like, crap, I got to support this for my IDE. So I get good.
William Vincent (26:31.662)
which is great. And it becomes more like I get all these great benefits because a query set can turn into JSON or can turn into Tommel and you get these side benefits for free because it's what typing lends you. So I like the developer experience, I guess it's my too long didn't read it.
William Vincent (26:52.568)
Fair enough. Yeah. Anyway, I agree with all of that. There's, think there's a lot going, there's a lot of possibilities here. and I think just from a, as a, a sort of steering council hat on perspective, it's, it's, it's come a long way in the last five or six years. And I think it's time to seriously have the discussion again about, okay, what does typing in Django look like or what could it look
Carlton, I think that's our lead into our mid role. Would you do the honors? Let me find it. Yes. Hacks off is your development partner beyond code from custom software development to consulting team augmentation or opening an office in Bulgaria. They're ready to take a Django project to the next level. Yes. Thanks for sponsoring hacks. So continuing onward databases. So I think no surprise Postgres and built-in ones are way in the lead. It's interesting that
Oracle's growing. It's small, but it's still growing. I anecdotally, don't that doesn't match with my experience, but you know, I have blinders on. I'm I just haven't heard anything about growth around Django and Oracle, but I guess it speaks to continuing to support Oracle as an official back end. I don't know if either of you have theories on on the bunk. I think this is our bubble. You know, I think that you've got real world users who use this.
who don't take surveys and we don't hear from as much. And so I think the growth was what, from 3 % to seven or So it's 7 % now. Yeah, it went from 2 % in 2021 and 2022 and then up to 6 % last year, 7 % this year. So that's, you know, it's 76 % for Postgres, 42 SQLite, 27 MySQL, MariaDB is nine, and then Oracle and then Mongo. So it's, you know, 7 % is for real. Yeah, no, definitely it's, I mean, definitely my bubble.
And I'm not sure what other frameworks support Oracle, but if you look at the PyPI stats on it, made up number, I feel like it was almost as many people use the Oracle driver as Django. I'm probably off by maybe half, maybe it's half as many people. It's a large number of people use the driver. I wish from a steering council or just, I wish there was a better way to defer what that means. I don't know if that's like if Django could support some level of saying, it, I'm not suggesting like we remove these database drivers.
William Vincent (29:18.87)
I wish there was a way to be able to measure that. PyPI seems to be one of the more accurate ways we have to measure that because there's ways that we can say like take CI stats out of it and let's just get real usage stats or what we as close to real as we can get. So like if anybody comes up with a clever way to be able to measure how many people actually have the Oracle driver installed with Django, same thing with MySQL, MariaDB, all of these would be just super useful even from like a board level. we kind of know, you know,
I would love to fundraise off of this information. So that's my little bugbear there is the fun. I'd love Oracle was just in the news the last week or so for being now the world's most valuable company or something or they tripled their value. I can't remember exactly what it was. The CEO was the richest because they're going to be doing allegedly all the OpenAI data centers. Yeah. Right. Okay. So that was where they got the news. But the thing is Oracle is a big company. It's used by a lot of
enterprises that using it. And I think it does Django well to have Oracle support as first class. I would love to, if we could somehow make it happen, I'd love to see us have Microsoft server and server support as well, or SQL server, you like to call it. I'd love to have that as built into Django because I think
It's a gateway for Django into these environments where there is a lot of money available. And then there's a second question about how we get some of that money. But I think it's important for Django, and I think it's good. I would be, personally, would be sad to see it taken out. think that would be a, I think from an open source and from a volunteer-only basis. There's all sorts of arguments as to why we might get rid of Oracle support. I think that would be an error for us. think long term, it's been a good thing for the framework.
we should find a way to keep it. I think a challenge we have to speaking with my board head on is our fundraising is something that we've added a third fellow this year and Django was unsupportable, was untenable to continue with two fellows or one and a half fellows. So we've had to raise that. There's been some criticism about the way that our fundraising page is laid out because it doesn't really emphasize that you're supporting the fellows.
William Vincent (31:39.434)
And so in the next couple of weeks, there should be some changes to that to help support companies because we say we want like Oracle and these companies to support us. We don't make an easy business case for them because we send them something and it says donation and donations going to help go to sprints and do things. And so I think we have to build a better business case for them. And that doesn't mean we won't still do these things. We'll support these things, but you know, like a sponsored fellow is just an easy win. I would love to see a sponsored fellow.
That doesn't mean somebody works for these companies. It just means we give them a way to actually pay something to get a business case off of it. Like if it takes nine months to review a pull request, I suspect we could figure out a way to make it not take nine months to review a pull request if a company is sponsoring. Doesn't mean they get any features that they want, but this is the kind of things we're working on from a board level because we want to be more realistic about how we get our funding. And, you know, thankfully the community has been beyond receptive and supported us for this long.
But I think we can also make a better business case that we can get a better level of more sustainable, sustainable level of funding. And I just think that's good for all of us. It's good for everybody. Good for the community. Can I just say, I think we're all wearing DjangoCon shirts. Carlton, you have an older one. Jeff and and I. You've got 24. 25. 25. Oh, sorry, 25. So this must be 24. Yeah, you have 24. Yeah, yeah. Sorry, I got my years.
I was going to just wear it, but it's fall here and it's getting chilly. So I put this on. the Durham Bowl on. So that was a good one. Yeah. Sorry. Okay. Well said. Third party packages. again, speaks to the, who responded. Django REST framework was the big one by far, but it was sort of the usual. Just go to, sorry to jump in there, but it is the big one. Like, so Jeff was talking about PyPI download statistics. Django is in
Sorry, REST Framework is installed in over half of all Django projects. So it's like more than 50 % of Django projects are using DRF. Yeah. At DjangoCon, I pointed this out too. And so people listening understand that a majority of people install Django through Django REST Framework than they do just doing a pip install Django or UV install Django. When I see clients, most of them have Django REST Framework in the requirements file.
William Vincent (34:00.994)
they do not have Django in their requirements file. It blows my mind when I see that. Yeah. So I just want to plug, there's a really great ecosystem page that the board and others put up. we'll put a link to it that links resources, you know, awesome Django repo that Jeff, you and I do Django packages, which you do, Jeff, band, Django commons, Django girls. I love that we have this page and I would love to see it.
a little more prominent and there is some work on the forum, some, some efforts around maybe doing something on the homepage, but you know, if I had a magic wand, I would want this page to be on the homepage in some capacity or just like, it's such a good page. And I know how much work went into curating this and I agree with all of it. think if people saw this as one of the first couple of things they see as part of Django, would help Django a lot. So can you show that on the vlog thing we're doing? I probably can.
I'll just do my little rant while you're looking for it. like, I, you know, I honestly believe that we can't scale Django's core bit. Like what Django, Django itself, you know, when you pip install Django, what you get, we can't scale that too much. We can't, we can add small features and we can, we should probably take some features out to create a bit more breathing space, but we don't need to. The ecosystem is big and large and it's there, but when you turn up at the Django site, you've got no idea that any of it exists. And so the goal was to try and give an inroads.
And this is just the first version. It's not as glamorous as it be and everything. But this was our steering council's take of like, you know, these are some of the highlights and lots of links to other resources so that you can find more. But the goal was that somebody could go through this and discover kind of the richness of the Django ecosystem. And I think if we can promote that as a community, this idea that, you know, somehow we're lagging or that we're static or that we're, you know,
whatever negative vibes might go around at times because Django is old, those could kind of disappear because actually the ecosystem is really vibrant. There's always new packages coming up and you folks do a good job of promoting them in the newsletter and whatnot. But if you're a newcomer to Django, how do you even find the newsletter? Well, the ecosystem page does at least mention it. For sure. I'm showing students some work too to get this bubbled up in search because that's the other problem is like there has to be some visibility.
William Vincent (36:26.668)
And people don't care who are outside of our circles. If they go to the website and they see search and they click on something, they just want to find that data. They don't care that, this is buried three levels deep. And so I really appreciate that Tim's doing this to try to bubble it up. Same thing happens with rest. You can do rest with Django, but you wouldn't know it from searching our documentation. And so I know part of that effort is the link to a couple of blog posts that show how to do rest with Django. And if you look at like Django's overall stats, which isn't captured here,
Python has grown a ton. Python is now the most popular programming language on the planet, and it's grown at least 26 % over last year, so it's significantly larger than everything else. Django's overall download stats have plateaued, and FastAPI, a year ago, was smaller than Django, and now it's 10 times larger than Django. Now, I don't think that we have to grow 10 % or 10 times, but I feel like we're missing out a little bit, and I think because of that information that it already exists, we know about it.
we need to do a better job of telling people and showing in the search, or maybe if somebody's listening and wanted to do a really good rest how-to, there's a how-to section in the docs. We show people how to do CSV files and generate it and consume it, think maybe, but we don't tell people how to do rest. That how-to would be a very, very important page to help people make a decision because they're going to FastAPI and then they hit us up at conferences and say, how do I use the Django ORM with FastAPI? Which is absurd, absolutely absurd to my core.
that that is a thing. hear that all the time. Yeah. Yeah, we can totally get there. And I bet you in a year Django would grow a lot. We don't have to focus on growth. I just don't want us to stay at a point when Python is going all these other web frameworks are going. And Django is actually better at doing a lot of the applications that people are trying to build with it.
William Vincent (38:17.39)
We're all vested in the Django ecosystem, but I think we could make the case quite well that for a lot of use cases, Django is a better choice than other things. Why? Well, I'm in good for building the other things around your website other than just the rest of the endpoints. But being able to build rest endpoints and consumer APIs and all those other things, those are core use cases for the web. Django needs to have a good case for supporting. It's a batteries included.
I wanna quote that very large font so big that it doesn't fit into the screen. so that's, All right, let's get through the last couple here. So latest version of Django. So people said they were on overwhelmingly on the latest version of Django, which it's nice to see, know, we Django fellows and the community put a lot of effort into the longterm.
releases guaranteeing around three years. So those are the point two, so 5.2 and then 6.0, 6.1, 6.2 will also have long-term support. I feel like that's, if I had to pick one area of the survey, was like, oh, I don't know if, know, 70, 80 % around the latest version, that would be the one that jumps out at me. For me, that's the tell that the, the, the, the, the responder base is the very most vested in the, in the community is, um, we know from again, from the PI,
PI downloads that any given time, depending on where we are in the release cycle, between 50 and 70 % of downloads are for a supported version of Django. And that drops. That will drop now because we've just released, or 6.0 is in pre-release now. When 6.0 goes final and we finally drop support for Django 4.2, suddenly we'll drop.
down and it's only then that people start upgrading and they get to 5.2 and then they hang and we just about get onto that by the time the next LTS goes that goes out of date and they drop off again and it goes down and back up again. No way are 82 80 however many percent on on the latest version. Yeah, so I didn't need to base and Jeff there's a quote from you here but yeah, so it's 75 % said they're on the latest stable release 21 % on the LTS and 3 % on the other.
William Vincent (40:37.698)
So, yeah. Next, just for next year, how often do you upgrade Django projects? I'd like to ask two questions there. One is like, do you upgrade to, you know, to the latest major release or do you hang around on the LTS? That's kind of, that's one question. And then the second is each month when the point, when the little point releases come out, do you upgrade those like all the time or every few months or when there's a security release or, know, to get an idea of how quickly people are jumping on the point releases as well. That would be a nice.
differentiation. I bet this is mostly tooling led to where people add Django to a project and they're just not upper bound pinning anymore because I don't think they get bit as much as they used to like they get warnings. And so I suspect that's part of it because when you know after six is out six one's going to have a few warnings. But like with the LTS cycle in general, we're letting people know ahead of time. I just think the barrier there isn't as high as it used to be and people are probably lazy like myself.
And they use CI and CI catches so much of this. So that would be my theory. So I mean, as when I was a fellow, was a big thing that we always thought about was, you know, maintaining this stability policy and not introducing breaking change and making the upgrades easy. Because when I started as a fellow, the narrative was, oh God, it's a pain to update Django and I'm still on 1.3 ho ho ho chuckle because, you know, and it was like a kind of badge of honor as to who was on the most outdated version.
And five years later, by the time I stopped being a fellow, it was like, no, no, everybody should be on a supported version. And the kind of the mindset had shifted. And I think that's a good thing. And I think that makes it easier to bring the community with us. think Python's been really helpful too, because I think they're stable releases and less change from year to year. My only critique of them is I really wish we would get out of, I know, so Python was
three point something knowing that Pi was going to happen at some point. And so the 314 release is why they've doubled down for years and said there would never be, it would never jump the four, never jump to something else. There was a CalDAB spec for a while and that proposal gets thrown around every once in It's called a PEP and there's a PEP where they've tried to decide like, should we rename Python to be like Python 25? Because that's when Python 25 will be. The answer to that is no, they're not going to for the foreseeable future.
William Vincent (43:00.226)
But I would love to see if this trend continues, it'd be really amazing to say, what version of Django are you running? And say, I'm running Django 26 or Django 27. And that name, that value has meaning and a release date would be amazing to get to that.
We talked about that in the latest episode a little bit. yes, speaking to Carlton's language. I'd quite like something like that. I haven't seen yet the kind of the one that gets it, I see every time we get to a 6.0, I see people commenting on the various comment places. Oh, but this isn't a major release. It's just the same as the last one. It's kind of like there's no difference between.
6.0 versus it could have been 5.3 just as meaningfully. And then it doesn't, I can't remember without looking when was 2.2 released and any idea? No idea. I'd have to go and search through the archives. How out of date exactly am I when I, when I see that project? don't know. can't. Yeah. Tied to the actual year. Sounds, sounds nice. Maybe, maybe we go to an annual release cycle then instead of eight months though. I don't know. That would be, think that's the point that would be, yeah, more contentious, but.
I would love to see it because I LTS is stable as Django is we can start to make that like, here's the cycle we support two or three years and it's just always rolling. that's again, I'd love it. I'd love it if you just yeah, exactly. If you know, Django 22 is like, oh yeah, 2020 to. if anyone out there has got like the clear idea of it do suggest it because I don't think there's too much resistant to a possible change, but no one's yet suggested like the, you know, oh yes, that makes total sense. Okay.
Testing, let's, so PyTest reigns supreme at 39 % followed by unit test at 33%, then PyTest Django, which the package to do it 30%, coverage 21%. And then Django test plus at 12%, that's a RevSys package. Now, Jeff, you're the PyTest person in this conversation. I don't use it much, if at all. Carlton, I believe you're also PyTest light in your.
William Vincent (45:13.826)
Or maybe. Yeah, I'm coming round to it because of playwright, to be honest, but I still write, I still write kind of unit test style things. Even if I'm using the PyTest runner, I'll still do my arrange act assert kind of formula within the test because I've worked on big projects and what happens.
for me is the fixtures just go missing in action. I'm like, we're spending ages trying to track down the fixtures. So I like to the scope of the fixtures very close to where they're being used. So I still write tests in that style, even if I'm using PyTest. But yeah, I see that it's very popular. Can't quite work out how Python itself could adopt it or how Django could adopt it. We've got a custom test runner and move to PyTest would be a big project.
If you only use PyTest to run Django tests, even if you're not fully embracing it, I think it's a better developer experience. I can't speak for how you test code with the Django, Django's itself. And the other trend that I see, I think I mentioned on your show before, is that people who swear by class-based views seem to really like PyTest like myself. And then people who like function-based tests really like class-based unit test style tests.
yeah, Jango test plus is just a wrapper. It's just convenient features. It works with unit tests. It works with a pie test. it works with both. I like pie test a lot. I think, well, I think what Carlton tried to say too is, pie test fixtures are like a friend of me in mine. I hate them. I hated them for a long time, but I love them and I use them a lot.
trying to figure out where you can expose fixtures so that they make sense to people because it just looks like here's this argument passed to a function. What the hell is this? Where does it come from? And that's something that just has a weird UX. Once you embrace it and you use it, whether you define your fixtures inside the same test file, if you've got a config file, you put them in, that's next to your tests. You just have to kind of know where to look. Django does this in a few ways too with things like signals and how do I know what a model's file is? Like where does this?
William Vincent (47:25.634)
If you're starting from scratch and Python, trying to figure out like Django does some things that aren't obvious either. And so I just kind of like embrace that by learning Django. So PyTest I'm like, where the hell are fixtures at? Cool. You can declare and you can put them where you want them to be. It's kind of what it falls down to, but they're so powerful. That's just code hygiene. same as always. If you put your code in silly places, you're going to have a trouble finding it later. Exactly. I just find that I can write better tests with less code using PyTest and fixtures.
And I like that function based style personally. You could tab it over and put class in front of it if you want to. You don't really need to with it is where I'm at. here's a question. And I think it's about Python and PyTest, but I think it reflects on Django and the ecosystem and the third party package story versus in core the discussion that we're always having in Django is if you do look at the Python survey, who's using PyTest? Well, it's like almost everybody and all the major packages use PyTest and all the
kind of headline Python developers that I follow and I really respect their judgment. right, PyTest is the bee's knees. But PyTest isn't part of the Python standard library. And it's like Python's number one testing framework or recommended test framework really doesn't come bundled with the language. Well, every other language out where the test framework comes bundled with the language, why not Python? And so you ask that question, the answer is, well, we can develop it more quickly and it's, you
It's easy to iterate and the trouble with the standard library is everything gets stuck and there's yearly releases and that's the only update cadence. And everyone's happy with that story in the Python land. But then we come back to Django and say, no, everything's got to be in core. Hang on, which is it?
I think it's the fundamentals of what Python is, and it's good that Python has some opinions about how to test. And I suspect someday PyTest would maybe come into, or some pieces of it are gonna go into the language because that's gonna make it easier and faster for it to support. If what you're alluding to is like a rest story, I think that when you think of using a web framework, if you pulled, and maybe that needs to be the question, like what should a web framework be?
William Vincent (49:36.184)
half of people are gonna say it's REST, half are gonna say it should be able to do HTML templates. There's probably people who've used DRF for 10 years that don't even know why Django has a template engine. And I think they would be wrong. I don't wanna see Django turned into Flask where it doesn't have any opinions because it's so hard to debug and it's so much harder to like write tests and try to figure that out. So I like your question. think it's, PyTest has moved at an accelerated rate, but I think we have to figure out like,
What are we as a web framework and what batteries do we need? I don't think the answer is remove all batteries. think it's remove the batteries people don't use, but we should be open to adding batteries that people need. What could be contentious here is go look at the Laravel community. They've added, if you go to Laravel repo on GitHub, you can see that there's a slash MPC, MCP, slash MCP, which is the restful way AI agents can wrap REST API calls.
And so they are already supporting that now. They also have Breeze, which Breeze is their way to call Laravel code interact with the Laravel application using MCP. And so I look at this and I go, in five years, would Django support this at the project level, the repo level on GitHub? And that I struggle with that because I think we should, I think we should allow those experiments to go. I do like the path that you're talking about where third party packages have to prove themselves.
I just feel like the industry is moving at a different rate than what we're used to. And that means we're going to miss a little bit. And I do think that it's fine to take some bets. I wouldn't mind seeing, like, it's been a while. Like Adrian had dated browse or data view or something a long time ago. And that was kind of like, let's, let's add this level of viewing the Django database and getting data. It's almost like Neapolitan, but I think it was more data CSV related. Simon's got a package SQL.
dashboard or some Django SQL dashboard or Django SQL Explorer, which is very much like this. You can just sort of dig around from the admin. I, and I think data browse was bundled in like Adrian, one of the last, I'm not making up history here. remember Adrian said, here's this package. I'm going to add the Django. It's really useful and it didn't work out and he removed it. And I think that's fine to have these tests that we run. could be that maybe it's Django dash experimental or just slash experimental becomes that, but
William Vincent (52:01.516)
I would love to see us try to swing and, you know, try for a home run, try something that's new. Cause I think these things are very relevant to the industry. Stuff like MCP, some people listen to podcasts who are going to say, that's a bubble. We shouldn't support that. I'm just looking at this is stuff that other frameworks are doing. I don't see where this would ever fit into how JNOS cadence currently works, but I think we should allow this space for people to make experiments. And sometimes it works. Sometimes it doesn't work.
If you look at like South and Andrew Godwin worked on this for a long time, that was a really rough path to get into Django. And at the end of the day, it worked out beautifully. But I hope that it doesn't take somebody 10 years to get something like MCP or get something that is valuable to the community and other frameworks already adopted. I don't think we have to look and do everything other frameworks do, but I would like to see us be more aware of what was working in Laravel.
what is working in Rails, what's working in FastAPI and have those conversations. Yeah, no, mean, I, my, my agreement there is with you is all about the experimentation and all about the enabling the experimentation. My, kind of take on that is that we enable that through promoting, external packages rather than trying to bundle everything in core. think that
The answer I get from the Python devs about why PyTest won't be merged into the standard library is because it shouldn't be there. In fact, you've got your core thing, which goes slowly, and then you've got your things around it, which go at a much faster pace. And I think we as a community can go at a much faster pace if we promote what's out, you know, the third party story, the external package story, even if some of those are under the ajangle umbrella, whatever that means, you know, officially promoted.
I think that's also code for the Python process to get changes in is more than what they want to do. And I totally respect that. They should be able to run the project as they want. I suspect there's a time when development slows down and it's pretty stable. And it is stable, but I suspect it gets to the point where it's less effort and easier to maintain if it goes into Python. And maybe it never does, but that's my guess.
William Vincent (54:12.024)
So last one is looking ahead, what should we, what should Django include in the survey next year? And I'll just give a shout out. If you're watching this on YouTube, you can put this in the comments that will see it and also it'll help boost the vodcast. But I would say UV obviously should be in there and it will be in there asking around packaging. AI thinking about how we ask how people are actually using AI.
And I do think there's too many questions. So I'd like to see fewer questions. I know that's, I think it's a general consensus consensus around trying to make it not take so long. But as I've mentioned to the, the PyCharm team who also works on the Python survey, like this survey is really important to Django. This is the only real way other than vibes and hallway track and maybe Django in the med that we have a sense of what the community is doing. So I do, I'm proud to see what the survey has become.
I guess is what I would say. No, it's super. And again, you know, I've said this about the Python study, but congratulations to JetBrains for the effort that goes into it because they don't have to stump up every year. It's a lot of work. It's a lot of work that they do. I we have to, you know, acknowledge that.
Yeah, and honestly, one of the big reasons I joined JetBrains is because I was on the board when the survey started and worked with them on this and also the promotion. yeah, they're good citizens with that. Jeff, anything I didn't mention that you'd really like to see next year on here? You and I have spent months looking at data and like thinking about it. I'm inclined to wonder if we could just put up like a GitHub repo or something.
and get feedback on the actual questions and just see if it would be useful. maybe let the community kind of help with it. Also, like I wouldn't mind some more like long-term questions just to let people like, are we missing? And, know, maybe get some that are less like check the box because it's so hard with overlap of like, what's your favorite third party package? What's your favorite testing? And there tends to be this overlap between the two and we're only capturing what we know. And so I don't know how to fix that other than like,
William Vincent (56:22.168)
let's get more people telling us like, these are tools we also use that should be in the survey and maybe get a bad format for that. But at least it's an easier loop than just a big Google Doc we share. Yeah, the data team at JetBrains, they're able to parse out and analyze long form for thousands of respondents. So that's a good point. Should do that. We're coming to the end of the show. Our new thing, projects and books. I can start.
Projects I'm gonna plug in virons, which I think Jeff you also like this is a way to do environment variables in Django I think Django dash environment is probably the most popular one. There's a couple other ones I personally like environs because it's relatively lightweight you can in brackets when you install it Put Django in there and then it gives you Django database URL a couple other things I just like it. I have nothing against Django environment. I'd use either but personally I like environs and I've messaged a couple times with the
maintainer who's been doing it for a long, long time. I don't know if everyone's using, I know everyone's not using environments, so I'll just give it a plug. think it's very solid. Okay. Either of you. I'll go cause I'm on the notes on the second. so I'm going to plug, at wing desktop. So, it's this new app that was just announced today and I've downloaded. we spell that? A T U I N. right. And it's, a years ago,
this tool called Atwin came out and it's a fancy shell history. Now you both know me, you know I don't adopt new tools. I'll try everything out, but I don't adopt basically anything. I think you're AI in fact, this can't be the Bill Carlton because. Yeah, no, this is my avatar that I put on for the show today. But I tried Atwin, I try everything, but I adopt very few things onto my final workflow. And Atwin is the shell history that I gave it a go and I'm like, yes, this is just great. And I have it set up.
So that in my projects, up arrow is like a project, local history search, then command control R is like global history search. And it's just phenomenal. You haven't told me about this before, Carlton. I was just not come up. I little just hadn't quite got around to. I have been standing it a little bit on Mastodon. anyway, they've released this desktop tool, which the plug is Runbooks that Run. So it looks a little, and I've downloaded it, it looks good. And I'm only plugging it because
William Vincent (58:46.862)
I'm so impressed with their existing project. And it looks a bit like say a Jupyter notebook, but it's specifically tasked to shell integration. It's got SSH integration. It got Kubernetes monitoring sort of going on it. And it's for kind of like run books for kind of ops, ops, ops notes. But instead of having them in a note file and copying them across your shell, you just click run and it's there. And so it's up to date and it's documented, it's coders configuration and coders documentation.
And it looks sweet. So I'm plugging it for that. Both Attoine, the Shell history client is wonderful. Give it a try. But also Attoine Desktops, their new thing. And it's all open source. And I think it's built with Rust and Tauri, which is like the electron thing. Anyway, that one.
Here it is, shells all the way down. They get points for marketing for that phrase.
All right, Jeff. Nice. yeah, you had me at rest on that one. Andrew Miller's Django prod server is, I love, this is one of those spaces where people are trying to make the deployment and the whole production story better. This to me is very night and day eye opening because it allows you to add this third party package. You can add it to Django. It gives you a dev server and it gives you a prod server.
I feel like we set people up and say, it's really easy to develop something with Django. Go read this documentation on deployment, which is awful. And it's not that the Django docs are awful. It's the Python's deployment story is awful. And I love seeing this because you can install it. You can choose Gunicorn or choose whatever you want to. And it mostly just works by default. And it gives you the right level of switches that you can dial in and tune. That way you can get a, you know,
William Vincent (01:00:35.384)
people are going to have opinions about what should live in their configs. Rightfully so. But this is a much easier story for somebody who's new. It also creates a dev server, which does what you think. I believe it's also like, I think prod server also like, turns off debug. And I think there's a couple of switches that flips for you as well. I would love, love, love to see this grow into something because it creates like third party hooks too. So you can plug in gun corn. You can plug in other, you can plug in tasks even.
So Django Q2 works in task libraries and it's creating like an architecture, which I would love to see inside of Django because it's not pulling all these third party libraries in. It just creating like a framework and hooks so that you can add an easier story for putting in your Django application in production. So, And this is very much like the Django way, Is you create an interface, an API that people can implement and then, you know, we might.
Django would normally provide a default implementation, if you want a different implementation, you just swap it in. So database backends, cache backends, email backends, storage backends. Yeah, it's all pluggable. Same idea here. And I think that would be a lovely addition. So I'm excited to see how it evolves over the next cycle.
All right, last bit, books. I'll be quick. So I'm actually, why machines learn. I haven't finished it, but I'm working on it. It doesn't shy away from the math behind LLMs and AI in history, but really well written, really nice balance of, again, it goes into the math. It doesn't shy away from it, but it's mainly text. So.
Continuing my threat of trying to wrap my head around AI this year but I think one of the things it mentions right off the bat is Yeah, there's math and there's linear algebra and matrices and a little bit calculus and stuff and probability but it's not it's not overwhelming math like he gives the analogy early on of What's his name? Illya? One of the founders at open AI who as an undergraduate University of Toronto was studying math and physics and went to Jeffrey Hinton and said hey Like what's up with neural nets?
William Vincent (01:02:50.006)
and was given a bunch of papers, and then came back and said, well, this math is so simple. How could there be something deep in here? And that's kind of one of the points is that the underlying, why he and Sutskiver, think, Ilya Sutskiver, was like, maybe this is the path, is because the math, it's not math for math's sake. The underlying math is like, there's some stuff there, but it's not string theory or anything like that. So anyways, I'm enjoying it.
I've sat on it for a little while, but I'm finally dipping into it and maybe I'll have more to say. But I mean, right, like the fifth page, it's showing some like matrix multiplication. So it's very much a, it's not like a pop culture, popular physics book with no equations. It's like, it's got equations in it, but it doesn't have homework. So I'm enjoying it.
Okay, I'll go. I'm gonna continue my vein of tech books, Linux at the Command Line by Daniel Barrett. This is like basically it's a bash book. It's how to use your shell, but it's great. So there's the old ones as things like the real staple holds like learning bash and classic shell scripting and the bash cookbook from whenever. And they're all wonderful, but this is...
It's got some good moves in it. There's a good chapter on like 11. It's not a thousand pages either. No, it's really quite thin. I learned lots of things about manipulating history, about launching sub processes, about arguments, substitution. It's a great read. You know, if you just want to refine your shell skills, I really recommend it. Efficient Linux.
William Vincent
Jeff, do have one? I didn't bring the physical book, but all of Jesse Seema's books, pronounce they, them are amazing books. If you don't mind showing that on the, yeah, yeah, let me pull it up. I'm challenging you on this. Like, no, I got it. Vlog world. We're in now. their books are amazing. my kids' favorites. There's a lot of unicorns. There is a Netflix series, right? Yes. Of the Netflix.
And this is a partner to John Bonifato, who is the vice chair going to be chair of PyCon US for the next couple of years. Also PyGotham, a lot of people know them from. If you go back to book page, top link. Do you have a specific recommendation? This one? They're all good. The Narwhal one's good. You got a little unicorn pony that thinks it's a Narwhal, lives under the sea with its family. Like what's not to love about that? I just see lots of Django pony love when I see the books. They're really good from like an adult perspective. Some of them are really get you thinking.
They're just they're presented very well brilliant illustrator really good stories. Love seeing them have like a YouTube Series that I think season 3 is out soon and just a small part of the Python community. I love seeing like This whole thing is great. So Thanks. No kids a new book just came out a couple weeks ago. I Like that link there Good good good. All right. Lastly we'll say this episode is sponsored by hacks off your Django development
Partner Beyond Code, and you can learn about their services in the description below. And Thanks everyone for listening. Jeff, thank you for coming on. It's always a pleasure to do this. And we'll see everyone next time. See you next time. All right, bye bye.