Transcript: Kolo for Django - Lily Foote

hi welcome to another episode of django chat podcast on the django web framework carlton

gibson joined us by will vincent hello will hi carlton hello will and this week we've got with

us lily foot thank you for joining us lily yeah it's a pleasure thank you for coming on we always

ask um so we'll get into what um everything about you and all about django but we always ask we

start off about how you how you found Django in the first place so you know it's kind of the

origin story so let's go with that how how come you're here uh yeah so um I uh

went to university for mathematics kind of got burnt out near the end of it and decided to

try learning programming um uh that led to me thinking uh now that led to me uh picking up

python and um then i was like um how do i uh how do i make my own website and i

looked around a bit saw that django was quite recommended for websites with python so tried

that and then ended up turning that into a career okay so the easy way then like just back

yeah um yeah i uh had a couple of um junior level jobs and then um ended up in oxford

uh for a company called in kuna where there are a bunch of um other jangri people um

Mark Tamlin who was a

core dev for a while

and

Charlie Denton and George Hickman

and just being around

them

really

kickstarted my involvement in

open source

it's very

inspiring

I mean Oxford's got a kind

of Django connection right

because i think torchboxer yes torchbox as well um uh yeah i um never worked with them but i am

aware that they're around but there was a were there meetups and things like you know is there

yes um yeah so george who i mentioned uh ran the oxford python um meetup for a while um

he's since moved away so it's run by other people now but um i remember i tried running some janga

girls events in oxford uh we managed to do it successfully twice which was good well super

so i remember meeting you in heidelberg i think at uh janga con europe so yes you know was was

that your first where you've been before and you've been uh seem to be quite well established

to that point yeah so i think the first jango con i went to was um cardiff in 2015 okay um i'd been

to some pycons before that as well and then yeah i've made pretty much every jango con europe since

um except the first online porto one i didn't go to have you been able to primarily work with then

Python and Django throughout your career, or were there any detours into other languages and

frameworks? From the start, it's been Python. One of my early jobs was half Django and half

Kivy, the Python mobile framework. In recent years, I've got into Rust a bit.

that seems to be the natural progression well it's just you know it's not hard enough let's

make it more difficult the um so okay so the way i kind of got to know you mostly was you're like

oh yeah i i'm working on this this db defaults ticket yes you've been working on that for a long

time and that's finally gone in for django 5.0 yes can you tell us a bit about it this is don't

know what it's what's it for you know and perhaps the backstory of getting it in because

you know spoilers that store that ticket was open forever yes so um

db default is um defining defaults for a model field so that the database knows that that should

be the default um for most of django um you were able to define a default but that would

only be used at the Python level.

So Django Zoram would set that explicitly

before sending it to the database to be saved.

But now we have a way of telling the database

that this is what the default is,

and whenever something's saved,

the database can put that default in for you.

This is really useful if you're doing stuff that's not Django

with the same database as the one that you are using Django with.

And so it's quite a useful feature.

I think I picked it because I was looking for a RM ticket that was wanted.

I think I was looking at the old tickets because that's always an interesting place to look.

And by the time it landed, it was the second oldest open ticket.

Fantastic. So I think you've undersold it there. I mean, DB defaults aren't just useful.

So it's all right. So the classic example is the date now, right? I need a date added now,

I need that something. But then if I go in and I happen to be editing not via Django,

if I access, you know, by pandas or I access via any other system that, that default is not

enforced. And to have it at the DB level saves me a bit of work at the, at the Python level.

That's one thing, but I think, you know, if I take my database seriously, which maybe I do,

maybe I don't, but there are lots of people who do. If I take my database seriously,

Having it at the DB level adds a whole layer of security

that's significantly better, right?

Yeah.

I'll take your word for it that I'm underselling it.

Well, I don't know.

I think it's a major feature, no?

Yeah, I agree.

Okay.

Well, and clearly you weren't scared off by the ORM

because usually that's the place that people go to last, not first.

Did you also progress through other open source Django things before that, or that was something you were dealing with for work and so decided to just jump right in?

I think the first RM feature I added was the greatest and least query expressions, and that's something that I needed for work.

and then i just kind of stuck around and was like yeah let's let's keep doing

arm things and i think the vast majority of my contributions have been in the rm at some

some somewhere or other i think there's quite a lot of value in just sticking around like i mean

