← Back to Show Notes

Transcript: Python Tooling - Hynek Schlawack

Hi, this is Will. A quick note that my website, learnjango.com, now supports free tutorials

and premium courses, meaning my three books, Django for Beginners, APIs, and Professionals,

are now available. I'm running a 50% off Black Friday sale until December 1st.

More information in the show notes and later on in the show.

Hi, welcome to another episode of Django Chat, a podcast on the Django web framework. I'm Carlton

Gibson, joined us ever by Will Vinson. Hello, Will.

Hi, Carlton.

Hello, Will.

And this week we've got with us Hinnik Twalek, who's Python core contributor and all-round, well, you know, I'm a big fan.

So, hello, Hinnik. Thank you for joining us.

Thank you for having me.

And I love how everybody has problems to peg me anywhere because I'm so over the place that it's just this dude in Python and we love him.

Yeah, no, that's exactly it because I was going to say you're a Python core team, but you are on the Python core team.

But that's not where you hang out mostly these days, right?

Yeah, I'm not, sadly.

Like, my time is finite.

Are you more on the Go side of things?

Or you're still equally in the Python world?

Or how would you divide that time?

No, no, no, no.

I'm on the Python side.

Okay.

But a vast majority.

Like, we use Go only when we need something that is faster than Python,

which is very rare.

Like, Python is fine for us most of the time.

Or when we need a single binary, which happens more often.

We need a setUID or something like that.

otherwise it's all python okay and so i'm just going to get jumped straight into there because

um you talk about being past faster than python um now there's this whole python 3.13 and free

threading and things like that coming along is that going to make a lot of difference because

i'm quite excited about it i'm like this means i can stick with python i can do my threading my

template rendering in a thread and it won't slow down but what's your view because you're a bit

more closer to the metal i think um i think i'll give you the most senior software engineer answer

that there can be uh it depends so good yeah because let's be honest we've been doing pretty

fine for like 30 years without free threading right so um i am absolutely pro free threading

I love it.

I'm very excited.

I was one of the people advocating for this experiment to start.

But you need a parallelizable problem to take advantage of parallelization, right?

And people also are not great at writing parallel code,

which will probably change because in Python,

we do not have good apis for parallelism with threads because it doesn't make a lot of sense

they are just not great um at some point you just run into the gill so nobody ever took the time to

like build really good abstractions for free threading and this is something i'm really

excited about when we will build that but uh i don't i don't expect any world-changing uh

things happening right now or for most people but i believe for many people it will be life-changing

like when they have computational things right like the data science people i think they will

be much happier than us although their stuff is already usually enforced right on c and uh

it doesn't have to go so we will see but um it is okay and so to be clear it is necessary to

future proof python i think that is true but i don't expect that uh our code suddenly but i'm

gonna be super fast or something it's just we will see it will be an evolution i think it will

be more boring than most people think okay so no no instant new world i was going to ask them what

about the sub interpreters thing because it was all sub interpreters sub interpreters then

suddenly free threading came out of the the blue and then i've hardly heard about sub interpreters

for a while yeah i mean uh eric snow still working on them and talking about them and

And I think they are also exciting and I think they are orthogonal to free threading.

And I think if they ever reach a certain stage and don't get like the whole oxygen pull out of the room, they can also be very interesting in the future.

But they have some limitations, right?

Like you can only exchange certain types of data between sub-interpreters while you can share anything using threads, which is both good and bad.

which which is of course the problem with yeah so there's been this this presentation by yuri

solivanov at last pycon where he talked about this amazing um i don't even remember how the

proper name for that is but it's these are the structures that are uh they don't change but

you can change them in a way that they remember the changes so basically applying patches to

to dictionaries and to lists and there that makes them frozen and you can share them across

barriers like sub-interpreters i think the correct name is stms or something like that

but uh didn't go any anywhere yet it's still not public i think it's in their async pg or in their

hdb report somewhere but you would have to copy it out so i guess my one more question in this

sort of way then we should cut back to the beginning because we didn't even ask you or

ask anything we just jumped straight into performance is do you think then that these

these over the medium term these techniques will keep python competitive with you know the goes

and the rusts of the world i mean i mean there's two questions right uh what is medium term for you

and python right now is the most used programming language in the world right

and the most popular ones like asking if it's competitive is is kind of weird um

i mean but there is this thing at the moment where it's like if you don't write rewrite

everything in rust the world will end and i know that we have that every time there's a new

technology or a new option but yeah you know yeah again i think it's it's important it will

enable new things but it is and i said before when we were like advocating for these changes

we do not have the fantasy right now or the imagination what we could get out of this

because we don't have it right um we cannot imagine from the primitives that we have now

what could be we will have to do we have to try it we have to play with that and then probably

someday out of some company will come some amazing framework that will make everything easier and

everything will just fly and everybody will be happy but um i don't think you can expect like

there's gonna be something in a year or something there's gonna be some nice things um i think async

IO works a little bit better when you have free threading

and things like that.

But it will take

something big that

will add an abstraction that people love

to use to be an actual change.

But again,

it's great for the future.

Alright, I'll ask a question.

So we have a big Google Doc of things

we want to discuss, but I wanted to make sure we ask about

your day job, which is at

VarioMedia? I'm probably saying

that wrong. It's not a real word,

right? Okay. So we have German

companies we call it vario media okay nobody's get offended if you pronounce it english yeah

we are web hosting company we do email hosting we are domain registrar and uh we run a kind of

tight ship with not a very big technical team which informs a lot of the things that i do and

say like i cannot afford having um janky systems that page someone every night or something like

because that someone is always me so i cannot just uh push something to production and hope

someone else will have to deal with that yeah we're only serving the german-speaking market

so uh that's why probably not a lot of your listeners have heard of us and our hosting is

mostly lamp so for the web hosting part yeah so yeah exciting times right now with wordpress

