Transcript: Django 4.2 - Mariusz Felisiak

hi welcome to another episode of django chat like it used to be fortnightly a podcast on the

django web framework i'm carlton gibson joined us by will vincent hello will how are you

hi carlton i'm good that's good and today we've got with us marish feliciak again my

django fellow colleague hello marish hi nice to be here thank you for coming on we ostensibly

we're going to talk about Django 4.2

and maybe

5.0 and I don't know, other things like that

because 4.2 is in pre-release

can you

tell us all about that now?

So we released 4.2

two weeks ago

4.2 is

one of a long term support release

so

we've extended support until April

2026

so more than

three more years

The final release should be issued in early April this year, so now is the best time to

check new features, to start testing, to choose your personal favourites, and see all Django

4.2 goodies that we have and that we prepare for our users.

I like that you've stated that with a nice understatement there.

It's a good time.

absolutely morally obligatory that you run your test suite against django 4.2 is you know come on

guys help us what's a test suite yeah what's the test 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 everything then if you could run that as well against django 4.2 then

that would tell us that would help us find 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 the django track saying oh i found a bug in 4.2 it's like we had months for this

and as for now we don't have any open release blockers for django 4.2 we already fixed all of

them that were reported at the beginning after releasing that for release so we are waiting for

new one okay so carlton i you and i talk all the time marius what are your thoughts on what's a

good like what do you see in the django landscape is 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 i just talk to each

other all the time if you take into account my uh open source work then probably github actions are

not the best options to to to start uh with testing your apps or your third-party packages

or any code that you are already working on 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 i will say that

the github actions are currently the the easiest to start okay that's my sense you're using git

git labs got it built in as well right so it's like it's not just so much it's github actions

it's the one that's nick already in whatever you're using just use that right just use something

I think because CircleCI, I think a couple of 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 yeah, but my sense is GitHub or GitLab actions is kind

of the default most people use these days.

I just want to confirm.

For me, it's got to be difficult if you're CircleCI, right?

because they were great and they were one of the options and they were they were awesome and

i mean samaris is a hero he runs them um the jango 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

and so i have a you know little sweet spot there for for me this is my first taste of

hosted ci you know 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 i don't have much experience with circular ci but i would say that the the power of

jenkins is as similar uh to the power of jungle that there are a lot of third-party packages and

plugins that you can use for almost everything right yeah yeah yeah it's it's tough with the

the consolidation just sort of makes sense in a way but when you have yeah github gitlab just

being like oh your your whole product is a feature and we'll just make it you know more or less free

um that's that's tough anyway sorry i interrupted we were talking about

4.2 and well a test in 4.2 if you i don't know if you um you know one thing that's always worth

doing is running against the next version of something so you know if I've got a production

app and it's on you know Django or Python 3.10 it'd be nice to know that it's right 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 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

week forward yeah and it makes you be a hero in work 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 it's good to know

for your company too and it's not that we are doing this only for ourselves we are doing exactly

the same with python for example we are testing we are testing with all alpha pre-releases

of new versions so we are doing exactly the same uh trying to help in python developing

yeah maris is um quite often fixing a little 3.12 bug that comes up he's like oh i've i've

fix this one here. I was like, okay, fair enough.

Well done.

Well, and

it's now 3.8, right, for Python,

3.8 and up for Django support,

or it will be, I believe,

with 4.2.

4.2, yeah, 4.2 will support

Python

3.8, 9, 10,

and 11.

The next version, 5.0,

will drop support for

3.7,

for 2.8 and 2.9 yeah yeah so it's 3.10 plus it's that's the one i yeah i saw it i think you you two

were talking about that on on mastodon and it's kind of exciting right i mean you know people

update or die you know it's it's not just exciting it's like wonderful it's like you know marish and

nick pope who's another regular contributor they just put in all these cleanup these millions of

cleanup commits to to drop support for this drops about that and it's just like this is beautiful

you know really like just lovely changes coming in you think ah and then you all of a sudden you

know and we've got to support 3.2 for another year and you start to feel a bit grumpy about it

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 and it's especially tricky when we have a long time uh long-term support releases