like the db tickets how many how many jango consprints were you just chipping away at that

chipping away at it chipping away at it yeah um quite a few i i do do um uh conference sprints

based development i go to a conference get very motivated hack on it for a bit at the sprints and

for a few weeks afterwards and then take a break until the next conference comes around

helps balance my

against burnout and stuff

as to how many

it looks like I

assigned myself to the ticket

in 2020 though I did

CC myself earlier so maybe I was thinking

about it earlier than that

I'm pretty sure that in

Heidelberg you were working on it already then

maybe

I'm not 100% but I've got it in my head

it might be that in Heidelberg I was still working on check constraints

oh yeah okay so okay so let's talk about check constraints because

um what so django defaults um in the database in and of itself it may you know whether you

think that's a groundbreaking feature or not i think it it's part of a long line of things that

have come in the database from indexes through constraints through comments in the db through

database defaults through hopefully we're going to get cascades yeah coming up and all of those

are kind of enriching the the ORM and yeah you'll you know you you're probably as capable of anyone

who's speaking to that topic yeah um yeah check constraints is a um another one where um it's

check constraints database defaults most of the ones that you mentioned i think

were all actually unlocked by the um expressions refactor um

now when would that have been probably around 2015 2016 um expressions lookups lookups transforms

um i think everything that i've worked on since has been made possible by that

right so it's kind of like eight years of slow progression building on on that change yeah

it's i think it's probably the most um uh impactful thing that not as many people know

about as they should okay i mean so i've often thought that the ORM is really hard to get to the

the details of so you know when you first start off you can learn to filter you can learn to

um you know create you can learn to get or create you can you know do some basics and you can do an

exist but then there's kind of a whole load of other stuff that yeah what is the learning pathway

there like how do we it's kind of like there's this there's this cliff that people don't jump

off and how do we how do we help them to do that oh that's a good question i think

the thing that really

helped me was

I mean

one thing that helped me was I got in early-ish

which is a bit tricky for

other people, but the other thing

is just I went to a lot of sprints

where a lot of

experienced ORM people

were already

so I was just around them and able to talk

to them and just learn from them

Right

How to do that if you can't get to

conferences trickier um but you can always watch conference talks and stuff like that

yeah i think there's some gold absolute gold dust in there if you go through the past conferences

and find the orm talks and there's some really you know really good ones i've often wondered

if you don't need to know the sql in order to really understand how the orm is working

i uh i will say that for pretty much every database feature i've worked on i've learned

the bits of sql i needed to know while working on that ticket and then half the time i've promptly

forgotten them afterwards well that's why we abstract it into an orm exactly well carlton to

your question i think part of it might be people when are they presented with the problems either

they don't know that it's something that the orm or the database could solve or they're just

perhaps working on applications that have other needs i suspect that's part of it

or maybe i'm just being naive and at a certain scale all these things come up

in your day-to-day work well let me let me respond and then perhaps there you can say what she thinks

but the um for me it's there's it often comes up is this um sort of n plus one problem where you've

got the lazy related lookups and that and then so to be able to work your way around annotations

and then you know filtering on the annotations then doing the values to get the group by and

that stuff's not really documented but you so you spend a lot of time learning it and i just

anyway it's but everyone hits those issues right yeah i think it's a case of

you hit them you search for help maybe you post on the forum or used to post on the mailing list

or ask in discord and um maybe someone helps and then you've got something for your toolbox or

maybe it's a colleague at work i think it's a lot of this is just community knowledge that you

pick up by being around and talking to people who've been there before you so you think it's

just reps it's just you know time on the time on the exercise machine yeah just um and learning to

ask the right question or learning how to find out i mean you can also

So you can look at other people's code,

you can dig into the Django code base if you need to.

How do you learn anything programming?

Yeah, try to bang your head against the wall for weeks.

Where's the textbook?

Oh, there's no textbook.

I guess I got to create my own through conferences

online stuff yeah i mean do you know his chat cheated big sorry i think documentation is

actually quite good um it's i think the maybe the biggest problem is that there's so much

documentation that it's a bit difficult to find the right bit of it but uh search engines are

not too bad for that i think there's a bit of it where it's like okay so i've spent a last hour

reading about you know query api or something i don't know whatever and it's like well what do i