Well, I can't...

If you go hot, I go mad.

You can't leave us there.

Yeah, how is...

Is that a model for, you know,

the Python and Django worlds, you think?

Have a dictator who goes crazy?

What do you mean?

Have a dictator who goes crazy?

Someone's going rogue?

Yeah.

I mean, Guido was apparently smart enough

to just abdicate before he can get crazy, right?

Right, right.

It seems like it just...

Maybe it's almost...

I mean, that's the thing,

is that Matt had a reputation,

deserved or not,

for being relatively sane

and a, you know, good in quotes person.

And so it's...

Yeah, I remember early Masodo

and he was like this,

he was kind of celebrated, right?

Like he took over Tumblr

and integrating things into the Fediverse.

Right.

I mean, given enough time

and enough money and power

and I guess this is the lab experiment playing out.

Yeah, hell hath no fury

like a billionaire scorned

or something like that.

Right, I know.

Well, I mean, it's interesting

in the Django space for, you know, Wagtail, right?

Which has been a big thing for a long time,

but especially as people are starting finally to think

maybe WordPress isn't all it's, you know,

maybe we should look beyond WordPress.

I'm curious to see if that brings more momentum

to things like Wagtail.

What do you, Carlton, you're making a-

The thing with WordPress is that it's PHP

and it's dramatically easier to deploy

than anything that will ever be with python so um you can just drop a bunch of files on a server and

it works and this is why it's successful like uh you cannot win the war against this one on

technical merits like with feature lists or something that's just not gonna work i think

i think there's it's more likely that there's gonna be an open source a new open source fork

of wordpress my sort of experience with it was of trying to sell alternatives was always it was

about plugins and themes it was you know people didn't care whether it was php or python or ruby

or whatever but what they cared about was plugins and themes and and only because i didn't know how

much of a pain it is to run right well i'm i'm curious your so your your day job i mean clearly

it's interesting and challenging to you like what are kind of the things that keep you engaged with

it right because you could be doing we're going to talk about all these open source things that

you're doing um but of all the challenges you could take like this seems to be one that you

seem to you know enjoy and stick with um i'm just curious if you could talk about running a web

hosting kind of company because that's something a little different than most of our guests are

working on um i mean my open source projects are results of my work at the web hosting company

because i don't do open source just for fun like these are projects that i need that i use myself

because I don't have time to maintain software that I'm not using.

So this is all our stuff that we use.

So you can see by that alone that my challenges are quite wide.

Okay, fair enough.

This is probably the reason why I've stayed there for over 20 years

is because thanks to the fact that we are a small team,

I have a lot of different jobs in a way.

I don't think I could work in a company where I just work on one Django application eight hours a day.

So this is not my life.

I have a wide variety.

I mean, there's some Go.

I write web services.

I write async IO code.

Our domain registry thing is done in async IO and works pretty well, actually.

So, yeah, I wear a lot of hats and I can kind of sort of decide myself when I change them.

So there's a lot of freedom.

I mean, there's a lot of pressure and responsibility because, again, if something breaks, it's my fault and I have to fix it myself.

But I have a lot of challenges to choose from.

And, of course, there's this thing that the thing that I do, I am the best at the company.

There's nobody over me.

I cannot get promoted or anything like that.

So I've hit the ceiling here, which is why I have this understanding with the company that they let me work on open source projects and engage in this community.

That was like literally what I told them to either you give me opportunity to learn from others there by serving a community, by having an exchange with the community, or I will have to go somewhere where I can grow professionally.

Well, here we are.

Yeah, that kind of autonomy is deeply rewarding, right?

It is. It is. It is. I'm a big fan for like these slow productivity books from Colin Newport and those things. And it's like this career capital that you can build up. And it is not that I'm working less. It is just that I work more on things that interest me right in the moment, right?

Like, I could take, like, two or three weeks off and transfer our projects to UV and just do this deep research of UV.

I don't, like, if I don't have a deadline, I have time for R&D, basically.

Yeah.

On the other hand, nobody else is doing the R&D.

So this is the other side, right?

Like, what I don't do doesn't happen.

Well, that's sort of the dream, right?

I mean, Carlton, for you, Carlton, right?

like coming off of being a fellow for five years speaking of autonomy you know look at what you and

marius are doing like you're not going and being engineer a thousand at fang right because it just

doesn't translate no so yeah i'm just working on um a single django app eight hours a day

but it's just you but it's just you though but yeah but it's just it but it's me and i get to

choose it and i get to set the the thing and i'm you know it's it's not a 10 year old project yet

it's so you know it's still very much fleshing out very much enjoying but it is you know me

driving the direction and that's the rewarding bit it's yeah fantastic um you mentioned cal

newport in it i've heard you talk about hustle culture and you know yeah um yeah i mean not a

fan right like neither him nor myself like um i mean there's treading that balance between doing

your thing and promoting it and but and just being out there sort of slimily selling it yeah i mean

that's another hustle thing right like hustle culture can mean different things like uh the

thing i usually talk about is that uh just do more do it now do it as fast as possible

and then there's of course this constant hustling and shilling and uh i just don't feel good about

that so i don't do that and uh yeah it might be that's just performance not great for my

coding or art it's just like performance coding and art right if you're spending all your time

talking about how hard you're working how hard are you actually working is like right it's like

can you go when you go up to meetups when i lived in san francisco for a while i tried to go to

meetups and they're great at first but then you realize it's like the same people saying having

the same conversations and everyone who's actually doing something is like hunkered down doing the

work rather than bro i don't even sleep anymore you know i'll say one of the things i found a

little disappointing about the Bay area was realizing that even though everyone was, you

know, a lot of people were, you know, nerds in quotes, they were still super all the negative

male stereotypes. So it wasn't just like a, you don't have to be a jock to fulfill some of those.

