Transcript: Django Survey 2025 - Jeff Triplett

More on their services later in the show.

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, friend of the show,

back on to talk about the Django survey. Welcome, Jeff.

So we're going to talk about, let me pull it up here, the Django Developer Survey 2024 results.

We're going to go through this, talk about what it means for the past, present, and future of Django.

But first, this episode is 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, we were both at DjangoCon US and you're former president of Defna that runs DjangoCons. And I know you just had a recap. Is there anything you want to mention about DjangoCon US and how it went for people who couldn't attend?

So people could go watch U.S. 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.

There were people, the Bears, 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 too.

Conference was great.

If you couldn't find, you know, four or five talks that you really liked, then you need to look inside.

Yeah, clearly 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 pretty, pretty cool.

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.

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 the show, I suspect.

And also, we will be back in Chicago next year, September 14th, I think through the 18th.

And Defno right now has a call for proposals we can probably get out, which is going to be looking for where DjangoCon US will be in 2027 and 2028. So I think that runs through mid-January, but submit sooner than later. So it was good.

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 gotta, I gotta hang out the facilities after a day or two.

in places that weren't obvious uh but 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 uh 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 seeing skyscrapers and stuff it was really surreal

to like give a presentation and see like a huge building in the river beside you so yeah that

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.

what's the board perspective on on the survey is like how i don't know were there any take let me

rephrase that were there any things that jumped out jumped out at you as oh that was a surprising

result in the survey and then we'll get into the details um who hit me with a good one from the

pushing people and so i'm in a unique position with django con us i usually write like a blog

post and say, I would really like you to talk about these subjects. So HTMX and seeing that

rise 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 a 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 is really useful for me and i think for the board too um i 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 uh we want yeah well it was yeah it was end of i think it

team have been working on this the plan is for sure to get out early next year and have the

results in the survey ideally by the summer so i i think that's very doable so yeah it's worth

yeah worth mentioning it's all a little time lagged the results here yeah htmx was really good

of that delay well there's still some we'll get to that yeah but the uh general experience level

two of developers and seeing, you know,

again, who likes filling out surveys.

Well, it was

So that's almost overlapped

with our Django news

newsletter amount. But

yeah, I mean,

I'll just say something, Carlton,

and then your hot take. I mean,

because here

goes podcast bingo. Because I work at

PyCharm, I also helped out and was involved

with the Python survey 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. You 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, I 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

using django it's like well because of the stability because long-term but you know long-term

nature of my project and that's proven dividends over the years we chose it and we start with it

you know these kind of stories are the bread and butter of Django and so yeah no one gets fired

no one's you know like once or twice a year it's like oh Django's 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

So, you know, when you read the Python surgery results, it's okay, take that 50% and think, okay, that's an interesting sort of tale on how the respondent base was skewed.

Well, okay, it doesn't invalidate the survey tool, but you need to hold it in mind.

And the same here, I think, we'll come on to the, you know, which version are you using question.

And it's like, well, we know that doesn't quite correspond to what the wider user base are using because we've got the PyPI download stats.

And, you know, this is a much more engaged than average responder base.

Now, that's okay, but we need to bear that in mind.

Well, maybe let's finish up on HTMX and Alpine.js.

So for those who don't know, Carson Gross, who's the creator of HTMX, gave the opening day keynote.

And Alpine.js, you know, 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.

I 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 OpenAI doing.

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 HTMX is so valuable, right? I mean, if I was a professional React developer, I probably wouldn't be as excited about HTMX as I am as a Django developer, who's like, oh, maybe I don't need React as much as I thought.

starting with htmx 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 a 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 um and you know i made the argument that post zero

interest rates you know that gives that gives us back to a nice advantage in that you know we can

make a business case for a much tighter approach in terms of financial well and jeff the trend i've

clients ask you about to use htmx or you present it to them um we've got two trends uh one is ai

the bulk of the clients i've had for the last couple 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

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 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 HTMX

and we just do this as a...

And Carlton's Neapolitan is a great tool

to use for these crud apps.

I can get it done in 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.

You 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.

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.