use this for i mean like window expressions are kind of quite powerful and there's quite a nice

doc on window expressions and how they work but actually you need some good examples of how to

use them and and whatnot that i kind of think are missing i think there's a there's a gap there for

that kind of um worked examples of how of these more powerful orm features i don't know

yeah um i'm open to seeing more worked examples i don't see how that could be a bad thing

well lily can i ask in terms of do you is there an area of django that you seem to focus on in

your work i mean obviously we're talking about the orm but have you like primarily apis and

back end have you done templating any front end stuff or do you have a niche um yeah so the

majority of my career has been pretty much jango back end um stuff so anything between the database

and the template layer probably um with a preference towards the database um

yeah i have dabbled with front end but it is not my comfort zone and how much of that is apis as

opposed to a monolith type approach i've done both i think um a lot of what i've worked on is

well yeah it's been a mix um there was definitely some api stuff um um and then a more recent job

but it was very much templating.

And I think there were four monoliths all talking to each other.

It was quite the legacy kind of place.

Okay, fair enough.

Do you have thoughts?

I mean, so one thing we've talked about,

and especially Carlton has mentioned,

is serialization and Django as framework.

If you could wave a wand,

how would you provide serialization to Django itself starting today?

That's a good question.

um i think from for what i've done with it rest framework has been pretty good um there's a few

bits where i'm like okay that's a not quite how i would have chosen to do it perhaps

though i can't think of any examples this is thinking back to the last time i ran into that

um but a rest framework does a pretty good job i i remember uh what was it that i used before

rest framework tasty pie i think and rest framework works so much better for me um it was a more

explicit tasty pie was a bit too magical if i remember correctly i i like the reasonably explicit

nature of rest framework i mean so one thing that's comes up when you start talking to people

is they like the the the newer um type hint um inspired um things like um pydantic or

attas or yeah yeah and they like that um the quickness of it the speed of it you know where

if you've got a very simple case you know um name um string um age you know integer like it's just

it's really quick and speedy but then you know same with attas same with um pydantic if you need

um the more complex cases where you need to add transformers or validators or you know whatever

on then you end up adding a field descriptor anyway and it doesn't end up looking too much

different than what you've already got um so it's kind of interesting as to if there's a sweet spot

for bringing in the newer sort of syntactic sugariness but you know it's no point throwing

out the whole stack for just a little bit syntactic sugar so there's a that's kind of

where i'm at mulling it over in my mind i don't know that makes sense i've not actually um really

had a chance to play with that stuff um the past few years i've been um not actually really doing

django itself that much though very much in the ecosystem because you you've been working on um

on colo yes so tell us a wee bit about colo yeah um so colo i describe it as a dynamic code analysis

tool. It was invented because Will Klopp was frustrated with traditional debuggers,

which you have to know where to set the breakpoint. You have to understand your codes a

certain amount to be able to use them well. And he was like, I want something that will just give me

a lot of that context without having to understand the code beforehand. So he started

building Colo and we met online at the Jamcon Europe 2020 online sprints, online conference for

in Porto and we got to talking and I was trying out contracting at the time so I

So we decided to give that a go, and it went really well.

It was a lot of fun working with Python's introspection features

and working out how to extract useful information from people's programs

without being too slow and yeah I eventually went full-time with colo

because it was just simpler and I was having so much fun with it and that's

also how I got into rust as well we were looking for a way to reduce the overhead

of having written in Python originally tried scython at one point but didn't

really get anywhere but yeah tried rust and was able to get that speed that we were looking for

which is really good well i remember carlton you were there too um will's talk at jango con europe

this year and it's we'll put a link to it i mean he got a standing ovation for that talk i've never

i've never seen that at you know all all the jango cons i've been to i've never seen that before i

I mean, it's quite a jaw-dropping moment to see it in action.

Give a bit of context there.

So what he did was demoed Colo's ability to generate Django tests for you.

So he made some requests.

So you have Colo running.

Is it in the VS Code debugger as it's running there?

Yeah, so Colo is currently a Python library and a VS Code extension.

they work together right so you it might just be that you have the library running and it would

capture the the um the request but it captures the request and then it's able to say right i need i

want a request for these i need i want test cases for these these requests that i've made so you're

clicking around in your application and then it does the whole um you know gets the test client

configures it with the right parameters you know does the request puts in some some dummy asserts