Anyways, I think we have a name for that.

Um, yeah. Okay. I want to ask one more question. Then I, I know Carlton has a bunch, but so I,

Well, I have to bring up, you have a 2011 blog post where you talk about, quote, Django's ORM is still a joke and reference that you preferred Flask and Pyramid.

So I have to ask, I know it's 13 years ago, do you still feel that way and maybe provide more context around that?

Okay, the quote is very much informed by Buck and Django that, by the way, is still open and can legally drink soon.

It's not the one that is linked in a post, but...

We'll put it in.

Yeah, I have a fun story.

I have a fun story for you.

So as part of R&D, I was trying out Django to use in our systems,

and it ended very, very poorly.

Mostly, like the key reason is that Django is a great framework

for Greenfield projects, but we do very few of those.

we have this existing architecture

the company

exists for like 25-26

years now

we run a weird database

and I had to

fight Django

a lot more than it was helping me

to make it fit our

infrastructure and what happened

there is that we have a

we have

a database table that

has a composite primary key

ah that's nearly coming in and i'm just make i make the long story short i changed the password

of everybody in our company because the table was the primary key was username and domain

and the orm never told me that it's only gonna have the last primary key you define

so when I

set the password hash

for a certain user

I change it for everybody

in the company

and all of our bots and whatever

so that was a lot of work to fix again

yes I can imagine

I can imagine

once upon a time I forgot a where clause

on a delete query

that went very wrong

for similar reasons

well I didn't forget anything I just didn't know

and Django didn't tell me

You know, so that little negative story about Django from time to time.

By the way, the Google Summer of Code project from this year is going to finally get the composite primary keys moving forward.

That's going in and after, I don't know, 20 years almost.

20, 19 years. The bucket's open for 19 years. I checked today.

Exactly, exactly.

But that ties into, you know, a lot of what we're going to go on and talk about is that Django does things a particular way.

and it's not necessarily the way you might do it from a kind of pure perspective so let's just put

that out there and then go and talk about your open source work because you've done so much and

i do want to get onto it and cover it with the with the listeners i think the thing you're

probably most famous for is the attas package is that fair yeah that's definitely the one with the

most downloads and with the biggest impact on python itself yes so i mean that's the attas for

But for people who don't know, it enables you to define a kind of very, very succinct class.

And it was the direct inspiration for data classes, which I think most people would have known of.

Yes, that's correct.

Like, I mean, adders predates type hints.

So that's a thing.

There's this funny syntax most people have forgotten about, but people back then really loved.

The package name is just ATTR, and the decorator is at adder.s, so adders.

And you define attributes by assigning them

to atter.ib, like atrip.

Hilariously, not everybody got it.

And people just imported those symbols.

And there was like at s class and then x equal ip.

Yeah, so anyway, this was like the first good class building

toolkit for Python.

And it was really popular, too.

At some point, people started asking

to get something like this into the standard library.

I still remember I got the email from Guido when I was at Amsterdam airport,

which is a good coincidence, traveling to PyCon US.

And we met up there with Eric Smith and did the first planning stage of data classes.

Okay. I mean, it's difficult to get something into Python, right?

I mean, like something big like that.

Because normally the talk is always about trimming it down and having less.

Yeah, it's usually not a good idea to put an existing package into the standard library.

like we have this moniker of saying that uh packages go to the standard library to die

and it's just that's a good one so we have this same debate in in django right so python was

is batteries included and i i remember when i first picked up python i came from php while i

picked up python it was just amazing because you know the standard library providers i don't know

most of the things i wanted um and django is very much a batteries included web framework but we

have this same tension between keeping things maintainable keeping them fresh and being

batteries included because if you trim everything away then where do you go you know the example i

always have is a um is a production web server i'd love it if there was a production grade web

server in the standard library so i could just sort of import it and create you know but i

understand why it's not there but in the same time i want it because i want i like that batteries

included philosophy i yeah i kind of miss it in a way so what many people don't quite understand and

that includes also when we talk about packaging like i made a few videos on packaging and i get

like these comments like i wish this would be in python that would be done by python but there is

no such thing as the python there's just a bunch of core developers who are developing c python

myself included, albeit not very active.

And they are not necessarily equipped

to write a production-ready web server.

Right, web server, yeah, right.

They have no interest in solving packaging problems.

I mean, just because you're a Python core developer

doesn't mean that you're capable

or interested in these kind of problems, right?

We cannot just tell them to do that

because nobody's paying them to do that.

So this is just like a discussion

where people just quite understand

what they're asking for

because it's not an abstract concept, right?

It's not like Mr. Python can reallocate developers

to do something different.

It's just a bunch of people with own interests.

Yeah, no, no, no, entirely.

I mean, I guess, do you have any thoughts then on,

because this is the other solution,

is let's just put everything on pip

and then ask people to install it.

But the problem then is

there's an awful lot of things on PyPI.

um and how do you how is it how's a newcomer to the community do you find the right packages the

right reason how am i ever going to go and find at us short of being in the python community and

reading the blogs and hearing it come up how am i going to discover it so many branches that we

could take right now uh obviously they should just listen to your podcast to learn about uh

important things like that yes um so we've had this in basically this the same discussion at a

Core, not Sprint, but Core, what's the name?

Core Summit, Core Summit at Python US.

Language Summit.

Language Summit, yes.

Sorry, I'll start again.

So we've had this topic at a Language Summit

a few years ago when I was there too.

And it was the question,

what kind of things should we put into the standard library and why?

And my answer back then was already

that we should put things there

that make people write better Python,

that leads them to a better design.

For example, data classes,

as much as I'm interested in using address instead,

I understand that data classes are a game changer

in making people write classes

into just screwing around with dictionaries

or, God forbid, named tuples.

And this is the things that should be in a standard library,

things that lead people to writing good Python.

And something, I don't want a web server in Python proper

