Transcript: Django 4.2 - Mariusz Felisiak

Like it used to be Fortnite, a podcast on the Django web framework.

I've got a gibson joined us by Will Vincent.

Hello, Will, how are you?

I'm good.

And today we've got with us Marish Feliciak again, my Django fellow colleague.

Hello, Marish.

Nice to be here.

We obstensibly we're going to talk about Django 4.2 and maybe 5.0 and I don't know, other things like that.

Um, because 4.2 is in pre-release.

Can you tell us all about that now?

Uh 4.2 is one of a long-term support release.

So uh we've extended support until April 2026.

So more than three three more years.

Uh the final release should be issued in uh early April this year.

So now is the best time to check new features, uh to start testing, to choose your personal favorites and see all good all uh Django 4.2 goodies that we have and that we prepare for our users.

It's a good time.

It's you know, come on guys, help us.

Yeah.

If you have a test suite, if you have CI, right?

So if you're if you're sitting there at your work and you're like, we've got a test suite and we run it on every commit and every thing, then if you could run that as well against Django 4.2, then that would tell us, that would help us find the bugs, right?

Because there's guaranteed to be bugs.

And what we don't really want is the day after the final release for you to open the first ticket on um the Django track saying, Oh, I found a bug in 4.2.

It's like we had months for this.

We already fixed all of them that were reported at the beginning after releasing the alpha release.

So we are waiting for a new one.

So Carlton, I you and I talk all the time.

Marius, what are your thoughts on what what's a good, like what do you see in the Django landscape as like good CI?

Like, what are the options that you see?

And is there anyone that I mean I know you spend all your time fellowing, but like what's your what's your take on CI and best practices?

Because you know, Carlton and I just talk to each other all the time.

Uh if you have more complicated CI, then we are, for example, using Jenkins.

Uh in Django, but there are there are plenty of options.

Then the I would say that the GitHub actions are currently the the the easiest to start.

Okay.

So it's like it's not just so much that it's GitHub Actions, it's the one that's nick already in whatever you're using.

Just use that.

Just use something.

I think because um circle CI, I think a couple weeks ago there was another.

I mean, that's one of the kind of older I think it's still around, but it's had some issues, and there was this security incident.

And um Yeah, but my sense is GitHub GitHub or GitLab lab actions is kind of the default most people use these days.

I just want to confirm.

Because they were great and they were one of the options, and they were they were awesome.

And I uh I mean so Marius is a hero, he runs the um the um Django Jenkins and keeps it stood up.

But I remember using Jenkins and then Circle CI came along.

It was like, ah, this is a breath of fresh air.

Uh and so I have a you know little sweet spot there for for the this is my first taste of hosted CI, and it was a lovely thing.

But then GitHub come along with their you know, basically quite quite generously generally generously hosting.

It's got to be difficult if you're them, I would imagine.

Yeah, yeah.

Um that's that's tough.

Anyway, sorry, I interrupted.

We were talking about 4.2 and well

If you I don't know if you um, you know, one thing that's always worth doing is um running against the next version of something.

So you know if I've got a production outp and it's on um you know Django or Python 3.10, it'd be nice to know that it's run, you know, when Python 3.11 comes out that it's compatible.

So if you can use a if you're not using a thing like a tool like Tox, which enables you to build to test against multiple configurations, you know, to test the next Django using a tool like Tox, it might give you an excuse just to bring that into play.

So you can run your existing one against, I don't know if you're on 3.2 or 4.1, and then you can also test 4.2 at the same time.

Um, and that helps us and it you know maybe helps you bring your test suite forward.

Like if you're a if you're a lower-down developer and you're working on Django, you know, there's nothing stopping you from running running it against 4.2, and you might find something.

And that's good to know for Django, and it's good to know for your company too.

We are testing we are testing with all uh uh alpha pre-releases uh of new versions, so we are doing exactly the same uh trying to help in uh Python developing.

He's like, Oh, I've I've I've fixed this one here.

Okay, fair enough, well done.

Yeah.