and then you can customise those to check the exact things

that you want to check.

But it's like, oh, yes, that's the really sort of repetitive bit

of writing tests for Django, right?

And it just went boom.

And it's not, one point he made, it's not probabilistic.

It's not generative.

Like, you know, you might get out of Copilot

where it's quite often wrong.

It's fully static, right?

It's fully deterministic.

Yeah, that's the thing I'm focused on at work at the moment

is trying to improve the reliability of the test generation

and add more features and stuff like that.

It's really good when it works,

but there's an awful lot of edge cases and stuff.

Right, yeah, I can imagine.

But yeah, we're hoping that we'll be able to get it

into a really solid place in the next few months

and it'll provide a lot of value to people.

Okay, well, looking forward to that.

Any chance of getting it as a standalone app

or is it tied to the VS Code extension?

You want it with BBR, right?

Well, exactly.

I keep nagging every time I see Will.

I'm like, come on, come on.

We have some ideas about having a web UI to it,

either an online service or something that runs locally.

We have some work-in-progress stuff around these areas,

but I can't say when they'll be launched.

Okay, well, maybe I can hold on to my glimmer of hope.

Well, if we step back a second, I'm curious.

Testing is one of those, you know, it's like testing, deployment.

Those are kind of the two big things that I always want to check in with

people and how they're doing it how how have you seen testing like how do you test django

uh projects and how has that changed over time if you could speak to that right because that's

i'm curious your example because i feel like everyone has a little their own flavor

how it's actually done yeah um i mean i have long been a um fan of test-driven development

maybe not purely strict I often bounce back between writing a bit of code and writing some

tests but I try to have it have them inform each other I think Django testing is often in the

integration test realm especially when you're doing pretty standard CRUD stuff

because the stuff that you really want that fine grained unit test stuff for

It's the custom business logic that is not so entangled with the database and so on,

which is relatively rare in my experience in Django projects.

It's all a bit entangled with the database at least.

So you end up with some sort of integration test in my experience.

It's that fat model thing, right?

Yeah.

You sort of, I've got a bit of business logic,

but I'm going to attach it to my model.

So I need my database.

Yeah.

Or even you, nowadays with a lot of the ORM features,

you can even push that logic into the database,

which means that you pretty much have to have a database

as a dependency for the test, at least.

Yeah.

I personally am a fan of the request factory

and skipping middleware

and just putting the request into the view and so on.

But for Colo's auto-generated test,

we've been relying on the test client a lot

because that matches what we recorded better.

because when you record a local request response,

that would go through the middleware,

so it makes sense to test it going through the middleware as well

when auto-generating.

I think it's probably the more common usage pattern as well.

I think testing views in isolation is kind of more advanced or more niche.

I do prefer being able to have that extra control

and reduce the overhead,

But yes, the test client is easy and often good enough.

And then PyTest, I assume, is also part of your kit?

Yes, ColoZone tests are run using PyTest.

And yeah, I like PyTest a fair amount.

I mostly like the tidier asserts,

and I use the fixtures a little.

But I wouldn't call myself a PyTest expert.

There's a lot that is in there that I just don't use.

How about coverage?

Oh, I love coverage.

Coverage is amazing.

That completeness, yeah.

Yeah.

Frustratingly, for colo, it's actually really difficult

to get 100% test coverage, for the same reason

that coverage itself really struggles to get a 100% test coverage

because the Python API that we use,

in our case, sys.setProfile,

in coverage's case, sys.setTrace,

they're similar with a few minor differences.

They can't introspect code that is running in one of those hooks.

So coverage can't introspect its own code while it's running.

I've had to work around that and it's um a bit frustrating but oh well there is the in in 3.12

the um um uh new uh is it I forget what it's called is it monitoring which

It might allow for introspecting that stuff.

It's been a while since I've looked at it, so that might have changed.

But fingers crossed we can get better coverage out of that.

And you mentioned integration testing.

Do you do anything with Playwright or any of those tools, or is that less applicable?

I don't think I've ever used Playwright.

Okay.

I mean, that's more for, like, testing JavaScript and, like, you know, did my Stripe payment go through trying to –

there were some talks at DjangoCon US about it.

I think that's a dominant tool. Andy Knight is a very big advocate of it and had a keynote, I think, one of the days on it.

