Transcript: Django 4.1 Preview - Jeff Triplett (Ep 115 Replay)

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Welcome, Jeff.

You two sound exactly like you do when I listen to the podcast.

I thought that was like a pre-recording or something, but

You have to spot that.

The first one you pick, you have to stay with.

Like there's no reason we do the intro that way.

It's just we did it once that way, and it's easier than thinking about it.

But anyway, so Jeff, I don't know if you don't need much introduction, but very briefly, you're partner at Revsys, you're on the board of the PSF, you help with our former past president, uh still involved with DEFNA, which runs US Django Cons.

You've taken over Django Packages.org.

We'll talk about that.

You and I do the Django News newsletter together.

And you also are a consultant, so you just see lots of Django in the wild, so always have stories about how it's being used or misused.

So I'll use that as a preamble.

I also you have a you have a a five-month-old, so um uh I won't try to ask too deep questions of you in this interview because I know how that goes.

So sorry for being rambly.

But I did want to quickly mention um uh for the Django Software Foundation, we will be doing a PyCharm um uh uh promotion this year after all.

They took a pause, but it's gonna be happening beginning of June.

So if you're thinking about trying out PyCharm, wait a week.

Um, you'll get 30% off most likely, and all the proceeds go to Django.

Um so that will be happening in June.

Normally we do it in the spring.

It got delayed, but it is happening in June.

So that will be on the Django project website soon.

Carlton, what were you gonna say?

Um so Jeff, can you let's what's going on when's DjangoCon?

When's the when's the call for uh participation open and you know what what do we need to know about that?

Yeah, DjangoCon US will be this October.

Uh we are very hopeful that pandemic and everything subsides enough that we can have a safe conference.

Biggest thing for us is making sure kids under five can have vaccinations and stuff too.

That way everybody, the whole population is is covered.

Um, the deadline for the CFP for submitting your proposal, we're doing talks and tutorials this year.

Uh, I think it's June 10th.

So it's the the fun Python AoE time.

So as long as it's been, I guess, June 10th somewhere in the world, then you're you're good.

I've tried to step back a little bit and give others space.

Uh the hardest part has been because we haven't had a physical conference in three years.

Um, we haven't had the normal supply of volunteers come in.

Now, the last month we actually have had, which has been really interesting.

So we're getting some new people who've who've uh kind of raised their hands and said we want to help.

Uh, but then also it's this burden of like, do you really know what you're getting into?

So we're trying to, hey, how do I get out from under this thing without crushing somebody else?

Um, not that I'm superman of this thing.

There's a ton of great people who do a lot of great work, but um I've kind of been one of the primary people who kind of know what the dots are, the cadences, and just kind of helping advising.

So this year I'm hoping to be mostly just advising, mentoring.

Uh, but yeah, I'm I'm doing my best to try, especially with a with a five-month-old, as you said, and uh four and a half year old.

It's it's just not not not that where I want to put all my time in at the end of the day, even though I love the conference and I look forward to being there.

And so, you know, a seasoned hand like yourself, it's even if you're not doing it, to have you around is really important to have like that knowledge.

So like it is not not just me by any means.

Uh, a lot of great people are back.

Um, I think two, well, last year was really interesting because we did a virtual and we the previous two years didn't do one.

And so the thing I think is funny is I know there's been a lot of people say like there's not a lot of interest for online virtual conferences, but uh the opposite was true with us.

Uh we had over we had 2200 people uh sign up for the conference last year.

Now, granted, it was free, so you get a whole lot more free people, but that's technically bigger than PyCon US was last year.

And we really just kind of planned on putting videos out over two days and not really being as interactive as we kind of last minute had to be.

Uh the person who was doing our A V work, Adam Fast, his his wife was due to have a baby like a couple days after DjangoCon, because you know, that's that's how we schedule things.

So his wife went into labor on Monday night before the conference.

And thankfully, think you know, thankfully they had a little bit of a delay, but there were like four or five talks that he's like, What do we do?

I'm like, Well, I guess those talks will go up a week or two or a month later, like it'll be fine.

So yeah, we've all had so much family stuff over the last three years, as everybody's had, it just wasn't worth it for us to do it.

So returning to in-person will be interesting.

We'll probably scale some things back.

Uh, I don't know if we're gonna do two tracks this year or one track.

Let's try to spread tables out, maybe make the room bigger.

Uh, we also put out our call for venues.

So if you live in North America and you want to host DjangoCon US next year, uh that that's what is it called?

CFV call for venue is up.

So I we're gonna do our best to not be back in San Diego, even though we've only been there three years.

It feels like it's been five or six because of not having the conference for three years.

Can I uh ask a little bit about um virtual versus in-person?

And is is there gonna remain a virtual element?

Because I I you know for me, I've really missed really missed the in-person conference.

But also the virtual ones have been really good.

But I've seen lots of comments saying, hey, I wasn't able to come, and you know, to to have the virtual is also is it gonna be a mixed format thing or what's your thought in that area?

So the hard part about me saying I want to step back is that when things like this come up and it requires more work, and I'm kind of the one who's like, I really want to do this part, or I want this to be an emphasis, then that our philosophy has always been uh don't volunteer unless you're willing to do the work.

And then there's very few things that we turn down if you're willing to put in the effort and do the work.

Um, so my view, and then there's a monthly conference organizer thing.

Um, I'll have to find a link to it and stuff.

I don't even know what we call it, but uh there's a couple of us have been doing it for a long time.

John from Pygotham, uh Elaine from PyCon Canada.

Uh we've been doing this chat thing for probably four or five months, or sorry, three or four years.

Uh, and it's like the first, I think, or second Wednesday of the month.

I could not have done a worse introduction for that thing possible.

But I'll try to make it even worse next time I say it.

Infant Pass.

It's all good.

All good then.

Anybody can go to it.

Uh so basically, I think the days of only in-person conferences are over.

I think you, philosophy-wise, I think you have to design for a hybrid or online first experience and bring that to an actual event.