because I want there to be competing ones.

I mean, there's this new one called Grainian,

which is written in Rust.

So there's no way that could be in CPython.

And now we're talking about it.

If we put a production-ready web server into CPython,

as the name says, it would be written in C,

which is illegal, as we all know now.

and um that's not great right i don't want a um freshly written web server written in c

in my standout library so yeah it was yeah i mean the the example came back to me this week i saw

julia evans who does the web comics the web scene and uh she listed um had a list of points about go

that she liked and one of those points was that it's got a production ready web server in it and

it came back to me i was like ah yes that was that was something i but this is a perfect example

because there is no mr python but there is absolutely uh a google and google needs a

production ready web server so they can just as well put it into the go standard library and write

it in whatever they want to write it right so that's the big difference right that's yeah that's

lovely okay brilliant so swing back to attis can you so i'm i use attis all the time i really like

kit i think it's it's you know as you say it lets you define these little classes and they

so then when you're using them you're not indexing into dictionaries you're not missing keys you get

type you know autocomplete and you get all of the other things there's one thing that you don't

include and you deliberately don't include it i wanted to talk to you about that and that's

validation like data validation and you've got this line in the docs about how data validation

should happen outside your could you just explain that tape because you know it's not there are

are other opinions and i'd love to hear you talk on that yeah so this this harks back to orms man

like we didn't we never finished the topic so this is great no we we're getting to it we're

getting to it no no this this is perfect so um how do i start this so yes uh address does not do

uh validation by itself i mean it does have validators and these kind of things but it is

not primarily meant to do validation because i want my my um my data that i've worked that i've

my business code with i don't want that to do validation i don't want to have any information

about how the code is coming from or whatever like my core domain model i want to have pure

such that i can uh such such that it is in a perfect shape for me to write that uh business

code and there's been an amazing talk at the last um pike escates called the rising sea where the

speaker shows how a problem is radically easier to solve if you have proper data model around that

if you take the first if you first take the step to transform the data that is coming in

and he's using i think some something from code advent and transform it into something you can

work with and then solve the problem and that makes it the code that solves the problem radically

radically simpler and easier to understand and shorter and nicer and everything and this is where

this comes in like um i don't mind the existence of pidentic or whatever like it's popular right

now but i think it is a problem when we use the same classes we use for validation also for our

business logic and this is the same thing with ORMs because these are two kinds of design pressure

from two sides like the ORM is basically your data model it's the tables so your models in your code

are going to reflect that fact I mean you can probably rename fields and do some joints and

whatever but in the end this is called table driven design because because the models that

come out of your tables are defined by the table and in my experience i mean maybe i'm weird but

in my experience you maybe have a say on how these tables look at the beginning but over time you lose

control over the tables one way or another maybe another team is working on that or someone else

is relying on it. This all should

not happen. This is all bad, but it

happens all the time.

Talk to anybody who's running production code

if they can just change

their data model. They probably

can't. So that's

what's coming from the database.

Validation is the same thing

just from the other side. You probably

cannot just change your API,

the JSON structures that are coming in

once you've defined them, right?

So now you have this

really, you have this

two types of design pressure coming from two sides and in the middle is your business code

and business code is supposed to be the pure one the important one it makes decisions if someone

goes to jail or if someone gets uh married or whatever right and uh this code in my opinion

should not be affected by how the json is looking from the outside because someone decided five

years ago it should be so this doesn't mean that for example pidentic is bad absolutely not i mean

people can use it and then transform into the data that they need for their business code but

nobody does that like i've been literally asked some from someone like usually people ask me why

should i use others if there's data classes so this time someone asked me why should i use data

classes if there's pidentic and yeah right this to me is an attractive nuisance because

you you do these two things like you have this data coming uh from the outside and from the

database and it's extra work to shape them so you probably are not gonna transform it and you end up

with this weird code that is affected by how someone decided five years ago how to make the

tables on how to make the API. So this is the thought behind that. And this is why I prefer

other ways to do validation. And I also I feel like you need normal classes too, at some point.

So it's just more layered. Hi, this is Will again. My website learnjango.com is now fully

live and I'm having a Black Friday sale 50% off all three of my books. With the new site,

you get lifetime access and free updates, meaning you'll always have access to the latest version

of everything. I've spent almost a year working on it and managing all the user permissions,

payments, and the rest. Carlton and I will have a future episode taking a deep dive look into our

respective projects this past year. But if you want to support me and the show and get a killer

discount, now is a good time to take advantage of the Black Friday sale, which is good through

December 1st. And the analogy with the Django projects is exactly right, is that you start off,

you've got these nice models, they're really clean, they're tidy, they're expressive, they're

quick and then over time you've got i've got an extra method here i've got an extra field here i

knew it does get more complex and then what people end up doing is creating a kind of

a mapping layer to move from the the table gateway which is the the the django model into

some more business logic type cleaner models or service layer or a you know a layer that's

decoupled from that narrow rm but i mean that's the right way right i i just don't i'm not sure

if it's the most common way well i think a lot of people there's that tension right between yeah

carrying on and struggling with or you know and it's it's what's interesting is when do you make

this this change or when at what point is it worth because that extra step that's what i said

right it's friction like you have this these classes and they almost work so you either you

can make this nice transformation that you just described or you just make it somehow do right

if statement here if statement there and you end up with terrible business code

and but that's the that's the same with any growing software project right it's not dependent

on rms or data mapping classes or you know well not necessarily because you can control

your uh the fringes of your code so so i think like my job is to deal with whatever is coming

from the outside and i consider the database also the the outside and i can transform it

into something i want to use and the same same goes the other way i this is in my power i

can write some code and if i don't do that that's on me and i'm just being lazy and uh i deserve

what i get but there is no tension if i do it from the beginning if from the beginning i say okay

i'm using uh a validation library that just transforms into normal classes on the one side