like jaguar 3.2 that still supports python 3.6 that is not supported anymore and yes we need to

we need to support it and backport all security releases for example to it um so can i just get

your thoughts on the um so jack python has gone to this yearly support yearly release cycle 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 what's your thought on that right it would it would be easier if

whether you have when you have a new python version per two years for example

much easier and especially with our policy when we are dropping support for python versions only

after the lts releases so we will not drop support for any new python versions

in 5.1 5.2 6.0 will be the next version we will drop support for any python version so yeah so

when 5.0 is released it looks like it doesn't support very many it's only 3.10 3.11 oh well

but probably 3.12 by the time it's actually released so support only three versions but

within its lifetime all of a sudden there'll be two more and then the 5.2 release will end up

supporting five versions of python again which is quite a lot five or six maybe right yeah because

we always get the we always get these um reports i remember um django 1.11 there was 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 have support we don't 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 jango 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 there's this sort of tension it seems between people who

want to be on the long-term support django but the latest python it's like which is it folks

well you're you know marius if you could wave a wand would you keep our current policy do you

think the pain that you and others undergo to maintain this is worth it or is it something

that should be revisited?

I think that the current policy is fine.

I would be maybe more careful

about backporting support

for new Python versions to the old one.

So we already decided

that we will not 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 backport support for a new Python version. I don't remember exactly 3.5 or 3.6, something like that.

We had a long discussion about this on the Django developers mailing list that folks would

like to support 3.6 and 2.7 at the same time. It was really tricky. So now we decided

I'm ready that Django 4.2 will be the first version that supports Python 3.12

and will not backport support for it to the earlier versions.

Okay, so that's some progress, at least from where you're keeping your sanity.

i think it's probably the best policy that's available given that we have these lts supports

which the lts versions and the lts version is one of django's unique selling features there

aren't many other frameworks out there that give you that kind of five year is it five years three

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 get some version of python on it and 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 lts cycle say

oh you know do you know what 3.8 worked till 4.2.6 but in 4.2

2.7, it suddenly stopped. That would just be, you know, as Tim Graham put it, that would

be a pretty rough stick, I think. So in the end, I've come around to that the current

version is probably the best one that there is. I don't see another way, having tried

to square the circle different directions. It just doesn't go.

Yeah. 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 how to install

django post which seems sort of like we'll 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

virtual environments all these things there's different ways to do it maybe you should do

python dash 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 yeah mainly because folks want to stick with python that is available

for their OS operating system distribution.

They just want to install Python and that's it.

And it's not going so fast as developing Python versions

and other packages.

Yeah, like if you just apt get install

and what do you end up with, yeah.

Okay.

So 4.2, what's your favorite feature, Mariusz?

i think that almost all of us all of my favorite features are related with drm

right unfortunately or unfortunately i'm i'm not sure so

the biggest one is support for psycho pg3

i'm excited about this one uh it's it's called psycho pg3 but it's totally different implementation

of a Postgres adapter for Python. It changed a few things, like for example it prefers server-side

parameter binding, it has asynchronous connections and cursors built into it. We are currently

Don't use them, but we need to have them available in long term to add the entire async path to the PostgreSQL.

I've been looking at this. I haven't played with it yet, but I've been scheming.

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 won't have any of the nice wrappers around the ORM facilities, but I can use that in an async view, for instance.

one thing i've been yeah you can create async cursor or async connection and just use it yeah

so that's perfect i mean i've been looking at that for a kind of um streaming response

type example to use publish notify and or notify listen and with this an async connection and see

if i can get that working because i think that would be a lovely example it's it's also really

nice in this integration that we don't have a new uh engine because uh current built-in

postgresql backend supports both psycho pg version 2 and 3 it depends

what do you have available in your environment so you don't even have to change your setting

file you just pip install the new one and it picks it up a new one and that's it and it works

like a charm. The second one are comments on columns and tables. It's a really nice feature.

It's another example of a thing that should help avoiding writing

D-row SQL statements because currently you can keep your database comments on columns and tables

In your models, we've got the new attributes, dbcomment for field and dbtablecomment option for models meta.

Then the migration framework will propagate comments to your table's metadata and that's all that you need.