Otherwise, I think it's gonna suck to be there because no one wants to see cameras in the back of the room and do a virtual experience where you're seeing that you know the tops of everybody's heads.

And so how we pull that off, I'm not sure.

But it's kind of been my feeling is I've seen conferences return and everybody wants to try to bolt on a hybrid experience because it's more money and it's low effort.

And so I don't know who all well, this is probably before your time, but Carlton, were you at Django under the hood way back when?

And then I was like, ah, this is what I've been missing for a while.

16, 17, something like that.

anyway, Django under the hood.

So one thing they did a really good job of is curating the talks as they went through the day, and they kind of did it in a way that forced people into either a slack or something.

So you could ask questions, but you had to ask it and they curated on the fly.

I don't know that that's something that we can pull off or want to pull off, but I think it's a more interesting format if the people that are watching from remote can submit questions and then kind of feel like they're a part of the conference.

So if there's a way we can pull it off, so if you're remote that you feel like you're part of the conference is what I want to try to emphasize.

Uh obviously being in person, you can go by the poll afterwards, uh, have your happy hour, do whatever you want to do, meet up with people that you couldn't meet up with probably online, or it'd be a little harder.

Uh, but we want to try to like cater to an experience that doesn't suck online.

And that's where I think it has to be prioritized that you know, be kind of online first with you know all the benefits that you get for being in person.

So maybe there's a space, you know, to have a camera at the front to get a decent, you know, video of the person on stage.

But no, uh yeah, yeah, we'll we'll have to shift some stuff around and then maybe by spreading people out and the different rooms set up, we'll we'll you know make that a little easier.

But if you have lots of people online, um it's always nice, you know, if you're open to taking them, it's I always like having the questions and um sometimes where people are shy in person, right?

Sometimes people would like right after the talk come up and ask me a question, and it's like, well, I'm happy to answer it, but I would have almost preferred to answer that publicly because others probably had it.

So, you know, so that hybrid approach maybe will lead to more questions, is what I'm trying to say.

Which I know not all speakers want to take those live, but if you do

We we I wouldn't say we discourage people from taking questions, but uh we we definitely don't make them feel the pressure to to do a QA.

It's it's kind of like you can do it if you really want to and shave off about you know three to five minutes of your time.

That way we can try to get questions.

But you know, like here's our schedule and here's what we're trying to do.

Uh we also I think want to try to have a deep dive day again, and again, I might be just making this up.

I think we've said on the website we want to do it.

If we get enough talks that meet that format, we would kind of like to have a very focused uh go a little deeper in the Django than maybe what some talks would be.

We figure after two days of intro talks, too, and you know, we have a whole selection of beginner intermediate advanced talks, but we figure after two days, even if you're new to Django, maybe you will have recognized and picked up enough in those that that period of time that the third day hearing into some of the maybe whether it's Django internals or shifty advanced talks, maybe.

But so Carlton I look forward to deep dive into the side.

Well, let's say

Can we talk about it or do we not wanna we do we not wanna prejudge uh his talk?

Um because he and I were just talking talking about his w what what's the is is it okay to talk about his um proposal or would you rather we should we wait until it's um accepted or not, Jeff, his topic?

Because it is an advanced one that's interesting to me.

If this is gonna be out tomorrow, then uh if this was to come out after, then

I want you to you know have to wait a little bit.

So yeah, that's that's right.

I wouldn't talk about you know the the the upcoming um Obi-Wan Kenobi series if I'd happen to have seen that.

So you might get it.

No, no,

No, no, no, that's not what I mean.

That's what what I mean is I I don't, you know, when you when you turn up for the talk on the date, you want a little bit of, you know, what's this about?

You don't want to have heard it all on some Ropey podcast.

What's it gonna talk about?

Who should submit to talk?

Jeff.

It's the bar is pretty, you know, we we want the conference to be accessible to you know, life skills or anything that makes you a better, whether developer, writer, writer, what do they call them, documentarian, um anything in the scope of what we do as far as an industry goes.

So don't be shy.

So don't just because you haven't spent that much time on Django doesn't mean you can't come up with something that would be um, you know, advantageous for the community.

And you know, if you think about, oh yeah, middleware is kind of confusing.

Or it's also if you have coworkers who are new to Django, it's a way to get in their head a bit more if somebody says, Hey, I'm I'm new to Django and this was my experience.

So I uh there's a lot of value in that perspective.

It doesn't have to be um deep dives.

Deep dives are fun too, um, but there's sort of an endless source to me, anyways, of the beginner experience on Django, which I kind of get a lot of just from emails with readers, but I think a lot of professional Django people don't.

Um so yeah.

Is that the just

I actually I I have a plan for a uh 30,000 foot view of of Django and web frameworks, like uh how do the pieces all fit together um kind of way that I think would be interesting.

I need to write a blog post up on this, which means I'm just gonna tweet, not blog, because it's just easier.

But like, you know, HTMX is super exciting.

I think anything that makes SPA apps, um, you know, your single-page apps easier is is cool.

Um HTMX is doing some awesome server-side rendering stuff.

There's other frameworks.

I think Django Unicorn doesn't get enough emphasis too.

Those are super cool.

The PyScript stuff is amazing.

Like, I've wanted Django that runs on my browser so templates get rendered for years.

I just can't get like I don't make decisions in Django to make this stuff happen, but I would love to see, you know, nice PyScript Django.

Like, what does it look like for Django to run a PyScript in your browser?

Like that would be so cool.

So I don't know.

I'll come up with a tweet thread or something and try to like you know give some ideas out.

But the best

And but the the the the best talks, the ones that really stuck with me were the the community talks.

They were about cognitive biases and inclusion and I don't know, community building and uh team diversity in teams.

Well, I well that's what inspired me to do my talk in Heidelberg was that I went to Florence and I was like, oh well, actually, this that was I was just blown away by those talks, and they were nothing to do with Django per se.

You know, yeah, they were people in the Jamang Django community giving those talks, but they weren't technical talks.