HTMX was on kind of a nice growth curve,

maybe going a little bit,

and React's kind of dropping amongst usage.

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?

You know, again, a year ago, almost 69% said ChatGPT, 34% Copilot, 15% Claude, 9% JetBrains, AI Assistant, and then Cursor. I would have to assume that all these numbers are going to go up and I would suspect Claude in particular is going to go up. I don't know, Jeff, what do you make of this? I mean, actually, can we mention you're an AI influencer now. You get flown out to the West Coast to sign NDAs.

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 in a

different show um i think it's ai is very good at writing django code and if you vibe code because

of the way python code's been consumed django code the documentation for django lends itself to be

something that if you whether 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 our

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, we are 82% with these

programming, you know, this level, 42% of that is how well 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 by coding sometime with a Django application, it is really good at it,

switch to another framework like fast api and it's okay at it but there's just 20 some years

of knowledge of django and documentation and blog posts that's you know compiled in

would add on this

is again

working

well we

it seems

that even as

there's new

models coming

out all the

time so

Sonnet 4.0

0.5 came out. I'm sure there'll be, you know, other ones. The trend seems to be slowing. They

seem to be, they're 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 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 want to use a local model like we we think

that this local model given your laptop is a good choice you know because 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

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 three percent 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 at it it can just solve and do um 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 uh 2-1 or 3-1 i think it's 2-1 i've been playing with it um yeah the 600 the 600

100 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 don't have a lot,

like using Copilot and Cursor in an IDE.

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.

So there's something to that because cloud code and stuff 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 survey will 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, type hints. So there was, again, survey respondents, but it wasn't even close in terms of response for type hints. I know this is something the steering council has been talking about. What is there to update on that?

cohort so a an innovators um leading edge type early adopter type so okay we need to um you know

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 um yeah and so uh you know

something we're going to talk about will have talked about by the time this came as it comes

out of django on the med i'm gonna get simon charette in the room who's got ideas about the

orm and you know i've got ideas about um types type um type safe serialization um i don't know

who else is going to be there there are there must be approaches that we can take but django being

django we're not just gonna be able to you know whiz through rewrite the orm in some totally

you know type safe way it's it it's 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 and so django fits right into that description and or django as

historically written and the other end 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 that's the big

challenge and if we can we can add a type safe layer on top of the of the orm then that would

feed into the to the um the model objects that you're consuming and not model objects but that

that query layer objects that you're consuming in your views being type type safe and then well

your views could start being typed you know okay we could have you know um the query parameters

come in that those those given known types we could have any of these things we could start

to introduce um but there's some hard questions to be answered first and then with django is

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 stabilities we've got the long-term support policies

it's we can't just rip it up and start again um so 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.

From custom software development to consulting,

team augmentation, or opening an office in Bulgaria,

you they're ready to take your project to the next level and there's new types i mean just this

year right astral put out tie um jeff you would know there's another another one came out did

facebook put one out as well i believe or meta put out one so it's ah there is no yeah i 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++ it's kind of not what python is to me so the

um required right and it's that that bit of the original pets have kind of not they kind of are

required they you know it has become conventionally in the case that you do need type hits but dynamic

python is still a valuable thing but there are some core cases where you want to know um i mean

i know take the take the data types coming out of a form so you go cleaned 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 dit out of clean data so the type checker could go you

know what i was expecting a name field not a noom field oh because i mistyped it right well but this

as a beginner you would just get that type thing but and you know vs code everybody might be using

well it it will tell you by default hang on there's a an a key error here because we were

expecting you to use name not noom oh yes it's a typo and that can't be picked up current without

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 Pydanic 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 Rar, 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 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 bully and 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 and it like

when you run your application dash dash help it will show you that you know you can do that

dash verbose 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 it 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 rar dinosaur part that's tough and i agree with all the reasons carlton is saying

um 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 oh crap i got

to support this for my IDE, so I get

good completions, 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

TOML, and you get these side

benefits for free because

it's what typing lends you.

I like the developer experience,

I guess, as my too-long-didn't-read-it.