For Python 3.8 and up uh for Django support, or it will be, I believe, with 4.2.

Uh 4.2, yeah.

Uh the next version, 5.0, will drop support for uh 2.7 uh uh for 2.8 and 2.9.

Yeah.

I mean, you know, people update or die, you know.

It's like you know, Marish and Nick, um Nick Pope, who's another um regular contributor, they just put in all these cleanup, these millions of cleanup commits to to drop support for this, drop support for that, and it's just like this is beautiful, you know, really like just lovely changes coming in.

You think, oh, and then you all of a sudden you're like, oh we've got to support 3.2 for another year, and you start to feel a bit grumpy about it.

I remember, you know, it's like, oh no, 3.2 is the the the chain around my neck.

That used to be 2.2, it used to be 111, you know.

Yeah, and

And we need to set we need to support it and backport all uh security releases, for example, to it.

So is a new version of Python every year.

So 3.11 this year, 3.12, or 3.12 will be this year, and then you know 3.13 the year after.

And what that means with the long-term support was we're still supporting 3.6.

So we're currently supporting 3.6, 3.7, 3.8, 3.9, 3.10, 3.11.

We'll be supporting 3.12 come October.

Ah, like this is a thought on that, right?

Much easier, and especially with our policy when we are dropping support for uh Python versions only uh after uh the uh LTS releases.

So we'll not drop support for any new Python versions uh in 5.1, 5.2, 6.0 will be the next version will be drop support for uh any Python version.

Or well, but probably 3.12 by the time it's actually released.

So it'll support only three versions, but within its lifetime, all of a sudden there'll be two more, and then the the 5.2 release will end up supporting five versions of Python again, which is quite a lot.

right, yeah.

I remember um Django 1.11.

There was uh quite a long line of requests for please support.

I can't remember which particular version it was of Python, but it was like, no, we don't add support, but we don't add support, we don't have support.

But eventually we're like, okay, we'll add support because it's only this one tiny little patch.

But it meant that Python uh Django 1.11 was supporting you know these whole extra versions late in its life.

You know, late in its life it gained support for an extra Python version, which seemed, I don't know, well, people wanted it, but the the there's a there's this sort of tension, it seems, between people who aren't want to be on the long-term support Django, but the latest Python.

It's like, well, which is it, folks?

Do you think the pain that you and others undergo to maintain this is worth it, or is it something that should be revisited?

Yeah.

So we already decided that we must uh backport support for new Python versions when the old one is in extended support, for example.

And it is something that we did in the past for 1.11 when we decided to uh backport support for new Python version.

Uh I don't remember exactly 3.5 or 3.6, something like that.

Though we had a long discussion about this uh on the Django developers mailing list, that uh folks would like to support 3.6 and 2.7 in the same time.

Uh it was it it was really it was really tricky.

So now we now we uh decided uh uh already that uh Django uh uh Django 4.2 will be the first uh version that supports Python 3.12.

Uh and we'll not backport uh support for it to the uh earlier versions.

There aren't many other frameworks out there that give you that kind of five year is it five years, three years, three and a half years.

Anyway, however long it is, they give you that you know that extra support there.

Um I made um Tim Graham chase me around the playground about it for both 2.2 and 3.2 about dropping the older versions because we're dropping um now 3.8 and 3.9 for for Django 5.9.

They've still got like a year or two left to go, and there's lots of folks that you know open up a computer and they got some version of Python on it and that perhaps they don't know what.

And it'd be nice if you know Pip install and just gives them the latest, but I think there's just no way out of it because what we can't do is in a point release, some some way through you know the the LTS cycle, say, oh you know, do you know what 3.8 worked till 4.2.6, but in 4.2.7 it suddenly stopped.

There's just that would just be, you know, as Tim Graham put it, that would be a pretty rough stick.

I think that you know so in the end I've come around to that the current version is probably the best one that there is.

It's it I don't see an another way, having tried to square the circle different directions.

It just doesn't go.

Well, I mean, and Django can't be responsible for people knowing how to use Python.