And so, you know, I gave my talk in Heidelberg on on what I did because I was like, oh wow, can I give a talk like that?

Maybe.

But so yeah, any anything but do something.

Like, what would you two like to see?

I'm really on a I would love to see more about testing, just how people do it, different approaches, because it feels like a somewhat undefined thing to me beyond the basics, how it's actually done.

Um I I've added uh plugs, so I I got the 4.0 version of my Django for Professionals book just out.

So all my books are 4.0, which is a big update for all of them.

I had a lot more testing.

But test testing is just endless.

I would just love to see how people test stuff, thoughts and strategies, doing coverage, you know, integrating PyTest, uh continuous integration.

I just think there's that's bottomless, and I don't see any great resource for doing it other than whatever the company already has or whatever go-to uh approaches you have.

I've been trying to get you, Jeff, to do a book or or something on testing because you know a little bit about it.

I think I like your line that you get paid to write tests, not code.

Can I say that publicly?

I I you make things that I say sound good, or I don't remember saying them.

So thank you for having a better memory than me, but

Yeah, yeah.

That is that is sometimes true for clients.

But yeah, I write code too, but it's you know, being able to like ship something that you know is repeatable, it's not gonna break, it's an underappreciated value, I guess.

Um there's been i interesting threads about you know, Heroku had had some issues and quite a few Django people have worked at Heroku and um it's a sticky, sticky wicket to uh make deployment work well, but that's one as well.

Like something between Kubernetes and a one-line script.

Like, how do you get there?

And I know Carlton, that's near and dear to your heart.

You're still plugging away with buttons that

We were talking about it before we came on.

I was talking before you um came on, Jeff.

Um, I was talking to Will.

He was like, Well, come on, you've got to ship it.

I'm like, okay, I'll ship it, I'll ship it.

But I'm building I'm

Well, yeah, yeah, yeah.

So I'm I was saying I was building nat I'm building native apps, and um, you know, the one reason why it's been so slow is because it's like, okay, well, I have to relearn Swift because I used to I'm like, okay, I'll build a Mac app Swift, I know Swift.

Uh no, I I don't know the modern frameworks, I haven't used them for half a dozen years.

To to relearn that has taken quite a big chunk, but now it's coming together.

It's like, okay, yes, actually, this is fun.

And then I was just about to ship Mac only, and then I had a cut uh a potential customer come along and say, Um, well, can I can I pay you to use it as a you know, and you can work out some I mean of course, that's the perfect, you know, that's the perfect test environment.

And they were on Windows, and I was like, ah, I haven't got a Windows story yet, so I had to learn all about um, you know, how well, okay, what am I gonna do?

So I investigated.NET and you know what's going on now.

I'm like, or JB, maybe Java, and then the thing I've kind of settled on for my Windows story is um to use Rust, and there's a pack um a packaging system called Tori, which is like Electron, but it's a much um lighter weight, and you know, the bundles come out at sort of about five megabytes, and they use the native web view, so you're not running this Chromium instance, you know, you know the jokes about running Slack or Teams that they take up the whole it's it's not like that, and so I think that will be my Windows story.

Um and so that's all coming together.

But that to learn Swift again took me much longer than I ever gave that credit for.

And then to learn Rust and to learn these things and to investigate that, that's all the backstory that took a long time.

But that's okay because I haven't been in a rush, and I'm not building, I'm not building like a Heroku competitor, I'm not building a platform, I'm building toilet tooling to you know communicate with those.

So that's that's all been fun.

Um, and then obviously the last two years have been tricky, and then my the start of this year I was knocked a bit sideways, and my family were um ill.

Um, and so that that wasn't a good start.

But I just last year at DjangoCon Europe I said summer 2021, and reviewing that it's gonna be summer 2022.

Well, it's gonna be 2022, so that's fine.

So we can we can have the moment where's the deployment?

I'll press it.

I'll press it.

I'll have a button that you can click to deploy.

There you go.

Um, but uh what all I can say is well, you know, it's gonna be worth waiting for.

And what are you doing?

I mean, you're embedding Python, I assume, inside your application.

This is where good Python developers go, they go to Rust.

Just like I I was looking, I looked at the Python embedding story, and frankly, it's terrible.

Um, and there's some great work being done to make it much better, but I can't ship you an app and say, Oh, can you please jump through all these hoops?

I just I can't do it.

Like I it wouldn't be an app that I would be happy to ship and live with.

So the for on Mac it's gonna be Swift base and that with a Rust core, and then on Windows it'll be Rust with a web um interface with Tori on there, and then the web app would be the web app, and it'll be those components.

Um but on on the server component that you ship is a single Rust binary that you just download, stick where you want, and run.

Um and it it ultimately it had to be that way.

And I took a long time, I took a long time investigating the various Python packaging solutions, and they were they are coming on massively, but they they just aren't there right now and weren't there at the time.

Um so

Swift took you a minute to to learn.

It's also because you're you're still following and 4.1 feature freeze has happened.

Do you want to talk about uh you know coming in August?

There's a lot in there.

Can you tease, you know, tell us okay?

So you can write a class, my view subclass is view, def, async defget, and then you can do your your async handler there.

We haven't worked through all the class-based views to be async, and maybe we probably never will, but um if you are into class-based views, you you don't have to drop into a different um idiom now to write an async handler.

So that's kind of cool.

Then um the ORM has gained an async interface, so you can do async, async, also you can do await my model filter dot get, but whatever, and it will stream out the objects to you um in an async way.

Underneath it's still the sync, um, the sync ORM.

We so we're still working on integrating the drivers and the getting the compiler to be async compatible, and that work will continue.

But you could now write from 4.1, you can write an async view with an async interface to the ORM, and that will pick up any performance improvements just as you update Django in the future, rather than you having to rewrite your code.

So that's kind of like the yeah, I can write async views.

And to be honest, the limit here is um is not threat, you know.

So at the moment, the way the the ORM works, so in in in 3.2, you we had this um problem with thread sensitivity of ORM operations, such that um basically that the or any operation ORM operation was single-threaded, it'd only go one at a time, and so your requests become one at a time, and that's not great performance.