Okay, can I ask, why do I need dbcomments?

In the past, I struggled a few times with creating a maintainable database schema.

And if you have folks that 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 move the entire

description to some field tool to describe how the current

schema looks like and how it works. Now you can use comments on columns

and tables to describe it automatically

for them. Okay, that's

a great answer, because

not everybody accesses your database

via the ORM. So can I

ask you about the other thing that's not

in 4.2, but it's been sneaking

along, you know, slowly building

up over the last few releases, which is the growing

support for constraints

usable

via the ORM and credible via the

migration frameworks. Same sort of things

going on there. What would you talk, how would you

what would you say about constraints?

and the power they give.

Previously, constraints were like the last resort

that protects our schema from invalid data.

And now we are using them to validate the data

everywhere on the user's site

when they are putting data on forms, for example.

You don't need to do the same twice, because now we are using database constraints to generate information in advance that some data will violate your database constraints.

So you don't need to do this in two places.

But I've got, like, I don't know, an age field, and you've got to be over 18.

Previously, that would have been a Python construct, a Python function, to validate that at the form layer.

But then if I happen to access my database directly, I could enter any value in there.

Exactly. And then now we have a single point that protects both on user size and on your database size.

And there was something about migrating old constraints.

Was it unique together constraints?

Are they being migrated automatically or do I need to take,

if I've got an old unique together meta value on my model,

do I need to replace that with the new unique constraint?

So all constraints defined in meta constraints are propagated,

are propagated automatically to your database via the migration framework.

Okay.

And were we getting rid of index?

there was something, indexes on the fields

were they going? I remember

seeing something go past here

yeah they are also going automatically to

your database

some databases are

mixing indexes and constraints

so sometimes you cannot

create constraint by you, in the same time

you can create index

on

in some cases

Like, for example, unique constraints, partially unique constraints, or unique constraints with some work conditions.

In some databases, you cannot create unique constraints with work condition, but you can create a unique index, for example, with work condition.

So Django will do this for you and decide which one should be created on the database side.

This is all relevant to me in that I've had a number of my readers who are beginners ask, like, what is the Django ORM?

And I've been going deeper and deeper and deeper and trying to explain.

And it's just like there's so many things you didn't think about that you need to think about, except that Django handles it for you.

And it's almost endlessly deep.

This is why, because Marius Carlton and contributors are doing all this hard work.

And so even if you don't know what we just said, it's more or less handled for you.

I did want to ask, do you have another question?

I was going to ask on a lighter note.

You know, I know that the admin is getting 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, that's kind of cool, right?

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

Is that okay to put that in there, Carlton?

Or do you still want to ask about?

no no no carry on it also means that i'm gonna have to update all my screenshots for the 4.2

book updates and tutorials which is okay but you know whenever the admin changes that's always the

one where i'm like okay now i really have to re redo everything all my screenshots because the

admin changes surely you only need one screenshot show and the admin you can toggle to dark look

and then no no because every because because every picture on the admin will have the toggle

somewhere and and it will bug me if i'm showing something that clearly doesn't have that toggle

right yeah 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 not that it's about me but you should

no let's make it about you you should become a um ui testing um expert like you should do

like this playwright thing that Microsoft chucked out that's a bit like selenium you should

totally script all your screenshotting for your whole well you know what I've sorry so just to

since you asked about me I've been getting lots of great feedback about my books and I find I

so when I wrote my books initially I was like all these books are so deep in the weeds and all the

details and I'm just going to kind of show you how to do stuff and then you can go read the docs

and i just get now i find myself filling in all the rest of it because everyone's like wait but

why does this do that why does this do this why does this do this and it's you know 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 is why you should have a web version so there can be a toggle for debt or a

slider for depth and you can start with shallow and you have a little slider and as you slide it

along more paragraphs can appear of superfluous yeah i just be like just just just blink twice

when you want me to stop going deeper and deeper on the explanations um anyways and you know

invariably it just means it just means like finding a link to the doc somewhere but then

you know internalizing the docs um anyway sorry admin marius

yeah despite the light and uh dark uh core team for admin which is not uh an accessibility