I mean it would be I mean I mean it's I like I just um released uh on my Learn Django site a how to install Django post, which seems sort of like well just pip install Django, but of course for most people it's like, well, how do you install Python?

What's the command line?

How do you use it?

How do you use uh virtual environments?

All these things, there's different ways to do it.

Maybe you should do Python-m pip install instead of just pip install.

You know, so there's a degree, I think, of education for others of us so that folks don't go, ah, Django, you don't support Python.

It's like, well, okay, you know, Python could help you out here, and hopefully I and others can help people not just assume that Django is responsible for all the you know the universe of web development that people need to do.

So, anyways.

Um they they just want to uh install Python and that's it.

And it's not going so fast as uh developing uh Python versions and uh uh other packages.

Yeah.

Okay.

Fortunately or unfortunately, uh I'm I I'm not sure.

So uh the the biggest one is support for uh Psycho PG3.

Uh it uh it changed a few things, like for example, it prefers server-side parameter binding.

Uh it has uh asynchronous asynchronous uh connections and cursors built in uh into it.

We are currently uh uh don't use them, but uh we we need to have them available in long term to uh add the entire async path uh to the uh Postgres query.

And I think I can just with the connection object, I can just create an async client and then I should be able to use that.

I mean it it won't have any of the nice wrappers around the ORM facilities, but I can use that in an async view, for instance.

Um Yeah, you

I mean I've been looking at that for uh kind of um uh streaming response type example to use publish notify and uh or notify listen and with us an async connection and see if I can get that working because I I think that would be a lovely example.

It depends uh what do you have available in your uh environment.

And it works uh like a charm.

The the the the second one uh are comments, our comments on columns and tables.

It's a really nice feature.

Uh it's another it's uh another example of uh of uh thing uh that should help uh avoiding writing uh D row uh SQL statements because currently you can keep your uh database comments on columns and tables.

Uh in your models with uh the new uh attributes, dbcommand for field and dbtable comment option uh for uh models meta.

Then the migration framework will propagate comments uh to your tables metadata, and that's it, that's all that you need.

Why do I need dv comments?

And if you have if you have uh folks that are have direct access to your database, like database administrators or maybe data scientists or other members of the team that are not Python developers that have direct access to your database, then you need to uh move the entire description to some uh to some to to to some fifth tool, yeah, to to descri

be what's uh how the current schema looks like and how it works.

Now it can be now you can use uh comments on columns and tables to describe it automatically for them.

twice because now we are using uh database constraints to generate information in advance that uh that some data will uh violate your database constraints so you need to so you don't need to do this uh in in two places

actu happen to access my database directly I could enter any value in there whereas exactly

with the new um unique constraint?

annot create unique constraints with work conditions but you can create a unique index for example with work condition so Django will do this for you and uh decide which one uh should be created uh on the database side

need to think about except that Django handles it for you.

And it's almost endlessly deep.

This this is why because Marius Carlton and you know contributors are doing all this hard work and so even if you don't know what what we just said it's more or less handled for you.

I did want to ask do you have another question?

I was gonna ask on a lighter note you know I know that the admin is getting um the light dark mode just in terms of things people will see when they open up and play around with Django right that's something um that's kind of cool, right?

Like the admin has been getting more JavaScript over time and um I don't know.

Is that okay to put that in there Carlton or you still want to ask about

Look and then you change

Right?

Yes.

It's the little things it's like polishing the inside of drawers you know so like when I see other people's books and tutorials and I understand why and they don't have exactly the right screenshots I'm like anyways.

Now that it's about me.

You should sc totally script all your screenshotting for your whole

And I just get I now I find myself filling in all the rest of it because everyone's like wait but why why does this do that?

Why does this do this?

Why does this do this?

And it's you know I'm I'm becoming sort of the thing I didn't want to be but I'm like I want to have like a whole like second half of the book that's like you don't need to know this but if you kind of want to know how this all works like here's why this

deeper and deeper on the explanations.

Anyways and you know invariably it just means it just means like finding a link to the docs somewhere but then you know internalizing the docs.