and on the other side i use repositories or something like sqlc that uh spits out normal

classes and then just control those because then there's no friction to add it right in the other

case you already have something that's almost working and then adding a little bit of clutches

and a little bit of dirty works here and there it's the easier way to add a whole layer of

transformations and it's also slower it's like it's another indirection yeah no yeah it's that

that that notion of an attractive nuisance which i think is quite is the nice metaphor it's like

It pulls you into doing the wrong thing in a way.

I want to ask you about UV and your YouTube channel.

But before we switch, you have a number of open source packages.

Are there any in particular you want to talk about or call out?

I mean, there's too many for us to go through all of them.

But are there any that you're particularly interested in or are working on at the moment beyond adders?

If I have, like, my most underappreciated project, I think, is services.

For many reasons.

For many reasons.

And I understand those reasons.

Okay, well, tell us.

Give us the pitch.

Give us the pitch.

That's the beginning.

It's so hard to pitch, like, especially to Django people, because you're just used that everything is a global variable somewhere.

Like animals.

That was not meant at Django.

I just have a friend that I have this constant discussion

because he does the same thing in other frameworks too

because he's convinced that having singletons in a module

is the better way.

And actually he says if it's good enough for Django,

it's good enough for me.

So fair enough.

So the thing about services,

it is kind of hard to explain in a general way

if the person who's listening

is not already cognizant of the problem it's trying to solve.

I mean, everybody heard of dependency injection

at some point in their life,

and they probably think it's something with Java and XML.

And one of my, actually my second YouTube video

was about how dependency injection

is actually just passing arguments into callables

and by that way, making things testable.

And how you get those things

that you pass into those callables,

there's different ways to do that.

There's dependency injection frameworks that I personally find complicated.

And then there's something that's called service location, which is what services is doing.

And the big picture is that you have a registry where you define how to create certain objects, as in types.

And then you have, let's just use Django as an example.

Then per Django request, you would have a container

which you can use to create those resources,

which can be database connections,

which can be API clients, it can be anything.

And of course, the boon is that at the end,

first the container cleans it up behind you

so you don't have to make sure

that your API clients are being closed

or whatever resource you're using.

And you can easily replace those objects for testing.

you don't have to monkey patch to replace your database which with with django it's a bit more

complicated but there is no an official django services plugin where also james bennett is part

of so i'm sure it's pretty good okay oh yeah i mean so the two things you mentioned there was

your video where you introduced this um we talked mainly about dependency injection but then you

mentioned services at the end and you had a lovely line in there which just when you said it i was

like, oh, yes, is that all side effects, anything that can happen, like you write to a file,

make a network request, make a database thing, all side effects happen through an object

that's passed into the function.

And you say, this is the key bit, right?

Is that instead of having the database connection card coded in there and you do it, you take

that as the reference.

And then if you want to pass in a mock or a test fake or whatever, you can do that very

easily and test that logic separate to, did it actually make the request or did it actually

you know without having to do at mock you know patch yeah yeah um i just wanted to

to quote brandon roads again where monkey patching is software bankruptcy and he's right

i want to say just one more thing it was underappreciated yeah uh and it is like when

i talk to people about services and describe what it does there's two reactions one reaction

is complete blank stare no idea what i'm talking about and the other is like this look of pain and

recognition and and uh like my ex my at this point my estimation is that the average company has like

3.5 implementations of something like services in their company just half-assed because that's

literally what they say yeah we've did the same thing but it's half-assed so you don't say

and uh the problem with spreading is that this is very much a project that you or a package that

you use when you start a project it's a decision that you do when you start something new it is

non-trivial to apply to an existing project like even i don't i don't use services in all my work

projects like i i just keep adding it when i get to work on my project or two or so every now and

then but it is hard to sell because people only need it maybe once per year or something and

yeah the growth is very slow and again you have to have this intellectual curiosity to just

deal with these kind of things which most people don't have because they don't care or i don't know

okay james james yes james bennett who you mentioned there he wrote an essay a long time

ago again about you know the django patterns and he talks about he was arguing against using a

service layer it's about no lean into the active record record notion um and one of his arguments

that he gave there was that you know people talk about needing a service layer in case you need to

change the db that's just never going to happen in real life and it's you know i'd be interested

to get him on again and talk about you know how he feels and his development of um the django

services like um component i mean i'm not gonna tell uh django people what to do and i think

james is on the money when he says that if you are working within a framework like django you

should you should do as the django notes right like it um it doesn't make a lot of sense to use

a fully-featured framework like Django

and then start using it like Flask.

That's not going to go great.

I mean, I had to do that, basically.

That was what I had to do due to my constraints,

and it was absolutely no fun.

I have replaced at this point zero databases

in my applications over the past 20 years,

so I don't think that is a good argument at all.

like a service layer can you use an orm2 i think like it really depends how you exactly define it

for me a service layer is more defined by the fact that it doesn't do any view things in that sense

and what i'm personally leaning into nowadays is that i'm trying to do something kind of called

like a functional DDD.

It is a lot of inspiration from functional programming

where you do a lot of things with immutable data

and it's basically data in, data out

and then you apply the changes,

which is even more testable than everything else

because it's just data, right?

I would not know how to use something like that

with a heavy framework like Django.

Yeah, it's difficult to bring in these ideas.

You bring them in sort of slowly and think about them piece by piece

rather than bolt.

There is no one step.

Oh, yeah, let's just switch to doing it in a totally different manner.

That doesn't exist.

But to me, a service layer is mostly about controlling transactions

and not doing anything with views,

which already makes it more testable

because you don't have to view stuff to test things.

right and it's like this separation of layers it's um yeah and i understand that repositories

for example are also not very popular in uh django for good reasons but i could just drop

words like cqrs or something like that but that's and we would be here all day yeah okay so look one