Fair enough.

Yeah. Anyway, I agree

There's a lot of possibilities here.

Um, and I think just from a, as a, from a sort of steering council hat on, um, 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 like?

Would you do the honors?

Yes, HacksOff 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

your Django project to the next level.

Yeah, thanks

for sponsoring, Hacks.

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

So anecdotally, I 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 backend. I don't know if either of you have theories on, on the bump there.

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,

like, I'm not suggesting like we remove

these database drivers.

i wish there was a way to be able to measure that uh pi pi seems to be one of the more accurate ways

we have to measure that because there's 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 um how many people actually have the oracle driver

installed with django same thing with my sequel mario db all of these would be just super useful

even from like a board level so we kind of know you know because i would love to fundraise off of

was just um just in the news the last week or so for being now the you know world's most valuable

company or something or they tripled their value well i can't remember exactly what it was or

is a big company it's used by in a lot of a lot of um enterprises they're using it and um i think it

does django well to have um oracle support as you know as first class i would love to you know if we

could somehow make it happen i'd love to see us have um microsoft server um server um support as

well or a dual server sql server they like to call it i'd love to have that um 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 and i would be personally i would be sad to see

it taken out i think that would be a um i think from an open source and from a you know volunteer

only basis and 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 i think you know long term it's been a good thing for the framework and

hat on is our fundraising is something that we we've added a third fellow this year and

django was unsupportable it was untenable to continue two fellows or one and a half fellows

so we've had to raise that um there's been some criticism about the way that our fundraising

pages laid out because it doesn't really emphasize that you're supporting the fellows and so in the

next couple 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 donation is 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's

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

25 i'm sorry 25 so this must be 24 yeah you have 24 yeah yeah okay sorry i got my ears i was gonna

that's a good one yeah sorry um okay well said third-party packages so again speaks to the

who responded jangerous framework was the big one by far but it was sort of the usual

PyPI download statistics.

Django is in, sorry,

REST Framework is installed in over half

of all Django projects. So it's

like, you know, more than 50%

of Django projects are using DRF.

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.

They do not have Django in the requirements file.

And 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.

Um,

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 jazz band,

Django commons,

Django girls,

um,

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 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.

I think if people saw this as one of the first couple of things they see as part of Django, it would help Django a lot.

can you show that on the vlog thing we're doing i probably can i'll just do my little rant while

corbett 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 um 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 inroad and this is just the first version it's

not as glamorous as could be and everything but this was our the steering council's take of like

you know these are the some of the 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 we

whatever whatever negative vibes go might go around at times because django is old those

kind of disappear because actually the ecosystem is really vibrant you know there's always new

packages coming up and you got 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

bubbled up in search because that's the other problem is like there has to be some visibility

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 oh 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, you know, Python has grown a ton. You know, 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 like,

that information that we already it already exists, we know about it, we need to do a better

job of telling people and showing in the search, or maybe somebody is 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, I 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.

I hear that all the time.

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.

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, RM, admin, 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

overwhelmingly on the latest version of Django,

which

it's nice to see.

Django Fellows

and the community put a lot of effort into the long-term

releases, guaranteeing

around three years. So those are the 0.2,

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 this survey, I was like,

I don't know if

70-80% are on the latest version.

That would be the one that jumps out at me.

that the responder base is the very most vested in the community.

We know, again, from the PyPI downloads,

that at 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 80 to 80, however many percent on the latest version.

But yeah, so it's 75% said they're on the latest stable release, 21% on the LTS and

3% on the other.

So, yeah.

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

you know to get an idea of how quickly people are jumping on the point releases as well that would

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 6.0 is out 6.1 is going to have a few warnings but like with the lts cycle in general

we're letting people know ahead of time um i just think the barrier there isn't as high as it used

to be and people are probably lazy uh like myself and they use ci and ci catches so much of this so

thought about was um you know maintaining this stability policy and not introducing breaking

change and making the 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 the um the mindset had shifted um and i think that's a good thing and i think

i think they're stable releases and less change from year to year yeah 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 before never jump to something else there was a