improvement per se yeah we also made a lot of small improvements uh that that should really

uh that should really improve uh accessibility in in in the admin like uh small things like

changing css units to ram like improving contrast of different elements and so on

so in e-version we have at least few accessibility improvements in the admin and i think that's

that's really nice and that's really important and they kind of add up over time right like you

know any one version okay it's more or less the same thing but if you compare it to a few versions

You're like, oh, wow, you know, I'm trying to think that the app filter that, you know, the little live app filter that's down the side of the, is that in 4.2?

Is that already in 4.1?

I don't know, but you can now filter the app list.

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 a little thing but it's like ah actually that's

quite a nice quality of life improvement and most of this most of these improvements are transparent

for other users if you're not using a screen reader or if you don't have a custom font size

for example

in your

browser

then they

are totally

transparent

for you

yeah

okay

so what

what else

do you

have you

got in

your 4.2

list

that you

think

is worth

calling out

because

cycle pg3

is the big

one right

that's the

sort of

you know

custom

lookups

probably

okay

that you

can

currently

register

free

instances

so

previously

you could

only

register

lookup

on field classes, so for example for the entire integer

field and all integer field when you register

a new lookup, have this new lookup

available. Now we can register it for field

instances, so we can register it for example

for a single field in a single model. So I've got a good

example of this, I've got for button, I've got variables for your application

um so you know for your app or for your particular environment and they can be templated

um just you know because they might depend on another one so your your static files

your static route that the path for your static route depends on your web route right because

it's inside your web route 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

the double mustache and then the variable name and it has to look inside the string value

to find 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

depends on lookup but what a lovely um api it gives me because it gives me variable.objects.filter

depends you know um text value depends on and then the class goes in and it reads

it expresses the domain object of my 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 know how it works then

you can use custom lookups to create massive shortcuts to create things that

will reduce complexity of your filters significantly. A simple example you have

a model with price and taxes. So you have a value and taxes. You can

create now you can create lookup that will be called total value for example and

automatically add tags to value and search by this without creating an

annotation without calling function everything depends how fluent you are with

the model lookup basically it has only one really important thing one really

important method that is called ssql and then you can do anything you want inside it i would say

they're a bit clunky though to write but they're don't you you can you can release existing

database functions for example for that so inside ssql you can call i know concat

database function past two fields compile it and return sql and parents and parameters from it

so when you when you start to to play with this

that then you can see that it's really powerful yes but it is i think what would i say 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 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?

What's your sort of routine for that,

for people who aren't necessarily so familiar with the ORM?

Read the docs, Carlton. Read the docs.

No, but this is the thing.

I don't think the docs are that explanatory.

And start from small things.

And also, I'm self-taught checking how the built-in lookups look like.

Yeah.

In many cases, they're having only a few lines.

So that's the ultimate poker of Will Burbett's Read the Docs

and Mara Shroes' with Read the Source Code.

Yeah.

You know what, though?

In fairness to that and to bring it back to me, I've increasingly added in my books and I do have things where I'll show some thing 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 link to the source code.

And it's actually one of the things that readers like most because they think that this, 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 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 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.

I had the same phenomenon with Django REST framework for many years.

People would at some point reach, they'd be like, 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 Restorament ships?

And the answer that comes from Tom Christie's policy on project maintainership, which I think is absolutely right, is no.

You can re-implement that method without the hook and 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 will be like, but it's not documented.

No, go and read the source code.

Well, that's a bad documentation.

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

Literally, you go into the mixing, you know, REST framework mixins, and all the methods are about six, seven, eight lines long.

And they're clear as day.

And it's nothing for you to copy that into your own project and customize it and implement it.

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

It's the most straightforward code there is.

And there are other bits which are much more hairy than that.

But in general, the code's not as scary as you first think.

Yeah, there are a lot of things in Django

that are not only dragons.

I like that phrase, though,

documentation understanding burden,

because I think that's something deep.

That's like blog post worthy, you know,

because it is these follow-on effects.

Yeah, I like that.

It's like, can we add an extra keyword arc?

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 arg and ask, is it relevant to them?

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

So don't add it.

Marius, can I ask about async since we always have to?

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