more thing i want to talk to you about in this kind of software engineering world i guess it's

just you've got this fantastic talk and essay combination on subclassing and subclassing in

python um and perhaps you could give us your talk and then perhaps we could talk um give us your

overview of that and then perhaps we could talk about you know a couple of examples from the

world because django uses subclassing very heavily right you subclass models to create a model you

subclass the admins to make an atom you subclass the forms to make form so you know you probably

have views on that be interesting to just django is a child of its time right so what what are you

gonna do uh yeah i've been very involved with the twisted project which is from a similar time i

think it's slightly older but it had the same problems like everything is template subclassing

everything is subclass and um but at some point they realized that or we i just have this memory

of us sitting bristol at a sprint and eating thai food and watching this uh seminal talk by

Augie Feichler and Nathaniel Manista

and the name was like the end of object

inheritance and the beginning of a new modularity

and it was kind of the talk that in a

Python community kicked off the

change of

thought that maybe we don't have to subclass

everything and

I'm not sure

where I'm going with that I'm just what I wanted to

say is that Django

just started at a certain time so it

has certain patterns

ingrained

and nobody's gonna rewrite the whole thing

right and it probably also be weird to just change the paradigm suddenly i mean probably

would be the right thing but uh this is hard i think this is really really hard okay so let me

let me phrase it let me give you something guy because i quite like the subclassing i think you

know your subclass and model it's fine and i read your essay and i agree with all you know i kind

of go through and i agree all the points i think but you know also yeah if i just take the model

and subclass to if i just take jango's model base class and then subclass it for my model and i'm

not doing crazy inheritance structures i don't it seems kind of okay you know it's it's like i get

all this behavior i get all the the things defined it's not like i'm losing myself in a million

different call chains and what's so bad i mean you know that's a rhetorical question yes uh i mean

obviously again it's all trade-offs right like in a case of models the subclassing is mostly a

mechanical thing to just decide to do it it could just as well be a class decorator and the difference

between a class decorator and a subclass approach like this which i demonstrated in the talk is

you just get everything inherited into your model so your models are very heavy and it depends from

when that's a problem and when it's not a problem

but you're on a slippery slope either way

but I don't find that kind of subclassing as bad

and again, we are in Python

so some things only work when you do subclassing

but the point that I was making in the talk

is that we have now two languages, Rust and Go

that have proven that you don't need subclassing

as a concept to write great software

you might need subclassing in python to achieve certain effects like you have to subclass

exception or something like that like for ontological reasons and there's different

types of subclassing which i also talk about for example specialization it's fine like go

has specialization they are just cheating they call it embedding it's specialization it's nothing

else it's um it just works in a very narrow way and i use subclassing in the same narrow way

in my code but it is something you have to know like it is an active decision it's active design

decision how you deal with those sharp edges while when you use composition you have to take

effort to to break it you know what i mean like um subclass is basically broken by design you get

everything in all the borders are destroyed um you you get a lot of things happening by accident

and a lot of surprising behaviors and if you go crazy like like you say like if you have like this

whole hierarchy diamond shaped what what do i know right then it gets extra hard so there's

many points that you have to take into account and but of course like just subclassing to effect

to achieve a certain effect is not bad nobody's going to jail for that but you have to be

cognizant of the rules and you have to be cognizant on um how to deal with the complexity

and you don't have to do that with with um with uh jesus christ

with the composition yes oh god sorry that's okay no so so it's probably i guess that the

take on is it's like a cold hygiene thing again like it's another one of these method methods of

making sure you don't fall into you know unmaintained or making your code harder to

maintain in the future as you as you move forward and this is the thing when someone asks me for

advice i'm going to tell them if you don't know don't do subclassing because it means that you

cannot make this decision in an informed way so yeah and you give a good framework yeah what once

you have the knowledge once you know what uh madame liskov is uh telling you to do and these

kind of things sure wield a tool but but it's a much sharper tool than composition okay there's

one it's just one bit on the essay i agree with the essays i read through it there's just one bit

of the essay that i do disagree with it's right at the end you you talk about uh or you give this

example template method as being at the part the sort of pattern you really hate but it's something

that um because writing django web views all the time they're all nine they're all the same you

know all crud views 90 of them are crowd views and 90 of the operations of the crowd views that

are identical and django's class-based views are very much template method right you override

the one little bit you need out of the template in order to make it make your the particular view

that you're working on in that time yeah sure why me hate template method so much yeah i hate them

So much, because they create this cyclical dependency

and this indirection through two classes,

and you're jumping up and down the hierarchies,

which is like the worst part about making things unreadable.

I've just recently written an internal project

where I also use template subclassing

because the development experience of using the resulting object is much better.

So again, it's all a trade-off, right?

But I wouldn't build a whole web framework

based on template subclassing.

But it's the views, right?

You've got an algorithm which has got some known steps,

and those known steps, sometimes you need to plug out a little,

well, that's template method, you know.

Yeah, but it probably could have been solved

with a strategy pattern or something like that, you know.

It just depends where you're putting in the code,

but it's hard to talk about this from thin air.

No, okay.

So we've got here in the Google, you

get 300 million monthly downloads

across all of your software projects.

MARTIN SPLITT- Yeah, but it's more

of Python getting incredibly popular suddenly.

Like, I mean, to get into the top 20 of PyPI downloads,

you need like more than 300 million downloads.

Like this is, it's insane.

Yeah, that is insane.

Okay, go on Will.

Okay, so two things.

We want to talk about UV

and I want to ask about your YouTube channel.

So maybe I'll start with that.

So your videos are fantastic.

I mean, I look at them

and I see you're doing a lot of production

and you've got quite a few of them, how did you actually get started, I guess would be the

question? Because lots of people think, oh yeah, YouTube channel, but it's quite a lot of work

and quite a lot of work to do it well, which I would say you're doing. So what was that journey