Anyway sorry admin Marius

things like changing uh CSS units uh to RAM like uh improving contrast of different elements and so on so in in in e version we we have at least few uh accessibility improvements uh in the admin and I think that's that's really nice and that's really important.

So if you've got 200 models registered you just type in the name of your model and you can find it more you know quickly it's it's a little thing but it's like ah actually that's quite a nice quality of life improvement.

the sort of you know custom lookups probably okay on

ah so we can register it for example for a single field in a single model

Because it's inside your web root um and in order to look up the matching ones, I'm working on creating one of exactly one of these lookups just on the text field for the for the variable value the the lookup that does the match against the name because it's a it's a template, so you've got um the double mustache and then the variable name.

And it has to look inside the string value to find the the value passed into the lookup, and it wants to select just those variables that depend upon the passed in value.

And it's lovely to be able to do that just on the value field of the variable class, not on every car field, because most car fields they don't need a lookup on a depends on lookup.

But what a lovely API it gives me, because it gives me variable.objects dot filter depends, you know, um text uh value depends on.

And then the class goes in and it reads expresses the domain object of my uh the domain logic of my model as it's as I'm writing it.

It's like yes, this is this is just a lovely addition.

If you if you know how it works, then you can uh use this custom lookups uh to create uh massive shortcuts to create things that uh will uh reduce complexity of your filters uh significantly.

Uh a simple example you have a model with I know price and uh uh and taxes.

Uh so you so you have a value and taxes.

You can you can create uh now you can create lookup that uh will be called total value, for example, and automatically add tags to value and uh search by this without creating an annotation, without uh calling function.

Uh everything depends how fluent you are with with the model lookup.

Basically, it has only one uh uh really important thing, one really important method that is called uh sql, and then you can do anything you want inside it.

Like they're you don't you

So inside as sql you can call, I don't know, concat uh database function, uh pass to fields, uh compile it and return uh SQL and parents and uh parameters from it.

So when you when you start to to to play with this, uh the then uh you can see that it's really powerful.

Not clunk clunky is not the right word.

It's a bit scary when you first open it up and start having a look.

This as this RHS, LHS, right hand side, left hand side stuff.

What's going on there?

How would you advise?

I guess my question is how would you advise learning that?

Like, what's your sort of routine for that for people who aren't necessarily so familiar with the ORM?

Read the darks.

I don't think the docs are that explanatory.

Uh and also uh I I'm sort of checking how the uh building lookups look like.

Yeah.

Yeah.

I in in fairness to that and to bring it back to me, I I've increasingly added in my books, and I do have things where like I'll do some show something and I'll be like, Do you know how I knew how to do that?

It's not that I just read the docs.

I went to the source code and I'll like link to the source code.

And it's actually one of the things that readers like most because they think that this eight they just the source code is just this total black box, but then they go in and see like, oh, this little you know, here's this line here, and you know, and just even navigating it, right?

Like I usually advise like like it's something as simple as um like if you're updating, if you're doing your authentication flow and you want to update the templates for password reset and password confirm, like how do you find that?

Well, you just you know take a couple word snippet, type it into GitHub, and um anyway, so I'm trying to do my part to get people to not be so scared about it because especially stuff like that, it's like it's window dressing, but there's this like, whoa, it's like I don't need to know how Django itself is structured to go in and tweak something.

I can just kind of navigate it like any other code base and see the results right away.

It's like people would at some point reach, they'd they'd be like, Can you can we subclass or can we add a hook so that we can subclass this generic view to do something very, very slightly different to the generic view that Django Rest framework ships?

And the answer that comes from Tom Christie's policy on um project maintainership, but which I think is absolutely right, is no, you can re-implement that method without the hook, and we won't we won't put the documentation understanding burden on every single user of the project ever just because one user in a thousand needs this weird customization.

You can just re-implement the method, and people be like, but it's not documented, it's like no, go and read the source code, and they'd be like, Oh, that's a bad documentation.