CalDAV spec for a while. And that proposal gets thrown around every once in a while. 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. 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.

I'd call it something like that.

I haven't seen yet the one that gets it,

but 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 even you know it's it's kind of like there's no difference

between you know 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 i

annual release cycle then instead of eight months though so i don't know that would be i think that's

as 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 but yeah that's again no i'd love it i'd love it if you

change but no one's yet suggested like the you know oh yes that makes total sense okay testing

package to do it 30 coverage 21 and then um django test plus at 12 that's that's a revsys

package now jeff you're the you're the pi test person in this conversation i don't use it much

if at all carlton i believe you're also pi test light in your or maybe yeah i'm coming around to

style things even if i'm using the the pi test runner i'll still do my um arrange

at 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 spend ages trying to track down the

fixtures so i like to keep 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 pi test but yeah

i see that it's very popular i can't quite work out

and how Python itself could adopt it

or how Django could adopt it

because we've got a custom test runner

and move to PyTest would be a big project.

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.

Yeah, what is that?

And then people who like function-based tests

really like class-based unit test style tests.

I'm missing out, Ted.

Django Test Plus is just a wrapper.

It's just convenient features.

It works with unit tests.

It works with PyTest.

It works with both.

I like PyTest a lot.

I think what Carlton tried to say, too,

is PyTest fixtures are like a frenemy of 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 the 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...

If you're starting from scratch in 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,

eh, where the hell are the fixtures at?

Cool.

You can declare and you can put them

where you want them to be

is kind of what it boils down to.

But they're so powerful.

That's just code hygiene the same as always.

If you put your code in silly places,

you're going to have a trouble finding it later.

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 so here's a question and i think

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 it's like almost everybody and

all the major packages use pytest and all the um kind of headline python developers that i follow

and i you know really respect their judgment all like pytest is the bees needs 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 isn't part 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 know 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 january so oh no everything's got to be in core hang on which is it

how to test and i suspect someday pi test would maybe come into or some some pieces of it are

going to go into the language because that's going to make it easier and faster for support

if what you're alluding to is like a rest story i think that what you know when 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 half half

of people are going to say

it's rest half are going to

say it should be able to do a

gmail templates people there's you know 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 want to

see django turn 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 i think

it's you know pi test 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.

I 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.

If you go to Laravel repo

on GitHub, you can see that there's a

slash MCP

which is the restful

way AI agents can wrap REST API

calls and so they're already supporting that now they also have breeze which breezes 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 um 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 uh it's been a while like adrian had data 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

sql explorer which is very much like this you can just sort of dig around from the admin and i and

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 it could be that

maybe it's Django dash experimental or just slash experimental becomes that,

but I would love to see us try to swing and,

you know,

try for a home run,

try something that's new because I think these things are very relevant to the

industry.

Stuff like MCP.

Some people listen to this podcast.

We're 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 Jake knows cadence currently

works,

but I think we should allow the space for people to make experiments and,

Sometimes it works, sometimes it doesn't work.

If you look at like South and, you know, 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, you know, 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 like aware of what is working in Laravel, what is working in Rails, what's

working in FastAPI, and have those conversations.

about 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 court.

I 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

um we we as a community can go at a much faster pace if we promote what's out you know the third

party story the the external package story even if some of those are under the ajango umbrella

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

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 we'll 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 you know mentioned to the

um the pycharm team who also works on the python survey like this survey is really important to

jango this is the only real way other than vibes and hallway track and maybe jango 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

so but congratulations the jet brains 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 think we have to

i was on the board when the survey started and worked with them on this and also the promotion

and um yeah they're good citizens with that jeff anything i didn't mention that you'd really like

to see next year on here?

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.

Also, like I wouldn't mind

some more like long-form questions

just to let people

like what are we missing

and, you 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 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 at least it's a it's

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 going to plug environs, which I think Jeff, you also like. This is a way to do

environment variables in Django. I think Django dash environ is probably the most popular one.

There's a couple of other ones. I personally like environs because it's relatively lightweight. You

can in brackets when you install it uh put django in there and then it gives you django database url