on starting your channel and then doing real production? Because again, you're not just

one straight take, you've got graphics and cuts and you're doing a really nice job with it.

Yeah, well, thanks for saying that.

I mean, I disagree.

I think my videos are still terrible, but it's glad that my viewers...

The ones I would do would be way worse, right?

I mean, you know, but I think until you've tried to make a video, just seeing even what you've done, I see hours of time in simple things that someone wouldn't if they hadn't done it themselves.

Yeah, you see absolutely correctly.

it is so much i mean starting the channel was the usual programmer's hubris just thinking that's

how hard can it be and um i'm gonna have to tell you the reasons too i started like reason number

one and that did not work at all is that i hope to just get better at speaking english because i

just get to talk more into the camera but uh that doesn't help if you're recording like one video

per month because because i'm so slow at the production because as you said production is

really hard sorry i have to stop you i mean your english is almost flawless i i don't really know

how much more you would improve to uh thank you for saying that i mean it's true but the main

reason was was really uh the implosion of conference invitations like uh giving conference

talks was my main creative outlet in my life because i cannot draw i cannot clap on a beat

or something like that, but I can give conference talks

and I've been told pretty good ones.

And I derived meaning from that too.

Like I told you before, small company.

So if I want to have an impact to more than 20 people,

I have to do something public.

And the interaction with the community

and the invitations, conferences around the world.

I mean, I've been to Japan, I've been to three US,

I've been to Russia when it still wasn't that bad.

It just stopped in 2019, and whenever I talk to conference organizers,

everybody's just complaining how they are just out of money.

So basically this whole bubble just burst for me.

And my other creative outlet, which is writing, has also kind of tanked

because whatever Twitter and Google are doing there right now,

like everybody who has a blog will tell you,

unless you are not on Hacker News' front page, nobody reads this stuff anymore.

So I decided to go where the people are

and YouTube is apparently the second biggest search engine

in the world nowadays,

probably after TikTok, I'm guessing.

I thought you were going to say Google, but yeah.

There's some logical synergies with conference speaking, right?

Because I'm doing like this talking head video stuff,

which is basically giving a talk.

I had a photography side business many years ago

until I realized that having a photography side business

means looking into Photoshop after work,

which I did not enjoy at all after a while.

But I kind of understand how lighting works.

And it still took me way too long

to figure out how to record in my tiny room here.

But yeah, I'm getting somewhere now.

Right, well, it's all about the key lamp

and then the overhead and then the side one.

You've got the shadows working.

I mean, I can tell because I've, like,

yeah, it's not so easy to do.

Yeah, I basically have one big light

on the right top right uh a small light to the left which is basically just uh like a lamp i mean

it's that is for webcams but i just rotated into me talking to it and i have a silver fill disc

under my chin because i have deep set eyes and uh yeah i record using my iphone to an ssd

oh do you use a microphone cameo or what's it what's it called is it cameo or they're

the software for using your iPhone, it's with a C.

No, no, no, I record directly on the phone.

Like the new iPhones, they have like this raw and log recording,

so very high quality, but it's very big files.

So I'm recording directly to SSDs on that.

So I connect the SSD to it.

There's like this crazy contraption that I connect to my phone,

which is also like leading out an HDMI to my iPad,

so I see what I'm doing because it's right next to a wall

because this room is tiny.

But I record the audio directly to my computer.

And this shouldn't have taken more than one afternoon,

but it took me weeks of experimentation,

and Lukasz Langa was helping me a lot,

especially with the audio and everything.

And, yeah, it's a process, yeah.

But learning about it...

I'm sorry to interrupt.

I was going to ask what video editing software are you using?

So I started using DaVinci Resolve,

which is free, but I did not quite warm up to it.

So I switched to Final Cut Pro,

which is like this Apple software.

And I'm really good with Keynote,

which by the way, I'm using for the slidey stuff

in my videos.

So I felt more at home

because DaVinci Resolve really feels

like a Linux application, which it is.

And like in the best and worst possible way,

it's like super powerful,

but I just couldn't get really happy with that.

Like, so I switched to Final Cut Pro after,

I think with my third video or something like that.

So yeah, this is also very expensive, by the way.

So like Final Cut Pro, 300 bucks,

then you spend even more money

on the plugins and everything, right?

So yeah, I couldn't be doing this

without my GitHub sponsors.

And since I'm talking to one right now,

so thanks for your support.

Well, I think you're right about that.

Thank you for turning out all the great stuff.

Yeah, the conference talks, I mean, our friend Jeff Triplett has just launched Django TV to try to put more light on conference talks.

But conference talks, even though they're available on YouTube, you look at the viewing numbers, it's, you know, a couple hundred, maybe a couple thousand max.

Whereas, I mean, your video…

My subclassing talk has 5,000.

I think this is my best talk I've ever given.

Like in every way, the subclassing one, it has 5,000 views.

And so it's like nothing, right?

Yeah, I know.

Like the UV one had 20,000.

Right, yeah.

Okay, well, I know we're coming up on time.

We have to ask about UV.

Separately, I would ask you a million questions about YouTube.

But so UV, right?

So you have, I think, two main videos, right?

Like one asking, is it the answer?

And then a second one saying it is the answer.

But what I was really impressed by is you really go in depth.

I think they're both about 20 minutes.

And, you know, so give us the pitch, right?

But I was really impressed.

You could easily have done just a quick clickbait, you know, short thing.

But you really dove into why it's so great, but also how it could be improved going forward.

So you stand by, I guess, as a question, you stand by the most recent video.

You're still on the UV train, and you

think this is the packaging answer we've

been looking for in Python?

Yeah, definitely.

It is like nothing before.

So yeah, for the foreseeable future,

I think it is the future of Python packaging.

So you want to give me pitch for my videos or for UV?

I wasn't quite sure what you were asking for.