You know, it's not bad documentation because it's fantastic source code.

Literally, you go into the mix-in, you know, REST framework mix-ins, and they're all all the methods are about six, seven, eight lines long, and they're clear as day.

And it's it's nothing for you to copy that into your own project and customize it and implement it, and it'll be easier for you to maintain and easier for everyone to maintain.

But all it took was you to pluck up the courage to open that file and read it, and you think actually it's not it's not magic, it's it's the most straightforward code there is, and there are other bits which are you know much more hairy than that, but in general, the code's not as scary as you first think.

Yeah, there are a

That would that's like blog post worthy, you know, because it is these follow-on effects and um yeah.

I like that.

Well, it's like well, we could, but then every single user of this API for the remainder of the history of the project will need to understand that keyword arc and ask, is it relevant to them?

And beyond the core use cases, chances are it isn't.

So don't add it.

Would you

There's there's some stuff, not a lot in this release.

It seems like there's a little bit around um something in the models and testing, but this isn't like a a huge async release for Django, which we've kind of had the last couple.

Um like there's something around the save method, right?

No, not the save method.

Um yeah, asave.

Yeah.

Uh uh hooks related with um related managers, like uh related version of uh adset clear for uh many to many fields or reverse for origin keys and so on.

Uh I I I think that but basically that's it.

It's not uh huge async uh async release, but of course some improvements are uh included like in every release.

So for an a streaming response um takes a an iterator and it it streams it out over time.

And traditionally the uh up to now that's been um doable with a sync sync iterator with WISGI and it would um block the the th the thread, but yeah, if you're streaming a massive CSV file, perfect, you know, it it would work.

Um with it that wouldn't work though under async.

Um it would it would consume the whole iterator and then give you the whole response all at once at the end, which isn't what you wanted at all.

If you now pass H uh streaming HTTP response, an async iterator under ASGI, it's important under ASGI, then it will um correctly stream, which gives us the ability for things like long polling or um server center events, which is kind of like the outer limit, is as I kind of see it of what of the features that Django needs to provide for async.

That nice um service server center event type pattern.

If we can provide that in Django itself, brilliant.

And then things like WebSockets and whatnot can be in channels or another third-party package.

Um and so that's that's a nice addition.

And then from async now on, we'll be about filling in the gaps, making it more usable, get because it's still there's still some gnarly edge cases and bits which aren't you know as as smooth as they could be.

And if we can flesh those out and fill those out and fix the bugs and improve the performances and all these other things over the next few versions, then all of a sudden, having it been quite a long road, Django's async story is starting to look quite mature, and that's that's a nice place to be, I think.

How do you I know I know you work full-time on Django, but do you have time or mental space to do to look at other things out there?

Like like we just had Mark Smith on from MongoDB, and he and Carlton have the Lud Love Fest around Rust.

Are there other technologies like it's okay, you can mention them, that you look at and think, oh, that's just interesting or something Django should do, or or just just are interesting from a technical standpoint, right?

Because you spend all your day dealing with the gnarly stuff within Python and Django.

I I could imagine some of the love for programming seeps out if you don't find other areas to have a kind of a blank slate.

I I would say that maybe in three or six months I would have more time to look at something uh more than that.

So well let me ask you uh some something uh something else, which is uh 5.0.

So I know there's nothing set in stone, but as ever, things that almost made 4.2 get shifted.

For the two of you, are there some features or new things for 5.0 that um might happen or would be cool if they happened?

Uh the main one is to add support for uh database defaults that is waiting for at least a few releases.

It's maybe even the oldest open ticket that we currently have uh on on our list.

It's 400 something, yeah.

So it's it's it's really hard.

And we have uh and we have a new pull request.

Uh and we we have a new uh pull request that looks quite mature, and so I I hope that's uh uh we'll be able to include it in in Jungle 4.0.

5.0.

Because I think the idea is that defaults would be would apply in both cases, but it might be that when it's created you want to add an added now, whereas when it's updated you want to do an updated now type type thing.

That looked positively received on the forum.

I don't know if you saw that.