From 4.0, it's per request the thread sensitivity of the ORM.

So you you that's that that's a big speed up because you can more or less with as long as you don't have too many open connections at once, you can process them in parallel because there's one per thread.

Um more or less now the the situation is that your your blocker isn't um isn't the speed of the the async isn't using threads, it's number of connections to your database, and it's the number of times you're so until we get fully async drivers, there's not gonna be any big speed up there.

Um so the async codes you have now is gonna be nice and performant, nice and fast.

Yes, it's gonna use threads to connect to the um the ORM, but that's fast enough for most cases.

Um why did how'd I get into that?

And I'm curious when you say drivers, Psycho PG, I think there's like a new Psycho PG3.

Yes, right.

What about uh Oracle?

What about MySQL?

We've got a there's a lot of, you know, the the ORM wraps up a lot of complexity for you.

With the big issue now you're gonna find is we're finally at the point.

So when you started Node.js all these years ago and you ran up the the the Node.js 101 example and you got these resource limits because you you opened too many file descriptors or you open too many database connections.

We're now at the point where actually that's the problem you're gonna hit with Django is that you're gonna find, oh, I've got too many database connections open.

But that's that's the place we want to be.

So then the next thing is, well, okay, we need a DB pool, uh connection pool.

So you you use PG Bouncer if you're on Postgres, but well, what about the other databases?

Well, okay, so at some point soon, ish, Django will grow a DB pool for the four native data sub-supported databases with a you know an API for um other database backends to be able to support a connection pool as well.

There, that's that's kind of really exciting.

So that that's that's where it's going, and that's exciting on async land.

The feature I'm most excited about is um that model constraints can now be validated in full clean.

So um in your in your database layer, you can say um an age field, say.

Say you've got a minimum age, you say the age can't be less than 15.

I don't know, for you know, some non-chart, no children allowed, so higher than 15, say.

You can set that constraint on your model, and that will be a database constraint, so the database will enforce that, but now that that can be that can be um validated when you in a form, say.

And so you won't get what what you might have had before is the database constraint in place.

Your form says is valid true, but then you go to save and you get an integrity error.

No, those constraints will come into validators on the form level, and that's gonna be that's actually gonna be it's it's gonna be really.

It may sound abstract, but if you've I've hit that yeah, that's a big thing.

So we've got new new div-based forms, um, form templates, which are uh have got modern more modern standards.

So for instance, they um they group related elements in radio lists, in field sets with legends and things like that, which makes make them much more accessible for people with screen readers and whatnot.

And that that's an easy opt-in with a form renderer, but those templates will become the default from Django 5.0.

You can still use the old templates, they're not going anywhere, but the form rendering changes over Django 4.0 and 4.1 are just amazing.

Like you we're at the point where libraries like crispy forms or floppy forms, the need for those is going to drop away.

And then there's an interesting question: what's left?

Because, say, for instance, Crispy Forms has dynamic form layouts where you can build your form in Python.

And sometimes that's much nicer.

You know, you want to construct your form in Python and then output it.

But just the template packs, you're not going to need those.

You're going to be able to just change your form renderer at the top project level and say, um, my you know, my bootstrap form renderer, and you'll be able to use that as your form renderer class and provide all the right templates so that you get the bootstrap styles or the you know the tailwind styles or whatever you're doing.

Less code, more template?

So um 4.0 inch moved the the actual form element rendering, the form rendering from hard-coded strings plus the widgets were formed were template-based to all the form rendering was template-based.

And then 4.1 has added this um much easier customization, so it can just be done at the at you can you can either do it at the project level with form renderer or you can do it per form class, or you can even do it per form instance, changing the templates.

And so it's it's it's really cool, it's good stuff.

It's like you know, every release I'm literally blown away by how much new stuff we have in it.

You think, oh, there's gonna be nothing for the for the new one.

No, there's masses, and we're already planning 4.2 now already.

It's starting to um we're starting to think excited about that.

So anyway, this so that was last week.

That was the feature freeze last week.

I'll just say one more thing.

And this week I've finally you know cleared the decks.

I'm like, okay, I can start taking on these tickets on Daphne and on channels and on Django, and it's like ah, I can spend summer working on you know lots of exciting async stuff that's been on the back burner for a long time.

Um and that's why you're a Django fellow, is that statement right there?

And we had discussions because um you're not Tom, but you know, uh he kind of said recently like um not really taking new contributions.

Um is there anything you want to add on DRF?

I mean, just I think I mean it's does what it does.

It's um

And it has been for quite a while.

And yeah, um so Tom, I think, is at the moment at the point where we take um inputs to keep it compatible with upcoming versions of Django.

You know, if changes in Django require changes in Django Rest framework, then um great, we'll have those.

But um Django Rest framework itself is not in the position to add in new features.

Um, the last new feature we tried to add, which we just never had the capacity to finish through, was the um OpenAPI schema work, which we got, and well, we got an okay version going.

But um the thing you really need to be using there is DRF Spectacular, which um is just you know just a super implementation.

And what was nice was that it it took the API that we provided in REST Framework and it rode with it and it went, yeah, and it's produced it's it's sort of showing what could have been done if only we'd have had loads of capacity and loads of bandwidth to work on that.

So I think he's putting Tom's put in the docs, or is it the point of putting in the docs, hey, go and look at DRF spectacular for that, and then eventually we should be able to get perhaps deprecate the inbuilt stuff in in um the schemas sub-package in Rest Framework.

And that will keep working, but perhaps move it into a sub into a third-party package and say, look, you know, you the modern version of this is over there, but if you're still using it, it'll still work, no problem, it's not gonna break on you, it just isn't actively developed, and then that will make REST Framework itself really tightly and tight and nicely developed, and then you know it's okay for it to um to mature and grow.

And then at the same time, though, a lot of what's important about REST Framework can be brought into Django itself.