Like I said, I've dabbled in front-end. It's not my comfort zone.

Yeah. I just pushed that once more. HTMX, have you at all played around with that or is that cropped up in this template-only projects?

I have not, but it looks pretty shiny from where I'm standing.

Honestly, I think if I had a reason to do some front-end,

I would look to see if I could use HTML for it.

But, I mean, my front-end is VS Code at the moment, mostly.

so it's what works in vs code which is a lot of typescript oh fun

can i ask you a question about russ can i ask you yes a couple of linked questions can i ask you

sort of what draws you to it what do you like about it what what do you find difficult etc

and then swing swinging from there just keep in mind it's like how do you how do you find it in

relation to coming back to python and then the typing efforts in python because i'll tell you

my response then you can just bang off is spend all time writing properly typed code in rust and

it's good fun it's hard and you've got the compiler and it's all this nice and then i find

typing in python to be deeply frustrating and it doesn't do it's all it's all work and no promise

no no you know or that's how it feels as i come back so with that as a as a sort of blur how do

feel about rust and you know what do you like and what lessons can we draw okay so i love rust um

it's it's high level enough in a lot of places that it wasn't too big a change coming from python

for me the thing that really helped with that as well was that i had a very concrete use case

that i understood inside and out um so i just being able to gradually port the bit the python

implementation of colo into rust it's a really smooth way to learn rust yeah you need something

concrete because otherwise the the you don't write the types and you don't you know it's a bit like

and and i was able to just okay what's the smallest thing i can do to have it still working

but more of it's running in rust and i just iterated on that so the amount that i had to

learn at each point was actually very small it's just okay what's the next little thing i need to

learn okay um uh i i have discovered that i really like um statically typed programming

um when it's got all these modern ergonomics that rust has um sometimes it's still a bit

tricky to work out what the right typing should be but once it's once you've got it it really

just works and i absolutely agree with you that the experience of optional typing in python and

typescript to the extent that i've worked with typescript it's it's just second class compared to

something that's thoroughly integrated in language i find i find myself writing django and think i'll

throw in some typing i've thrown a bit of typing because you know why not and then i get deeply

frustrated with it and just like no i'm ripping it out so i just don't want this it takes all the

fun out of writing python yeah and it's not like dislike rust i love rust but python typing ain't

it yeah uh yeah i think i haven't worked on any of the really big python code bases that want

typing but in my experience if you're on a small project typing in python isn't really worth it

well you have to say something now we'll just let that no we'll just let that stand i mean

i'll give you an example from um neapolitan trying to type um neapolitan crud view so that

the set when the model class is you sign them so it's a it's a it's like a django thing right so

it's a view and you assign a class place view and you assign a model class as the model attribute

and then it's got um at various points you might use self.object so you know on a create view at

the end you've got self.object or on a detail view you fetch the object to begin with and then you

render it to the template so self.object has got the set is an instance of the type that model is

and there's just been literally no way of typing that in python um without typing something like

class my crud view square brackets my model you know model equals my model object my model and

it's like you've typed my model 40 times in three lines it's like this is not i'm not doing it i

can't i'm not making any person write that i wouldn't write that no one should ask anyone

to write that it's just it's not good yeah yeah in in colo uh in uh we do actually still use mypy and

typing and my experience is that like 80 90 of the time it's just busy work to tell cut

uh to tell my pipe what i already know um five percent or something um it's okay

my pi is actively stopping me doing something that i know is right

and then the rest of the time it actually catches a small mistake okay yay it's

Now, maybe the benefits would be more apparent

if I was working with more people also working on the code base,

but it's me and Will, basically,

and I pretty much own all the Python and Rust code,

so it's just for myself, really,

and it doesn't really feel worth it.

Yeah, okay. Interesting.

Okay, let's move out before the lynch mob arrive at the flaming torches.

No, yeah, I don't have a dog in that fight,

but I know that's one of the things that comes up to the steering council all the time.

Yeah, anyways, but I don't have a...

So I wanted to ask you about Janganaut.space.

Oh, yes.

You were one of the navigators on the first pilot program that's just finished.

So can I ask you about your experience there?

your thoughts because yeah from the outside looks like a wonderful thing yeah i i'm i'm really glad

um i took my part um i think uh sarah boyce uh was the person who um asked me if i wanted to