Oh, yeah, I guess I do this sometimes.

I just, Carlton knows, I just talk.

I guess I was just saying people should watch the videos, but I was giving you a compliment

that they're really in-depth, you know, so people should go watch them.

You can't sum them up neatly, but I was, yeah, far more in-depth than the usual videos, right?

If I see something on a topic I'm interested in, usually it's someone just saying, this

is interesting, but you, yeah, I guess we don't have time to dive into all the nuance

that you cover, but you do a good job with it.

Yeah, it's mostly a result of lived experience.

I'm not talking about things that I've read up somewhere,

but I've been part of all these shenanigans

around Python packaging.

And I've been around for a long time.

So I remember when setup tools finally got freed

and was taken over by the community.

And when it was a big deal,

I remember when wheels came to life

and it stopped being a big deal to install a binary extension.

So, of course, that's a gift of age, I guess.

So I have the perspective and the context to talk about these things in this way

and just knowing so many of those problems that they are actually solving.

And I have the humility to say that they are not really solving my problems.

Like I was reasonably happy before, like PDM worked great for me.

UV is much faster, but I can see how important UV is

for the Python community because, again,

at a community-wide scope, I don't care about the speed at all,

which also, like, there's been this NPM blog post

about why NPM should not be rewritten in faster languages.

And I think this is a red herring.

Like, if UV would be just as slow as PDM

or pip it still would be a huge deal because people complained about python packaging being

unclear and janky people things were broken and it was unclear what tool to use when there was a

bunch of 90 solutions like and you have to know which 90 where your 100 are in that spectrum so

to use the right tool these are the things that people are complaining about not that pip is too

slow that was never an issue at least not on a serious thing right and um i don't think this

is possible to achieve in python like we've tried and hatch came close but only by using rust helpers

again like uh i think wrote this pie app thing so some rust or zig or c is inevitable but don't

use cc is illegal now at least in the us we all know that but now like making like modularizing

it would make things more complicated again right and you cannot ship like a packaging tool that has

a binary extension that would just make it that would that doesn't make things worse not better

so um so you think it's the one tool thing that's the real it is the one tool that doesn't break

that is my main point and i think that also resonated most with the audience of my video

when i make making this uh this point and i of course i don't want uv to be the only tool right

I want PDM to exist and do well.

I'm happy to keep pip the default installer

so people can use it if they want to.

And I don't want to convince anyone to use UV.

It's fine.

Just use whatever you want, right?

But I'm really glad that we've just solved

the biggest Python problem we've had,

rivaled only by the GIL.

But I think this is a bigger deal than the GIL

because people run only months later

to using python into threading problems but the initial impression of installing python of using

python of installing an application of starting an application that is something that you have on day

one and that's a huge that's a big huge difference and people are like looking for hair in the soup

which as a czech living in germany two very compliant heavy countries i fully understand

and we also totally need to do risk management like we need to plan for when astral's vc overlords

will pull the rug under us but i wish the conversation were more solution oriented and not

and less like per clutchy like yeah there are there are bad aspects to this like this is

absolutely true but also this is something wonderful that we've been waiting for we've

been begging people to use money to solve this problem and now someone did so now it's our job

basically to make the best out of that i just have one question on on it which i i saw a post this

week um from nolan lawson but he was talking about the he was saying why he's skeptical of

rewriting javascript tools in master languages yeah that's the one i meant same post you're

referring to yes but the point i took from that i thought was quite good was that um the thing with

when a tool is written in python or in his case javascript users can sort of debug it themselves

when they hit a problem they can get in they can understand the the what's going on but if it's

written in a another language a compiled language suddenly that ability to dig into it as is gone

and i wonder if well i wonder if that's a loss so i'm i'm gonna say the word again uh it's a trade

off and okay it absolutely is a loss and there was this um really interesting mastodon thread

started by Jacobian, by your very Jacobian, where he kind of shitposted, kind of lamented

the fact that you used to have to learn C to contribute to Python, then you stopped

having to learn to C to contribute to Python, and now you need to learn Rust.

And that absolutely is a loss.

But the question is, what are we getting for that?

And I have to say, I have not debugged PDM or pip many times.

so for me this has not been a loss in a practical sense and if it helps all those people that have

been so frustrated by python in the past and by the way many of those are in the comments of my

video it's not even funny like how many people are just airing their grievances with python packaging

so there's so much pain that still needs to get out so those people are there and this is helping

them like they are the ones where we say this is the one tool use it and at some point you can still

look at other tools, but for now

with this one, you don't even

need to go to python.org

you just download this one thing

Well, I think we're out of time

we could still talk about so many things

but I feel like this is a

This wasn't even half of my notes, man

I know, we'll have to have you

on again if you'll come

Well, yeah, thanks so much

for indulging all our

silly little questions about this

but it's good to be able to pick your brain

and get your responses yeah thanks for listening for my to my rambling i'm used to script everything

out because of course english is my third language so it's very hard for me to just have coherent

thoughts uh life yeah so which is well we have links so nice to lie to me all the time no no it's

i'm not sure i could have so i speak spanish and catalanx i live in spain i'm not sure i could have

an in-depth technical conversation about

ad hoc, about software engineering

in Spanish or in

Catalan, I'd struggle. So I

think you do phenomenally. Thank you.

And the funny thing is I've had a much harder time to speak

about technical stuff in German or Czech because

it's just not... Because it's not

the language of... Yeah.

Yeah.

Okay. Well, we have links to all these things.

Definitely check out

YouTube channel, personal site.

And again, thank you so much for coming on.

We are at DjangoChat.com

and we'll see everyone next time.

Bye-bye.

Bye.

Bye-bye.

This show was brought to you by LearnDjango.com.

Free tutorials and premium courses

to help you level up and stay informed

of all the latest best practices

building websites with Python and Django.