It seems like there's a little bit around the models and testing,

but this isn't like a huge async release for Django,

which we've kind of had the last couple.

Like there's something around the save method, right?

No, not the save method.

Yeah, async.

We basically added a few hooks that were missing in the previous release,

hooks related with related managers.

like a rated version of art set clear for many to many fields or reverse for region keys and so on

i i think that basically that's it it's not a huge async

async release but of course some improvements are uh including like in every release but

There is some streaming report, async support for streaming HTTP response, which is quite, you know, it's not a major thing, but it's quite, for me, it's the last kind of feature bit.

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

And traditionally, up to now, that's been doable with a sync iterator, with WSGI, and it would block the thread.

But, yeah, if you're streaming a massive CSV file, perfect.

You know, it would work.

With – that wouldn't work, though, under async.

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 streaming HTTP response, an async iterator under ASCII – it's important, under ASCII – then it will correctly stream,

which gives us the ability for things like long polling or service center events,

which is kind of like the outer limit, as I kind of see it,

of the features that Django needs to provide for async.

That nice service center event type pattern,

if we can find that in Django itself, brilliant.

And then things like WebSockets and whatnot can be in channels

or another third-party package.

And so that's a nice addition.

And then from Async now on, we'll be about filling in the gaps, making it more usable

because there's still some gnarly edge cases and bits which aren't 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 a nice place to be, I think.

So Marius, a couple questions for you.

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

out there? We just had Mark Smith on from MongoDB, and he and Carlton had a love fest around Rust.

Are there other technologies? It's okay, you can mention them, that you look at and think,

oh, that's just interesting, or something Django should do, or just are interesting from a

technical standpoint, right? Because you spend all your day dealing with the gnarly stuff within

Python and Django?

I could imagine some of the love for programming

seeps out if you don't find other areas

to have kind of a blank slate.

Yeah, so

a lot of things

are currently

happening in

my personal life, so

I'm

totally overwhelmed with

Python and Django.

I would say that maybe in

three or six months

I would have more time to look at something more than that.

I don't have anything to say

on anything other than Python or Django, so.

Well, let me ask you something else, which is 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 might happen

or would be cool if they happened?

I have a few things on my list. The main one is to add support for database defaults

that is waiting for at least few releases. It's maybe even the oldest open ticket that we

currently have on our list. It's 400 something, so it's really old. And we have a new pull request

and we have

a new pull request

that looks quite mature

and so I hope that

we will be able to include it

in Django 4.0

5.0

did I see Tim Schilling

had this idea for changing update

or create to give

a separate dictionary

for defaults on the create case

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 a 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 yeah i think that will merge it in in the next few days okay right

so that'll be the first feature it's already there brilliant give me a hard one right yeah

Yeah. The one I want to, I've got my post-fellowing list to move forward with a PR on adjusting the request object to handle non-post data, non-form data. So the one, the first phase of that will be to 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 back burner it's a bit you know i think the

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 that the my goal is to get that first step in and then perhaps for

google summer of code maybe or you know but over the 5.2 cycle have that um configurable request

passes so you could you know have yammer or i don't know cuddles the new the new format everyone's

using or message pack passers 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 can we uh talk publicly

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 no so my plan is to step down at um on the the end of

march at the end of um the first quarter 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 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 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 because what I will

need to do the first month is I'll just need to turn off the notifications for Django Django not

i'm disappearing not i'm stepping away but i can't 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 i need i'm going to take you know a month and say no i'm not going to look at you know

if someone out mentions me that's a different thing but um i'm not going to watch every

so just yeah just at carlton on every every feature everything yeah no but that's fine i

want to stay you know i'm not leaving django by any stretch of the imagination django is uh you

know he's just a massive part of my life massive part of my career i'm still going to hang around

i'm still going to be contributing i'm just not going to be a fellow and we we talked about this

when we interviewed tim graham way back in the early days of this podcast 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 there's a fellowship committee.

It's on the website.

Are they going to ask you, Marius, your thoughts if they have finalists,

or do they just decide if they get a list of people and it comes down to a couple?

I'm not sure.

I don't know how it's going to take place.