So um serialization is one big thing, and for that, I'm really excited by Django Readers, which um you know we had uh Jenny from Dab Apps come on the show.

Go and check out that show again, go and check out Django Readers, it's it's great for serialization.

Um and then the other thing that REST framework really does is the content negotiation, it'll let you handle REST um uh JSON requests, so you content type application JSON.

And so what we'd like to do is bring um request passing, body passing in.

So it it you add a request.data property um which says, you know, if it's form encoded, you'll get request.post as you always have.

But if it's JSON encoded, you'll get a dictionary back that goes via JSON load, you know.

Um but what what I think the thing that needs to be in core is the ability to respond differently to um different mind types.

So this is HTML, this is JSON, and if we could respond to those different that would be the 99 case if that's pluggable, so you can respond with a YAML parser or Toml or great.

But if we had HTML, plain text, JSON, that's almost all the web requests, web responses you ever sent, right?

And all the request bodies you ever get.

Um that's what we'd like to do.

And then go on, go on.

And that that that that nearly went in, and and the Maris and I were a bit like, but that's a massive change, a really disruptive change without any features.

It's just literally a cosmetic change and it would affect everything.

The diff was massive.

If we can get the request passing in as well, the content negotiation in as well, then it's not just a change for change's sake, it's a change with um a whole load of feature goodness to go to justify and to go with it.

Um and so you know uh that's kind of that's kind of what's on my list is um the async's work plus that kind of request modernization, request data type stuff.

Um I think Maris is very much focused on things like um you know ORM, cycle PG3, um DB connection pool, these kind of ideas, you know, can we get those in as well?

So it's just a really positive time.

Um that's great.

You know, uh I'll say one more thing and I'm gonna shut up because I'm my throat's starting to get dry.

But I think we're really seeing now the maturity of the stuff the the API stability policy and the then the move to the to the three the new request the numberings where it was 2.0, 2.1, 2.2 is the LTS, and then we've maintained the stability from 2.2 to 3.2.

And you know, the the upgrade cycle is really easy, and because we've got the stability policy, it's like, okay, this is this is a given space and time for Django to keep keep growing.

And you know, then with the async starting to mature, it's like, oh wow, you know, these are this is a positive and rewarding time to be working with Django, I think.

Let's give it, let's throw it over to the fellow.

Um, as far as DRF goes, uh, model serializers are so underappreciated.

Um I'm doing a project for a client today like now where I had to deal with CSV data, and it was just so much easier to do all my validation through through model serializers for it, even though it's CSV.

And then there's a third-party project that adds CSV um, you know, handling.

And then it was funny, I was writing tests for it.

I'm like, why is my response codes all messed up?

And then I viewed the output and actually returned it as CSV.

So I was getting status code and description, and it was amazing.

I'm like, oh, this is horrible and great at the same time.

Because of course, status codes would come back in CSV format versus you know JSON or or whatever.

Um, but you know, the extendability.

So like the hard part I think is what what will Django take from routes, I feel like, will be interesting to see because uh, you know, Tom did this, had this beautiful playground of coming up with all these concepts that he couldn't do in Django.

And so view sets, I think, are super powerful.

Serializers were just a better version of Django's.

Um, and then, you know, like you said, the content type, negotiating mime type negotiations.

Um, yeah, I don't know.

It'll be kind of curious to see the parts that need to go back.

This has been my wish list, and I've talked to you all for about it for years.

Like, when is DRF gonna merge back into Django, or what does this look like?

So I think it's exciting.

It is.

Like if you've got an idea and you want a feature in Django, well, implement it outside of Django and show what it looks like, and then maybe you know, because that's to to email the developer's list and say, can they have this new feature?

The answer's pretty much always no.

Whereas if it's like there's this third-party package that I've built and it works really well, and everyone's like, wow, that's amazing, can we have it?

That's a that's a different conversation.

Can I ask you two a question?

And I wanted to A, thank you both for that, because it's just phenomenal the work you've done, and B, ask you about it and how's it going and what your thoughts and that sort

of stuff.

That's quite a compliment.

I don't really know how to follow up with that after that compliment, actually.

Will you have thoughts?

Um yeah, Django News is it's been fun.

It's been, I mean, in in some ways it was an excuse, Jeff, for us to uh collaborate more regularly.

And it also came out because you I think even more than me, you just have your finger on the pulse of what's going on with Django packages and things, and and it just seemed like we should share that with other people because there isn't a Django newsletter.

Um it's a lot easier to do the newsletter than the podcast.

Um, you know, I think like like we do it weekly, but it's you know, I look around and find stuff, you find stuff.

We kind of do a little communication on Thursday night, but it's um it's not that hard to do.

And if we need to, like, you know, you can take a week off, I can take a week off.

So it feels pretty sustainable.

Um the we use this platform called Curated, uh, so that handles most logistics.

It's it's a little expensive.

I think it's $70 a month now with where we're at with $2,500 plus um readers.

But we have ads and we have job postings.

Um so it's you know, it's not a moneymaker for us, but I enjoy doing it and I I yeah, I do think it helps the community.

And um I like things that are relatively easy to do, I guess I would say, as opposed to the podcast, which I love doing.

Um, but you know, it's gonna take me the rest of today to produce this episode, whereas the newsletter is a little bit faster.

And so I I don't know.

I was we we kind of talked about it and the whole idea of like, is this a project we can do in about 30 minutes a week?

And for me, it's kind of a byproduct of things I'm already starring and articles we're already seeing.

So it's kind of interesting of like what we notice on Twitter.

Uh Will was very Twitter adverse for a while, but I guess you're back on Twitter, so you're maybe seeing this stuff again, or maybe you were lurking before from uh

Okay.

I prefer email to Twitter stuff, but I try to do that.

I mean, you know, there's just so much stuff out there.

I mean, we don't repeat things, it's it's pretty amazing.

I I I keep wondering, well, we're gonna run out of projects, or there's there's not gonna be new new stuff to feature.