be a navigator and i said yeah all right um and yeah it's um it's been good um it was i had

three mentees and they all got stuff landed in django and um i'm glad i did it was um good to

see them uh getting this stuff in and having the confidence to work with Django and so on

and could ask was it a big commitment for you as a navigator because I think there's a billion

people listening to this podcast who would be qualified to do it and we've had the organizers

on you know Sarah come on talk about it and pick it up so but you who played the navigator role

what did you have to do what if you know someone's like well maybe i could be a navigator what so

what's involved um yeah i we scheduled a once a week catch-up call with my janganauts and

that ended up lasting about 15 minutes most days um so that was fairly low commitment the other

thing that i did was i tried to keep an eye on the pull requests that they had and give initial

review um and uh i think that went fairly smoothly as well um the time commitment from my point of

wasn't wasn't too onerous so if somebody's in doubt yeah go for it you can always um drop out

from doing it again if you don't like it so will you will you do it again or are you going to step

out i i i have um said that i'm happy to do it again so okay because i think that's one of the

things that's been discussed is the idea that not having the same people every every time you know

once twice three times and then step away like a tag team sort of thing um i keep it fresh i also

said that if if they had too many people wanting to be navigators i was happy to step back so

and i haven't heard yet whether that is the case so we'll see okay well i don't know is i forget

what the deadline is but i i suspect there'll be a lot more applicants uh for this second the

but the first kind of open open round than there were the first time so i imagine they'll be

yeah we should have one of them on to me oh actually we're going to have um sarah on

uh coming up soon so we can ask her to give us a recap of it i think in yeah sarah sarah's going

to come on and talk so it's all right we had sarah b before oh yeah sorry yeah yeah two sarah

sorry sorry yeah sorry django sarah con yeah

nice one question i had for you actually i don't know uh on orms and it sounds like you

primarily work with django but have you had a chance to look at any other web orms and take

inspiration or um was that part of your process or is you've been mainly fighting with sequel and

django i it's mainly been sequel and django i looking at other other work in this space is

something that does sound valuable but it's not something i've got around to doing yeah yeah fair

enough yeah i'm just a bit too focused on okay what's the thing right in front of me or or i'm

taking a break until the next conference depending on my mood yeah well that would be it would be i

mean carlton you can probably maybe speak to this i mean sequel alchemy is certainly historically

has been spoken of as having some features that the jenga orm does not but i don't know if it's

as active as the jenga orm is i suspect not but i i can't speak to that yeah who knows um

no i'm not an i'm not a big orm depth expert so i've used sequel alchemy a few times and thought

yeah it's it's it's an orm um like i think the big thing is that like um jango's the jango orm

is slightly more um objecty if that makes sense like sequel alchemy that doesn't hide away the

sequel quite as much like aware that you're building a select query or you're aware that

you're um building whatever is django it's not quite so clear um so i don't know i don't know

yeah i think django is slowly moving more in the direction of matching the sql a bit more

explicitly i mean all the expressions are now more directly named after the equivalent sql concept and

check constraints that's named after the database name for it whereas early stuff like filter

is more our own naming so there's some value in matching up well to the database concept that

you're implementing that we've been doing in more recent years well i have one more carlton and then

i'll let you fill up the time but uh so colo obviously it's so we had david kramer from

sentry on a little while back and he was talking about how sentry developed initially as an

improved django debug toolbar and in a sense colo is also like that so my question to you is

beyond where it is to now where do you see potentially going to you know in the future

if things keep going swimmingly my personal wish list for colo is i want us to be a go-to tool for

local development um i want us to have a good story for not just django but um flask fast api

maybe even scientific python though i don't know if that's possible um that's where i'd like to go

but um i don't know if it's where we'll end up going

I'd also like to be able to

I'd like to be able to

have a way of people contributing plugins to it so that we don't have to do all the integrations

um that's something that's always simmering in the back of my mind how are we going to do that

but at the moment the test generation is our main focus i think so that's where a lot of our

thinking and um development time is going at the moment yeah because the the visualization and the

drilling down and the jumping to the code that's all in place right i mean it's you know it's quite

an impressive little tool to be honest yeah well no i mean just thinking on that like the question

is like at some point it has there has to be a business that too towards it so it's moment

colo is free um and i guess that the sort of um the big one is teams right you is to be able to