Did that get picked up?

Do you think that might go?

So that'll be the first

feature in.

It's already there.

Brilliant.

Yeah.

So the the one the the first phase of that will be to um handle JSON data.

So if you post JSON data, you can be able to access that as request.data and it'll come out past as you know a dictionary rather than having to.

And that's not a big step, but that's been on the backbone.

That's bit, you know, I think the original issue for that was something like 13 years ago, and it just sort of not happened and not happened and not happened.

And so the the my goal is to get that first step in, and then perhaps for the Google Summer of Code, maybe, or you know, over the 5.2 cycle, have that um configurable request passes.

So you could, you know, have YAML or I don't know, Cuddles, the new the new format everyone's using, or message pack passes or whatever.

But you wouldn't Django, I don't think, would provide those itself, but it'd be nice to be able to have content type aware request body passing in in Django itself, because that's something that REST framework added um separately before.

So you have a you have an end date, right, Carlton, just in terms of the transition and like like I'm not on the board anymore, so I'm not privy to the job.

No, well,

Um so hopefully the the call for new fellows will go out this quarter.

Um, but I know Marish would be fine if you know he has to hold the fort by himself for a little while.

Um I always joke that he feels that he's like that anyway.

Um but yeah, my my plan is to step back the end of this first quarter.

I have said that you know if there's a need for mentoring or whatever, I could be around, but you know, again, Marish is perfectly capable of that.

But what I don't want to what I when I said that, what I don't want to do is just walk away and leave a vacuum.

If there's a need for a transitional period, I'm happy to do that.

But basically, I think it would be good for me to step down.

I've been doing it a long time, and now my head's sort of turning away.

It's like, oh actually, I need to I need to draw a line rather than drag it out.

Um because what I I will need to do the first month is I'll just need to turn off the notifications for Django Django.

Not that I'm disappearing, not that I'm stepping away, but I can't f I won't be able to follow the notifications in the way I have been as fellow because that's that's sort of soul consuming.

Um and that's fine, but uh I need I'm gonna take you know a month and say no, I'm not gonna look at you know, if someone at mentions me, that's a different thing, but um I'm not gonna watch every notification

At Carlton on every every Facebook.

Yeah, no, but that's fine.

Django is uh, you know, he he's just a massive part of my life, massive part of my career.

I'm still gonna hang around, I'm still gonna be contributing, I'm just not gonna be a fellow.

I mean, because it's not the first transition, won't be the last, right?

So this is a question I should know this maybe, but so the fell there's a fellowship committee, it's on the website.

Do they do they ask are they gonna ask you, Marius, your thoughts if they have finalists, or do they just decide like if they get a list of people and it comes down to a couple?

I hope I mean

I don't know how to do it.

I guess you haven't done it before, but well well, Carlton, you I know you were extremely excited when Marius came on board.

I don't know if you were involved with that, but

I didn't know about it until I saw the announcement.

And but Maris was like literally the perfect candidate.

Um, Tim was stepping back and I could handle most of the framework, like no problem.

But those RM tickets, I'm not, you know, I'm still not, even five years later, uh, you know, the expert in that area.

I mean, you know, I could I can find my way around there now much more happily than I could before, but I'm still not like, oh yeah, I'm gonna do this for every database and blah blah blah.

Whereas Marish is like, bam, RM expert.

And when it was announced that Marish was taking over, all my concerns about Tim stepping back just disappeared.

It was like, yes, Marish was actually the perfect candidate at that time.

So I'm still excited that it was him.

No, no, no.

I mean,

it's absolutely straightforward.

What he's always the same thing.

What are the areas Well, okay.

Like, what would you what would you, Mario, say to someone who's considering um applying for it?

You know, because if somebody's thinking about they might be listening to the podcast, like what are you know, what would be different than what Carlton's doing, for example, right?

Because everyone comes in with different interests and different areas of expertise.

Like, and what would you, you know, what would you be happy to have someone else handle that you're currently handling?