But between all the Django things happening with the fellows, and then Python has things, and people have articles and tutorials, and um Django Girls is now having a podcast, you know, there's um it feels good to kind of wrap it together, and it gives you know us an excuse to look around more than we normally would for what's what's out there.

And if we can help move the needle a little bit so people know, like it is okay to use um Python 310 or start testing with 311, then that's super valuable.

And I I hope that that influences people to try these things out and update their CI.

And you know, if there's something that we think is cool, um I'm super opinionated about stuff like HTMX, I've said for a while, like use this, this is gold.

Um, even though I've maybe done one or two projects with it.

So like anything like that that kind of helps move the needle back that Django is good.

Let's give you examples by showing you something that maybe will inspire you to write something or use a library, then that's that's where I get fulfillment.

Seeing it.

That that we're sort of um go on.

And it's been far better than I feared it might be in terms of when people submit a project or an article or something, or we see something, you know, people kind of understand where we say, you know, it works or it doesn't work, like we're trying to be a positive voice here, but we do have to curate it.

Um I sort of envision more negative interactions on that front, and there basically haven't been any.

Um, you know, same thing with awesome Django uh repo that Jeff and I do that that's now over 5,000 stars.

Um, you know, it's it's it's hard to say no, but the whole value is in saying no and trying to enforce some degree of maturity in the things that we uh promote.

Anyway, that's what I was gonna say.

So if we include a link that is not great, but it's not bad, then that's okay too.

Like, you know, you never know, you know, like you said, there's 25, 2600 people are uh who who subscribe to the newsletter.

And if one article appeals to a hundred people, great, but there's no pressure that you know there could be bummers and that's fine.

Um awesome Django is interesting that I feel like it becomes this like you can't use Django in your product name more than anything.

So we kind of joke about that probably on the side about like the number of like trademark issues that sometimes come out of awesome Django, which

So there's probably more like agony with it than Django news.

But please put a yeah, please, please put this note in your your footer and ask the DSF before you do this.

Like, this looks cool, but you know, you can't just name your project Django Django Django.

Can I ask you one more question, Jeff, about Django packages?

Because that just came up there uh uh previously.

You've been working on the job.

You had a Python thought, Carl.

It's a bit like at the moment we're in a well, I feel that we're in a bit of a di uh an interesting time because they've moved to this annual release cycle.

Um, but that what that means is that at any given point there are basically five supported versions of Python active at any one time.

So 3.6 has just died, um, 3.7 will die in uh October, but then out will come 3.11 and it's uh 3.8, 3.9, 3.10, 3.11.

And so for the for the LT the Django LTSs, we kind of have to end up supporting all five of them because people will be like, I'm on the LTS and this new version of Django's come out.

Can you please support it?

I think we've said that 4.0 will be the first version to support 3.11.

So Django 3.2 probably won't support 3.11.

But we've had this problem before where you know, month after month people are asking to support the old version the new version of Python, even though they're on the old version of Django.

It's like uh this is hard.

This is really, you know, uh I'd like to get to a point where we can support, say, three or something.

Like, you know, the last three years worth of Python or something.

I don't know.

I don't know.

I mean, if it's just the CI that bothers me.

We run these, we you know, we run this absolutely massive matrix of the same test again and again and again, and there doesn't seem to be a very clever way of saying, well, only run this one if that one passes, you know.

Do you see what I mean?

Because you know, you're running 50 builds and it takes an hour and a half, and it's like that's too long.

That's you know, I just pushed a docs change.

Um anyway, that that was the only thought about the Python release cycle.

It's it's it's

tricky to know.

But I mean, yeah, to your point, um, I think that it's gotten a lot easier to go somewhere around Django, or sorry, somewhere around Python like 3.7, 3.8.

Moving to 3.9, 3.10, 3.11 has been very I've yet to have libraries just fail because you switch versions.

Um, I suspect Django is gonna get more like that too.

And it's probably more about, you know, with the depreciation messages and stuff, you're probably gonna be able to I don't know.

They should at least be showing up on CI.

So I think yeah, the tooling needs to change a little bit about it.

And um, I feel sorry for authors because you know I've heard people complain for years about how much like changing versions of Django impacts their book titles and makes their content out of date.

So like it's even worse, I'm sure, for people writing Python books today, but I don't I don't know the solution.

It doesn't update every eight months.

No sympathy.

Who knows?

I mean, I'm like the only Django book author left.

I mean, who's been here for a while.

Adam Johnson is still updating, um, but it is a I'd like to say it's beyond my control, but I guess it's somewhat in my control, but um, you know, I don't it's a technical decision.

Um yeah, it would be nice if you know it would make more sense for newcomers if 4.0 was the LTS and you could just be 4.0 point da da.

The point two doesn't help book authors.

Um, but I know that it's relatively new to have that whole system, and as Carlton mentioned, it really helps the development.

So it's not all about the book authors, even though, yeah, it that would be easier if a book, you know, didn't go out of date so quickly.

I suspect we'll figure it out or there'll be a better way of laying things out, or maybe it flips at some point.

Maybe by by Django 7 or something, the LTS lands on a zero.

Like I don't these are solvable problems.

I think it just hasn't been obvious what the the friction is, but you know, the more you talk about it on your podcast, then

Python's just gonna be like, you know, three three dot fifty.

Like when does it go to four?

Does it ever go to four?

It's a long time.

But my theory, and this is completely made up, um, is I think that there's no way in the world you're gonna have a language called Python that has, you know, PY in it that they would switch over to Python 4 before they could have Python 3.14.

So they're gonna land on Py, and then I suspect at some point someone's gonna say Python 3.85 is weird.

Let's just finally match dates or do something.

So I think it'll flip at some point.

The point is to get this cadence down so it's so much low effort that when they switch from Python, let's say 3.14 to Python 4, then it'll be such low friction, low effort that we're not gonna have this whole, you know, the grief that we've had in agony before.