provide some kind of help at a team level where you know startup 5-10 developers they can get a

subscription yeah give it to everybody and you know yeah we have some small dabblings in that

direction but um nothing very concrete at this point um but yes i would i would love for curler

to be self-sustaining yeah that gives it the longevity no indeed well we've been not doing

nothing but asking you questions is there anything you wanted to speak of since you're on a in the

any things that are of interest or with work or the community you wanted to mention

um i know that's a big big one i just threw at you so it's fine to it's

we've mentioned a lot of what's on my mind at the moment um

uh i guess there's there's been a fair bit of um conversations on um the forum and discord

recently about uh consensus and how stuff that um a lot of um suggestions to for changes to jango

going at the issue tracker and a fair number of them just get accepted and that's great

But when they're rejected, the response is, okay, if you disagree, take that to the forum or use it to be the mailing list or whatever.

And then it feels like it can be a lot more of a draining process to try and make your case and get something in.

And I think my wish list for Django going forward is that we make that less draining on contributors somehow.

When they've got an idea and it's not immediately met with, yes, let's do that.

find a way to make that smoother and i'm hoping that we can improve that experience somewhat in

the future yeah the the default has been for many years that um a sort of change required a consensus

in favor of it yeah and so the burden of the burden is on the new feature yeah so the the

default is is no basically i mean you know to basically any change um and that's that can be

massively frustrating when that's the feature you want yeah um i think one of the things that

has kept me around in django is i've largely only picked things to work on that were already

accepted if i'd come along with a particular feature that i particularly wanted in but i was

met with resistance i might not have stuck around so easily yeah so just to the flip side of it is

of course the stability yes is the the the reason why the historical policy was you know requiring

the consensus for the change was the keeping django stable and if you i was on a the django

developers mailing list searching for some things i've came across a thread from i don't know 2015

where there was massive gripes about the massive churn

between versions and the difficulty of updating.

And looking back now at 2023 to something from 2015,

you think there's no churn.

Like you might, oh yeah, I have to tweak a setting

and I've got two and a half years to tweak that setting

before it becomes pressing.

It's really not, it's not a burden.

And most times it's pip install, that's you, Django, run your tests.

Oh, it's done.

come on the latest version took you 10 minutes that wasn't the case yeah that really wasn't

yeah i i i have some memories of upgrading back in the 1.x days i do remember it but i think

perhaps we've overshot and gone a bit too conservative now yeah possibly possibly well

one thing i've gone i say uh to what you were saying lily one thing i've taken heart with is

Paolo has this idea of Django sprints.

Oh, yes.

He just posted another article about pushing that forward because, yeah, there's no reason why it has to just be at the end of DjangoCon conferences.

And so perhaps I hope that that becomes a thing and that could be a way where someone, even if it's turned down, they can still meet up.

And, you know, there's nothing like in-person progress to or in-person to make progress or, you know, talk it out in a way you can't even on the forum.

So perhaps that's one way.

Yeah.

i i hope so um yeah there's yeah there's been a number of things recently i mean i guess

grand scheme actual raw numbers probably not that many but the it feels like a lot because

there's so they generate so much discussion and it feels like such an uphill battle

yeah it can be it can be just like long grass and it's like how do i move this feature

forward yeah it's like not sure i can or not sure i can quickly um and that first interaction is so

important when you just it takes so much effort and self-belief just to put it out there and then

you're you're hypersensitive to the response yeah and unfortunately yeah it can be crushing even

when someone who's just busy just says no yeah and they don't so there is some but you know

jango nut programs and others we can see that there are people and faces and

the community is friendly even if the interfaces aren't always as friendly actually that was one

of the points that sarah boyce was making about um she's a big fan of the discord and how that

sort of interaction more aligns with i guess modern communication and certainly is more

friendly than just an email service email listserv yeah i definitely agree um

i also think that for better and for worse django has a reputation of i mean for better it's really

stable and um uh slow moving but also for worse it's maybe really missing out on um opportunities

it could be providing to.

Is Django going to continue to be picked for new projects?

Some people I've talked to think,

no, you're only going to pick Django

if you already know it or it's a maintenance.

People have been saying that for a decade and a half.

Would they pick instead?

Is there a default though?

Probably something like fast API

or something even not in Python.

But I mean, yeah, it's as old as Django.