a couple other things um i just like it i have nothing against django environ 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 environs so i'll

notes on second um so i'm going to plug um atwin desktop so um it's this new app it was just

announced today and i've downloaded can we spell that a-t-u-i-n and right and it's um a few years

ago this tool called atwin came out and it's a fancy shell history now you you both you both

know me you know i don't adopt new tool you know i'll try everything out but i don't adopt

basically anything unless i think you're ai in fact this can't be the bill carlton because yeah

no this is my um this is my avatar that i put on for the show today but i tried actually i try

everything but i adopt very few things onto my final workflow and atwin is the shell history that

i i gave it a go and i'm like oh yes this is this is just great and i have it set up so that in my

projects up arrow is um like a project local history search and then command control r is

like global history search and it's just phenomenal you haven't told me about this before

i was just not come up well i just hadn't quite got around to i have been you know

standing it a little bit on mastodon but um anyway they've released this desktop tool which

and the plug is runbooks that run so it's a little and i've downloaded it looks good

and i'm only plugging it because i'm so impressed with their existing project and it looks a bit

like say a jupiter notebook but it's specifically tasked to um shell integration it's got ssh

integration it got kubernetes monitoring sort of going on it and it's for kind of like runbooks

for kind of ops ops um 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 Atuin, the Shell history client, is wonderful.

Give it a try.

But also, Atuin Desktop's 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.

Here it is. Shell's all the way down.

All right, Jeff.

Nice.

Oh, yeah, you had me at Rust on that one.

Andrew Miller's Django prod server, 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 that 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, 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 this also, like, I think prod server also, like, turns off debug.

And I think there's a couple of switches it 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 Guncorn.

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 Django because it's not pulling all these third-party libraries in.

It's just creating like a framework and hooks

so that you can add an easier story

for putting your Django application in production.

You create an interface, an API that people can implement,

and then Django will normally provide a default implementation,

but 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. And I think that would be a lovely addition. So I'm excited

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 thread 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 of calculus and stuff and probability,

but it's not overwhelming math.

He gives the analogy early on of, oh, what's his name?

Ilya, one of the founders at OpenAI, who as an undergraduate at University of Toronto

know was studying math and physics and went to jeffrey hinton and said hey like what's up with

neural nets and was given a bunch of papers and then came back and said well this math is so simple

like how could how could there be something deep in here and that's kind of one of the points is

that the underlying you know that why he and um satskiver i think ilia satskiver was like oh maybe

this is the path is because the math you know it's not math for math's sake the underlying math is

like you know there's some stuff there but it's not you know it's not string theory or anything

like that so anyways i'm enjoying it i've 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 uh it's not like a pop culture popular physics book

with no equations it's like it's got equations in it um but it doesn't have homework so i'm enjoying

linux at the command line by daniel barrett this is um like basically it's a bash book it's how to

you know use your shell but it's it's great so there's there's the old ones as things like you

know the 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... 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 argument substitution. It's

a great read.

You know, if you just want to

refine your shell skills,

I really recommend it. Efficient Linux

at the command.

I didn't bring the physical

book, but all of Jesse Seema's

books uh pronouns 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 yeah uh their

books are amazing uh my kids favorites there's a lot of unicorns there is a netflix series right

yes of the netflix fame and this is a partner to uh john bonifato who is the vice chair going to

be chair of PyCon US

for the next couple

years also PyGotham a

lot of people know

them from uh if you

go back the book page

yep top link do you

recommendation this one

the narwhal one's good

you got a little uh

unicorn pony that

thinks it's a narwhal

lives under the sea

with its family like

what's not to love

about that uh I just

see lots of Jango

pony love when I see

the books um they're

really good from like

an adult perspective

some of them are

really get you

thinking because 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 three is out soon and just a small part

of the python community i love seeing like this whole thing is great so nice so kids a new book

just came out a couple weeks ago i like that link there good good good all right well lastly we'll

learn about their services in the description below. And thanks to 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. This episode was sponsored by Hacksoft,

your Jenga development partner beyond code. Learn more about their services in the link

in the description.