I still have Python 2 clients that, you know, we do porting jobs, probably two or three people at Repsys are doing porting jobs at any given point in time because there is so much Python 2 code out there, and you know, other than like security is a good reason, but if you've got millions of lines of Python 2 code, we didn't really give people a compelling reason to switch other than we want to work on Python 3.

And that's totally, totally valid.

But, you know, companies kind of get a bad rap, I think, sometimes for saying, you know, you wrote this code in this thing and things are stable and you're supporting features and stuff.

But when you're trying to flip a million lines of code over because of print statements and stuff, I mean it's kind of silly in my my opinion, but eventually you gotta do it, and there's compelling cool features and great things that have come out of being stuck on versions at what is it?

Django 2.0, I think was the last 2.7 release.

Maybe 111 was.

I was the happiest person.

That's the happiest person.

Red Hat has some Python 2 somewhat supported version.

Do people use that kind of stuff at all?

The these company supported Python 2 things?

Right?

I think it's Red Hat.

There's a particular version of Red Hat I think a lot of them use, but we tend to just put them over in Docker, and then that way they can run the old in a new environment, and they don't have to worry about you know 20-year-old or 80-year-old servers running because those are pretty crusty.

Um have you got time for my Django Dragons?

And I wondered you've seen to I've seen you tweet a lot and you've done a lot of work on it.

Because that was a thing.

And if you do you want contributors and because one of the reasons I'm keen on these old pack these old sites is that they're sort of real Django applications that you can have a look at the source code and poke around and see you know how they're built rather than just you know academic exercises, like you know, um learning exercises.

Um so to me it's pretty cloudy.

We had a we had some really good momentum going, and then we had a baby, and then I kind of you know, I I keep up with it and keep patches, and I've got a bunch of like get stash code for some features I want to change.

Um the the code was in excellent shape.

So other than like some lunting and random stuff, and then I've been kind of making I do what I do at RevSys, like look for patterns of what's maybe broken or what's not so much broken, but like performance issues.

And I've been slowly kind of like every every couple of Fridays or something, I'll spend half a day or a day and just like kind of devote to you know what can I fix?

Like can I fix search?

And there's been some spam issues and stuff because you know, curation is really hard on it.

And then right now we still have too many packages and grids, and so um I've kind of been, yeah, just slowly iterating on it and stuff to try to like um make make it a more solvable problem.

I think for a project that was created back in like the original, was it original Django Dash or the second Django Dash or something when uh Danny and Audrey created it.

Um and then what has it been like 12 years or something since?

Um it's a cool side.

I I think Django Snippets doesn't get enough love either.

I'm certainly don't give it enough love, so I would love to see y'all, you know, maybe bring a maintainer on or talk about it and

Like I get ops team emails and there's stuff on snippets.

It definitely needs a a Jeff to come in and give it a full love.

I think somebody's doing it.

I'm sorry, whoever you are.

I'm sorry.

I've just added the list.

I think yeah, it needs more attention and

Yeah, yeah, yeah.

Oh my god.

Who's it's Chris, Chris, Chris, quid Chris?

Chris, sorry.

Yes, Chris needs

No, he does.

But it's like, okay, he's been he's done a really good job of cleaning up the backlog and keeping it keeping it going.

And then you know, he's even asking, you know, well, what features do we want?

What can we do?

And I think it's a great, it's it's a lovely opportunity for you know, I want to get involved, work on a little project.

It's not high stakes in terms of you know, it you don't have to be intimidated by it, you can just work on a little feature, add a thing, work with contributors, work in a on on GitHub.

It's it's a nice opportunity for ah, I can get my toe wet in open source.

And it's a lovely little application, and it's a real Django app that's been uptime of forever and just been ho, it's been hosted on Heroku, and they've done very well.

And we're no doubt gonna have to move it at some point.

But it's you know, I love that it's still going, and we had to shut down Django people because we couldn't keep that going.

And it that again, that was an old app from the old days, and it was just the thing is we had um, was it this European legislation, GDPR issues, and people weren't able to update their their um their personal data, and it's like, well, you know, are we even is this even legal now to hold to have this site?

I don't I don't I don't know, and then there were spam issues, and so we had to shut that one down, but to be able to keep Django snippets going, and it's you know, it's a cute little thing, and and there's some genius little if you dig through it then how do I customize uh the the choices in a form uh form in it based on the current request?

Ah, there's it's on Django snippets.

There's a perfect example of that from you know 2000 whenever.

Like on the Django community page, snippets isn't there.

You wouldn't know that it's

what it is.

Um Yeah.

Um and Django Packages too is one that I used every week.

I almost use it daily.

And so for me, like putting some time into it to maybe fix search or get it up to date with Django 4.

And it really didn't take a lot of work to do that.

Um, once I get kind of more back on my feet, and it's kind of hard with Django Con.

So part of like doing snippets or sorry, part of doing Django packages was a good excuse for me to dive into more open source code, uh, a little less community stuff, and kind of give me something to buy some time and you know, fix issues that I fix for clients and give me a place that if somebody I get I get requests all the time for people who want to be want me to help mentor them, and it's so hard.

I don't have the time.

And I thought, well, maybe I can throw out an issue on uh GitHub and point people to it, and maybe we update the docs and make it an easier experience so people can give back if they want to, and then maybe I can use that as a good way to you know have a have a quick win.

But yeah, if people want to contribute, we had I think a hundred issues, and I think I got it down to 12 or 13.

Uh granted, GitHub has discussions, so probably three-fourths of those I shifted to discussions.

Um, I don't want to butcher his name, but there's uh a Fabio who also works on the project too.

Um, he's one of the maintainers.

Look at the footer.

I don't want to butcher names.

Um, but like, so there's there's more than just me working on the site.

Um, I'm probably doing most of the main lead stuff now just because of time.

Both of us had kids in the last year, so you know how that goes.

But yeah, I would love to see it grow.

Um, I want to change the default grids to be more list-based and then give you a more of a comparison because those grids that are 100, 200 wide are just it's just too much.

And then there's a pretty big spam update coming up, and you know, part of it like too is we are starting to filter out projects that are 12 and 14 years old.