I'm sure your input will be in there.

I guess you haven't done it before.

Well, Carlton, I know you were extremely excited when Marius came on board.

I don't know if you were formally involved with that.

No, no, no, I wasn't.

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

But Marish was like literally the perfect candidate.

Tim was stepping back and I could handle most of the framework,

like no problem.

But those ORM tickets, I'm not, you know, I'm still not,

even five years later, you know, the expert in that area.

I mean, you know, 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 going to do this for every database and blah, blah, blah.

was marish is like bam or m expert and when it was announced that marriage was taking over all

my concerns about tim stepping back just disappeared it was like yes marriage was

actually the perfect candidate at that time so i'm still excited that it was him no no no i mean

you'll be the you'll be the i guess the senior fellow either way what he's always like what are

the areas oh okay like what would you what would you maria 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 yeah i would recommend to apply so uh we need candidates and i hope that

we'll have uh more than few to to uh to pick up uh the the perfect point i don't have anyone

specifically in my mind currently

I would be happy to

have a candidate with

areas that I'm not extremely

comfortable with

like I know

JS

CSS

and so on

but at least

for the

last few weeks I'm trying to

move out of my comfort zone

and triage tickets

that I was not really happy to triage a few months ago

and I tried to push them to the carton box.

So currently I'm trying to triage whatever I can

and to review whatever I can.

But yeah, I think that we have maybe four weeks

with a single fellow.

So Django should survive without any issues.

It would be fun.

That's a good point, though, that you're constantly,

I mean, Carlton has said this,

but constantly learning in the fellow's role

just because the scope 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 it's it's a phenomenal learning exercise there there isn't a bit of jango's

code base now that i don't think yeah i know my way around that like yeah there's still the

gnarly bits the other m 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've

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

break point in there and see what's happening at a particular bit of code can i you know put 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, I think it's intimidating.

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

I don't know my way around there.

What am I going to do?

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

It's fun.

Yeah, so we learn new things each day

like we did in the past.

We're coming up on time a little bit.

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

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

Yeah, 4.2 is the big one.

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

Custom lookups for field instances is a successful project for the previous Google Summer of Code.

So, please apply, we have a special site with some ideas about the Google Summer of Code

projects.

If you don't find anything interesting for you on on this list, you can come with with

your own ideas.

Yeah, I mean, if you've got, you know, you've got an idea for a project, happy to happy

to open open to it um yeah there are big ones that we're considering from

many years like billion factor authorization and so on we have some ideas for for these features

but we need uh for example like to spend time uh and learn uh new things to build it into django

Fair enough. And what else? DjangoCon Europe is coming up for those who can attend in May in Edinburgh. I'll be going. I know both of you are going.

Yeah, we'll be there.

Are you going to submit a talk, Marish?

Yeah, come on.

Wait, Carlton, you've mentioned something on the back burner, right?

Yeah, I've got a secret idea that I'm brewing. I can't spoil it. It's a top secret.

sorry marius were you going to say can you publicly mention what you were thinking of

potentially talking about i don't have a specific idea but i'm thinking about submitting some

some talk well marius thank you for thank you for taking the time 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 and you know these releases don't come from nowhere so yeah i mean i think

the pre-release phase is quite exciting it's quite a lot of work to get the alpha out the door and

then there's this nice you know rolling test early enough and folks test early enough mario so you

i should know are you on mastodon now is there any like i guess if people can find you on the

django you know developers group but is there any other way people should yeah i'm currently on

on the master i'm not really tweeting anymore so i don't have enough time to cover

few social accounts

and basically

Mastodon is the only one that I'm

currently

posting anything

well same

Carlton you're pretty active on there which is nice

yeah I just I need one place

where I can just throw out random thoughts

at will

it's not at you will

but just at will that I can throw out

random thoughts

I've just said at will again how does that mean

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 that's good yeah that timeline is much shorter yeah yeah no i mean there's only a

few people right yeah i i mean basically everyone i followed on twitter about django is on mastodon

so it's same it's just more filtered and it's still good 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

DjangoChat.com. We are on Mastodon 2

and we'll see everyone next time.

Bye-bye. Thank you.