It's like a hacker news post.

Django still exists and it works.

Yeah, it's bad.

There's something valid there, though, right?

I mean, I mean, certainly there's just the marketing of Django.

This is one of the topics on the members forum about just the website and things which there is work being done.

So, yeah, how do we get across?

I mean, that's one of things I've been most heartened by is Sarah Boyce has really taken the lead on the upgrades to Django section on the Django News newsletter and just showing it's just it's so active.

There's I feel like it's 12 to 15 a week of changes.

And, you know, so some sort of marketing sheen on what's actually happening.

But because we're mainly volunteers, we don't have the muscle to do it or the time to do it.

I'm hopeful that there is currently a bit of an influx of energy happening to Django.

And that will lead to it continuing to flourish.

It certainly feels like it for me, right?

I mean, there was this, or being on the board during COVID, it definitely felt a little bit like end of days holding on.

But, you know, now that we have the conferences and everything and new initiatives and new people, I mean, so many people are going out for the board now that there's the new board, that there's even some discussion of perhaps we should expand the board or, you know, find a way to take advantage of people who want to contribute in a way that we're not.

I had to look at the candidates and I was like, I have no idea how to rank these.

They all look amazing.

Yeah, right.

I mean, yeah, it's a good, like, really strong position.

um carlton you had something to say i interrupted you about no no no i just totally you know i agree

i i don't i think it's i don't really buy the old jango mortal danger line i've heard i've been

hearing that for 15 years and it's no true it's more about the perception i think independently

of sure but dango's been old the old fuddy-duddy for you know for a long time now and it i i don't

buy it's um there's an existential threat i look at the changes that come in every version i think

yeah this is positive i do hear you know um what lily's saying about you know can we can we tweak

the way we um discuss the features can we think about ways of pushing forward i think you know

there's not enough there's too much of a barrier to getting to a full sort of formal depth this

this Django enhancement proposal that it's too it should be a lightweight thing it should be look

here's my here's my proposal can we discuss it can we feedback on an actual written spec because

you know if you want to make a major feature change in any project to write up a little

spec is not a big ask right that should be easy it should be we should be encouraging people to

write writing third-party packages we should be saying look look this is what I've done

how can i can i pull it in and yeah we should be open and you know let's do all of those things

that's all great i don't buy that jango's index essential threat if we don't but yes let's let's

take the new energy and let's go with it and it is wonderful to see just so many young faces like

we went to the that first conference back after the covid to two three years where we didn't have

it and then we were back and it was like yes all the old faces yes all the new faces too and it's

like oh wow yes and i said um so many times this year that i'm as excited about django and where

it's going as i've been for a long long long time i think it's really healthy place that we're in

and that's just wonderful well i do have a shout out to django con us which i don't think either

viewer at was, I think it was the, I heard many people saying it was the most diverse in all

respects, uh, attendance that they've ever had in terms of there was huge numbers of people from

Africa, people from different industries, different, I mean, just, it wasn't the largest

DjangoCon US we've ever had, but the breadth of people and backgrounds and experiences certainly

felt and seemed to be the largest yet. So that was, I took a lot of heart from that as did,

think most of the people there yeah and jangakon africa as well i right we need to have someone

come on and maybe maybe ask marish to or one of the organizers to um speak to that well i think

we're we're pretty much um out of time at this point unless there's any is there anything we

didn't cover lily or managed to throw enough questions your way i think there's always more

stuff that could be talked about but i'm hesitant to open some cans of worms so maybe another

podcast okay well we'll have links to everything we discussed especially colo for django which

everyone should check out and um is there is there any way that would you like if anyone doesn't

already know about it who's listening and tries it is there a way to provide feedback or what

you ask someone to to do who downloads it and for the first time yeah um we've got a small

discord of our own which is mainly used for people coming and asking uh questions for help um we have

some documentation if um if the documentation is unclear please let us know it's something that

um i want to be good but i'm not a technical writer so um uh we have an issue tracker as well

um and um i think you can also uh schedule time with will to um come and actively help you um

get started or work through a particular problem or something like that as well

there's lots of different options thank you for taking the time i think we've been trying

planning to do this for quite a while and so i'm very pleased that it came together

and yeah thank you for coming up really good jango chat.com links to everything and we'll

see everyone next time bye-bye bye-bye