I didn't want to immediately um remove all of those so that you know some old packages wouldn't be accessible, and so yeah, there'll be some quality of life updates.

I saw a project the other day, I don't I don't want to mention their name, but somebody kind of had a like, this is like Django packages but curated.

And I thought, oh, that's kind of neat.

But again, this gets into another trademark issue, probably with the DSF.

So I uh hate to bring it up.

I love seeing those sites exist though.

So I think it's neat when people are like, here's a thing plus this, but just be careful with what you name your projects.

Yeah.

Like I don't think Will enjoys that's not what Will wakes up every day and say,

Um just ask first.

So um Django X is a starter project I have had for a while that I just uh just updated to 4.0, has a f over a thousand stars, which I guess is is good.

Um it's a lightweight starter project you can just get up and going with pip, pipem, docker, um, white noise bootstrap, Django Debug Toolbar, and Crispy Forms, so del and all auth.

So deliberately very lightweight, not not cookie cutter.

Cookie cutter is amazing, but designed to be somewhere in between.

Um so people should check that out.

And also, um, you know, Jeff, you and I have talked about our you know, potentially collaborating on our own version of like a premium version of that, which um is one of these interesting, but is it worth the time kind of thing to do?

Like, I mean, so I guess I'll tee that up to you as a question.

I know at Revsys, you have an internal kind of template you use, right?

Like, is there anything you could talk about?

What do you like to see in a starter uh template project?

Like there's some really, really good cookie cutter templates that I see a lot of people use, but there's so much inside them sometimes that it's not like it's not as useful for stuff.

Uh RevSys has one we call it Alpha Kit, and we've kind of toyed around with like opening it up too.

And so we our problem is the industry is hit and it's so I guess hot right now as far as like we've got more work than we have people for, but we also know that the market will correct itself or can change.

And so it puts us in a bind where like we would love to be able to spend time working on products or this type of thing.

Uh, but you know, like what do you do?

You um take on client work while you have client work, and then if we can get into lull, maybe we'll work on something.

Um yeah, so you know, things are great.

Um, but you know, we would rather be a little too busy than not busy or have to lay somebody off or something.

So that's probably more inside baseball than the casual person who listens to your podcast would care to hear.

Uh, but yeah, I think in general, um, starter projects I think are great.

I think there's a couple people who've tested it.

Um, I like to look at I like to see what all the other communities are doing.

Laravel um is doing some really awesome stuff for a while.

And that's kind of, you know, when you have somebody who creates a framework and then they decided that it was okay to make money by doing all these products that are adjacent to it.

And so I think I showed Will like my idea playbook like three years ago, which is like, I think there needs to be a good newsletter, I think there needs to be a good news site, I think there needs to be um like a good starter project, I think there needs to be a good button out there.

Yeah, yeah.

Um and he's uh Taylor

I mean that um so I mean those are those are the two ways you do it, you hosting in a starter kit and really probably hosting.

Right.

And so the hard part of Django is deployment, which you know, smart people at Carlton and I think uh Pete from Lincoln Loop and um you had I just listened to the is it appeared app you like yeah, applet i just listened to that.

I just listened to the podcast the other day, and it's interesting.

I've kind of like you know kicked the tires on these apps to see kind of what they do, uh, except for button.

Uh yeah, I mean I I think like there's a whole healthy industry here that you know don't be afraid to start these companies or try these things out and stuff.

Just get permission first if you use Django in your URL.

That's really my only advice for your domain.

You know,

You know, Corey was very good about checking and it does not have Django in it, so it's fine, um, for example.

So, you know, this makes everybody better because it's such a huge industry.

I think people think that it's like, you know, 2,600 people that follow the newsletter.

There's there's 10,000 times more that people hit my mic.

10,000 times more people that are part of the Django community or that use Django.

We probably only get what we call the community, are probably a very small piece of the pie of the people overall people who use Django.

People just they don't have a solution.

And so it's not that there's a saturated market or anything like that.

Like there's room for a billion options.

Like there's I don't know if there's a dozen Django shops or something, consulting agencies, but we're uh friends with everybody.

Like it's been such a big market and stuff, and I've never felt like there's been competition.

Like, sure, we may put bids on the same stuff, but overall, I mean, there's always more work than any of us can do, and it's you know, a lot of great people running a lot of Django shops, so you know

I mean, I met someone at the playground yesterday or last week at uh who had been at JB Software.

I think he said they had like a hundred people or something like that.

You know, they're they're a sponsor of Django, you know.

I mean, because RevSys is relatively boutique, actually.

There are these really large shops out there.

Um yeah, and I I don't know that they have that many Django or Python devs.

They probably have four or five or something.

And again, that's probably made up numbers, but they do a lot of I think.NET and different different stuff.

So nice plug for them, by the way.

I was not being facetious.

There's any agency that you work at, there's like you know, two two Django devs and then two front uh JavaScript hands and then two designers and then a business development fella, and then you know.

Like we've either co-worked on projects together, or there's been a couple where we've hired their devs, and I've like let been either lead or project managed on, and and that's the same thing.

I've worked with other shops too because they needed help.

So we are uh very good friends in this industry, and you know, the problem has just been really getting people.

And I I enjoy these somewhat rambling discussions, but I think between the three of us we cover a bit of ground in the Django community.

So it's interesting to me, and I think hopefully fills in others on all these things we talk about that maybe we don't talk about publicly.

I uh really appreciate being on your show and appreciate that you all keep doing it.

I know it's more work than a newsletter, but

We'll put out old uh old episodes and start up in the fall.

So with Carlton's mentoring, I've you know that's how we keep doing it.

Is it that's

It's like you know, it's too old.

That's amazing.

Read the docs is another Django Dash project, too.

I think it came out the same time as Django packages.

Somebody should redo Django Dash.

Someone from DEFNA, maybe.

We are DjangoChat.com, Chat Django on Twitter, and we'll see everyone in two weeks and then in the fall.

So see you then.

Bye.

Bye bye.

Bye.