So uh we we need candidates, and uh I hope that we'll have uh more than few to to uh to pick up uh uh the the the perfect moment.

I I don't have anyone uh specific in my mind currently.

I would be happy to to uh have a candidate with areas that I'm not extremely comfortable with, like I don't know uh JS, CSS and so on.

But at least uh for the last few weeks I'm trying to move out of my comfort zone and uh triage tickets that I'm that I was not really uh happy to to to to triage a few months ago.

And I tried to to to push them uh to to to to the cartoon box.

So currently I'm trying to triage whatever I can and to review uh whatever I I can.

But yeah, I I think that's we have um maybe a few weeks with a single fellow.

So uh then we should survive without without any issues.

But that's a good point though, that you're constant.

I mean Carlton has said this, but you know, constantly learning in the fellow's role just because the scope is is so large.

So even though you come in with a particular area of expertise, it's not like you're only doing ORM tickets for years and years, right?

There's all these areas and somebody needs to handle it, and so there's opportunity to learn, you know, just just to sell the position a little bit to someone, you know.

I mean it sounds

There there isn't a bit of Django's code base now that that I don't think, yeah, I know my way around that.

Like, yeah, there's still the naughty bits of the RM that will always be difficult, but I think they're even difficult for marriage if I'm honest.

Um and there's no way I had that knowledge when I started, you know.

I was but what did I do?

I did what I tell new contributors to do now.

I sat down with a ticket and I opened, you know, I looked at the ticket and I tried, read the ticket, and it's still the same now.

I try and understand it.

And I okay, I open the thing, where is it in the code?

Can I reproduce it?

Can I put a breakpoint in there and see what's happening at a particular bit of code?

Can I, you know, put an a raise in a test case and see if I can get an exception somewhere?

Okay, explore.

And you know, when you first start off, yeah, wow, it's I think it's intimidating.

You know, oh god, this bit I I've never looked in.

I don't know, I don't know my way around there.

What am I gonna do?

Well, you're just gonna dig in, get your hands dirty.

It's fun.

Are there other things you wanted to mention, Marius, or we should we should ask you or discuss?

I mean, for the 4.2 is the big one, which we've talked about, and people should run the tests and yeah,

Uh the new Google Summer of Code is coming, so uh please apply one of the features that I mentioned previously.

Uh custom lookups for field instances.

It's a successful project uh for the previous uh Google Summer of Code uh edition.

So uh please apply.

We have a special uh site with uh some ideas about Google Summer of Code projects.

Uh if you don't find anything interesting for you on this list, you can uh come with uh with your own ideas.

Um yeah,

We we have some ideas for for these features, but we need uh for example to like to spend time uh and learn uh new things to beat it into Django.

And um what else?

DjangoCon Europe is coming up for those who can attend in May in Edinburgh.

Um I'll be going.

I know both of you are going.

So Yeah,

Yeah, come on.

I can't spoil it.

It's uh it's top secret.

I know you and Carlton do all this work, and I hope you know, beyond the release notes and everything else, this helps people get a sense of what's coming.

Um these releases don't come from nowhere.

It's quite a lot of work to get the alpha out the door and then this is nice, you know, rolling.

But test early and often folks, test early and off.

Is there any like I guess if people can find you on the Django, you know, um developers group, but is there any other way people should Yeah,

I'm not really tweeting anymore.

So I I don't have enough time to cover uh a few social accounts.

Uh and basically Mastodon is the only one that I'm currently uh posting anything.

Carlton, you're pretty active on there, which is nice.

Um it's not not at you, Will, uh, but just at will that I can throw out um random thoughts.

I've just said at will again.

How does that make it anyway?

Yes, I like Mastodon, it's fine.

It's just for me, it's like Twitter, but without the Nazis so far.

So that's quite good.

Yeah, that

Yeah, yeah, no.

Right.

Um we'll have links to everything.

We'll have links to to your Mastodon, uh, Marius, and the release notes and everything else.

And we are uh DjangoChat.com.

We are on Mastodon too, and we'll see everyone next time.

Bye bye.

Thank you.