Transcript: Practices of the Python Pro - Dane Hillard

Hello, and welcome to another episode of Django Chat, a weekly podcast on the Django Web Framework.

I'm Will Vincent, joined by Carlton Gibson. Hello, Carlton.

Hello, Will.

And this week, we are joined by Dane Hillard, the author of Practices of the Python Pro,

a regular DjangoCon speaker. Welcome to the show.

Hey, thanks a lot for having me.

No, thanks for coming, Dan.

So there's a lot of things we're going to talk about. We'll get to the book. But before that,

I've seen you in person give two talks, and maybe you could mention how you got into the Python Django world.

So what's your origin story?

Yeah, I think I came out of school doing a lot of C and C++ programming and things like that.

And sometime into that, a friend of mine asked me to join him at a hackathon, and it was a Ruby thing that he was working on.

think we were trying to develop some arbitrary precision number library um and something

superficial like that yeah uh and uh i guess it kind of revealed to me what some more uh modern

and interesting languages look like um you don't like corvettes like she's a corvette so did you

so you didn't do python with your undergrad uh programming at all no not at all um was it just

what's the c stuff and java i'd assume yeah we didn't even do any java in my program um oh geez

yeah it was all it was all c plus plus and matlab um wow yeah that was a that's a computer science

degree yeah uh computer engineering i guess so um kind of a mix of of hardware in there too but

um all all kind of focused on embedded applications and things um which i but you got through it so

now everything is just downhill from there. In some ways, I don't know. I've, I've sort of

foregone the, uh, the hardware aspect of things in my career, which I'm okay with. Um, so I guess

after this, after this kind of like realization that maybe there are some fun languages to work

with, um, I started using Python, uh, at one of my jobs, maybe my, it must've been my last job

early on in my last job. Um, and we were doing bioinformatics, um, work. So, uh, data science

applications obviously are one, one thing Python is good at. Um, and around the same time, I guess

I was looking for something to rewrite a personal website in for my photography. Um, and I wanted to

do something that would help me learn something new rather than just using, you know, WordPress

or something like that uh and so i decided i heard about this thing called django uh and so i

and what year was this do you recall sort of circa it must have been around 2014 i would say

so that was what like 1.5 that sounds about right yeah um so you had all the difficult

that's a good time to get in well either that was just slightly too early 1.8 was migrations

yeah i did right that was i did get in before migrations were part of the uh standard deal if

you will uh yeah and so uh you know since then i've i've picked it up for more things uh and then

uh kind of got into my current job by way of django um at the time they were

uh, migrating off of kind of a legacy, uh, CMS, if you will. Um, and working toward

more continuous integration and custom infrastructure on AWS and a lot of that

kind of stuff. And a major part of the sort of front end of, of the website that we build,

uh, they had started doing in Django. So, so now this is Ithaca, right? Is the name of the company?

That's right.

And they've run, there's a couple like well-known services that they are in charge of.

Like what's the, what's the business aspect of that?

Yeah.

So jstore.org is probably the one that most people know.

Right.

And that's a, an academic journal archive.

And there's also art store that we emerged with a couple of years ago.

Kind of the same concept for art history studies.

and then they they have a couple of other business areas all all kind of in higher education

but got it when i like that you said django is part of the front end because that's a point

carlton i've hit on in this podcast is that django actually sort of is a front end framework but

maybe you could put that in the context what does the full stack look like where you can say that

django is the front end part yeah uh it's a great point to draw i think that django for me uh sits

very much at the area of concerns on most of my projects, I should say, where you're interested

in responding to requests directly from users often. And to me, that makes it sort of part of

the front end. And at Ithaca, that's especially emphasized because really, once a request makes

it to Django, we then talk to a variety of further backend services, typically written in Java,

in order to get authentication and metadata about content and all this stuff and Django acts kind of

as a as a glue to all of that um with a specific application toward the JSTOR web front end right

yeah so are you using the Django ORM how does that glue together we aren't for a lot of the

sort of mission critical parts um those are those are all dealt with in the back-end services so um

We use the ORM for some sort of internal back office type things.

But we're really just using mainly the request handling portion of Django

and the middleware aspects of Django, I suppose.

Yeah, I was going to say, it still gives you access to the middleware,

which is sort of what Django is besides the ORM.

Right.

We have integrated kind of the authentication backend

with Django's authentication system as well.

Do you use remote user or that kind of thing?

I don't know if we're using the remote users.

We maybe should.

Well, you'd be set up for that potentially,

or, you know, token GWT.

Yeah, we have like a custom user model

and a custom authentication backend written

that integrates with that service.

Okay.

can so a nerdy question if you recall are using abstract base user or just abstract user like how

how much are you getting into it it's been a while since i don't expect you to know unless

yeah you wouldn't have written it yourself but you know for for listeners so you the sort of

quick way is to use abstract user which brings in abstract base user but if you want to go

way down under um you can use abstract base user which the further i use django the more i'm like

i'll just use abstract base user but when i teach it i just do abstract user because it's a lot

simpler and you don't have to worry about screwing up as much but the eventual code is

arguably cleaner assuming you understand but then you're i don't know what do you think carlton then

you're sort of rewriting django but it like why are you rewriting django like i don't know you

know you know my view i just use i want a manual i want a manual transmission i just use the bog

bog stand oh you want a manual fine okay yeah well you use profiles you don't even use you know i

i use the built-in user model and i'm just like yeah whatever i've if i need extra fields i just

have a one-to-one you know well i mean because you know to get into it so django all off are you

do you know if you're using that we're not using that i'm familiar with the library though

right yes that's very popular and you can use that to have email only um but behind the scenes

it's still using username uh for admin and it's sort of like adding two-digit numbers onto

username so you know that's a problem you want to have when you kind of blow through all the

you know will dash 999 all those iterations but part of the purist in me goes well i don't like

that i want to do it all myself so anyways as an aside this is the problem carlton the more i

program the more i become one of those people i'm like i'll just do it all no but this is where you

end up right you're like i'm just going to knock up a website and then you start building a website

builder and then you start you know it just goes on and on then i start loot then it's like i'm

fighting django it's like why even use django and you know just yeah sorry authentication though

so i guess where i was uh we were talking about um sort of the pieces of django that we use i'm

trying to think if there's anything else that we also take advantage of what's the front end are

you using a javascript library or using the server templates it's kind of a mix at the moment uh we

definitely use the templating engine from django uh so i i guess that's another major aspect that

we definitely leverage right uh and then we also are starting to use some more uh front end

frameworks uh view and react have made their way onto the site in some areas um both of them yeah

both of them uh we also have plenty of legacy code in jquery right so it depends which freelancers

in this week right yeah um we're also kind of building a design system at the moment um

and i'm actually on the team that is that is working on that so we're trying to figure out

how we can build uh web components that will be supported yeah you know in a variety of these

frameworks um web components proper like the the standard that's being worked toward um right

right seems like something worth working towards yeah i think i think we need it

um and now you've i'll link to it you gave a talk at i think pi ohio on pi test i wanted to ask

about testing and i assume you know it's a large site you're probably using pi tests unit tests

like what does the testing situation look like yeah uh we are using pi tests we kind of moved

to pytest maybe within the last year for sure i'm trying to remember how long ago it was exactly but

uh i would highly recommend it too that must feel good internally to switch over right like that's

hard to explain to a business person but something like that is like deeply meaningful yeah i would

say that pytest has really boosted our testing productivity for sure um we're also maintaining

kind of a variety of packages that are installed in our various applications and um so between

pytest and tox uh i think we've really seen a lot of productivity we're trying to i guess tox uh

helps us test across uh sort of current and next version of both django and python um and it's

helped us make sure that we're forward facing yeah it's really good as well because you know

you're on 3.6 and you want to upgrade for 3.7.

You don't know if you can,

well,

you can build a tech talks environment,

run your test suite.

When that's passing,

you can upgrade and it's,

you know,

and then you can get 3.8 in and it's just,

it's,

it's a really nice way.

Can you publicly say which,

which version of Django you're on?

Um,

I think I can say that.

We're,

uh,

we just migrated to 2.2.

Oh,

that's fantastic.

Yeah.

Ahead of,

ahead of the one 11 end of life as well.

So I was happy about that.

That's,

I mean, you know, on this podcast, we're a bit strict on, you know, you should always update like your car.

But for a large enterprise site to be on 2.2, that's really good.

That's not common.

Yeah, I will say that I think the process of going from 1.11 to 2.2 was actually much easier than going from like 1.8 to 1.11 in our experience.

Yeah, no, but that's just objectively the case.

like um updating django now is incredibly easy incredibly stable versus you know before it there

was more breaking changes and you know it's it's it's it's a much more mature framework now than

it was yeah um we were even able to kind of we were able to sort of fully get to

two, two compatibility, uh, without actually making the upgrade. Um, I remember maybe putting

in two conditions, I think, uh, sort of, you know, if, if Django two, two or higher do this, um,

only, only in two or three places that I can think of and the rest to just sort of like

worked in both versions. Yeah. Um, so that was, that was really enjoyable actually.

That's great. Well, that's a testament.

to the community and the fellows you know yeah no well your work tim again it's like tim tim

graham did so much work to get jangle and it's stable footing that it's on i mean so you know

again to go to him and yeah like i said pi test and and talks really helped us through that i

think because um we were able to just run our full suite of of tests in both situations and

and you know now that we're on 2.2 we've updated our testing environment to include 3.0

for when for when that comes right fortunately now we're on 3.1 yeah 3.1 fortunately we're on

2.2 which will be a long-term support for some 2022 is it yeah it's another two years it's

another two years from now so like you could but like if you've got that tox environment in place

there's no reason why you couldn't do the little hops but hop step all the way you know three three

one when that comes and then nine months time you're on three 3.2 that you know as soon as it's

out the door yep so what's what does this um cicd look like for running all these tests we use

jenkins for most everything uh it's that's that's what i mean i think that's by far the most common

still at large sites it's certainly the sort of de facto standard if you can't put it out in

something like Travis or, uh, circle CI or something. Right. Um, and it's free, uh, which

has its ups and downs. Yeah. Free. Yeah. Just developer time. Yeah. Uh, so it, it, you know,

we have experienced, I think some, some growing pains on it. Um, they do have this Jenkins file

approach. Now you can write sort of declarative and procedural stuff in groovy. Um, and that has

been helpful because it's much easier to kind of define

what you want rather than fiddling around

with their UI menus.

So we have sort of a Kubernetes cluster

that can spin up Jenkins instances

and run jobs as we see fit, which is pretty fantastic.

But sort of managing all of the resourcing and pooling

of workers and nodes and things has been somewhat troublesome we're kind of at a at a steady state

now yeah it's difficult so you said kubernetes are using docker then locally uh not for local

development so much i think we want to get there um but we our apps are containerizable

right clearly yeah um yeah i think we there's mostly kind of uh efficiency things to work out

before it would be too helpful in local development um we still haven't made our images small enough

to iterate quickly on well we just recently had um katie mclaughlin on from google and we were

discussing alpine versus slim versus full and she brought up the point which i wasn't aware of the

alpine is just a completely different world actually um because of course slim has the

psycho pg2 but um yeah and optimizing your containers is incredibly important yeah i i mean

i'm i'm not very good at it i mean but i know it's it becomes a big issue fast when it's you know 700

megabytes for python and on you go yeah gigabytes locally uh another big issue we've faced trying to

use alpine uh is that it has its own c compiler um yeah that was the point that she was making yeah

so we had a couple of libraries specifically that um have no wheel available for alpine i don't i

don't think alpine even does wheels if i remember correctly i'm not sure uh but in any event it you

know we had to incur the cost of building uh like lib xml or lxml um from scratch yes but yeah that's

one of the ones that yeah i mean yeah so personally i i just default to slim these days because it's

like yeah maybe i could use alpine but it's yeah yeah there's a poke under the covers too much

yeah there's like this trade-off between how much how many batteries you have included and

how bloated your image ends up being so yeah so we come to python let's let's talk about

so your book so you have this fantastic book um i've read it how did that come about like what's

the i mean and i'm curious too just as a fellow book author like why would you spend the time to

write a book. Why would you do that? So I'm not sure how much this is the case for everyone. Uh,

in my particular case, um, sort of the publisher that I, that I wrote this book with has someone

on staff who reaches out to people doing online blogging and things like that to see if their

interest is manning. Right. Um, and, uh, so someone reached out to me and said, Hey, we've

seen some of your writing online. Have you ever considered writing a book? And I was like, well,

no i never never have thought of that uh and i guess i thought about it for a bit and um it spoke

to i think a lot of the goals i had with writing online in the first place um i i like sharing

knowledge i like um you know having starting conversations um so by putting things out there

you give others a chance to say well i handle this problem this way you know you said you approach it

this way, but I have this other solution as well. So opening up those kinds of conversations is

really interesting to me. Um, and so in general, I like just putting things out there and seeing,

um, you know, if I can help someone or if I can, um, pull information out of other people,

uh, by way of those conversations. Right. So, um, you know, I figured writing a book could be,

you know another sort of natural way to to go about that um and then from there they they have

you kind of propose a a whole like not just the table of contents or what the book might contain

but sort of a timeline of how you think you can get that done um which is generally how accurate

it was right you're a software engineer how on earth are you going to come up with the you know

right so i don't lie for a living right another 50 or whatever six to eight months yeah

uh i think my original proposal was probably something like a year uh and i was over that

but not by not by a heck of a lot as far as things go in the in the long term uh maybe

a year and three months or something right so a lot of that time is really spent

with your development editor going through making sure that you are teaching to the audience that

you identified up front as well as then each chapter sort of goes through a technical editing

phase they check your code make sure that it runs make sure that it does what you said it does

um and then at the end they also do all of the typical kind of copy editing language editing

and then throughout you're sort of writing um writing these examples uh they have someone do

a final check on all those um you're creating figures for the book so they have people uh

kind of re redo those and make them look nice and polished um you just ended the nap just described

Like months and months of my time that I had to do on top of everything else because I self-publish.

That's why I typically advise people to go through a publisher if they just want to have a book out because it's a lot of work and most people have no idea all the things involved in a book if they haven't done one before.

Yeah. You know, the time is one thing, you know, your estimate versus how long it takes. But seeing all those things that really go into it on the publisher's end was pretty fascinating to me.

You described your audience. You said they do a review to make sure you're targeting the audience. And the audience for the book is what I think of as advanced beginner, right? So they know how to program, they've done their first, you know, few projects, you know, capable, but then it's how do you move up beyond that to a more sort of high level. And go on, carry on.

That's exactly right. I think it, the book is intended to help folks who are starting to move into those larger projects that may last, you know, a year, many years, so that they can sort of build in maintainability and long term kind of understanding and, and the ability to collaborate on that code base with others.

So, I mean, the big thing in there, the big thing that really jumped out was your focus on encapsulation and breaking things down and keeping the, you know, the implementation hidden from the outside so that it become, you can reason about it, right?

Yeah, I like, and I like the two part, both that you pose the questions that professional developers do think about that if you haven't had that experience, it wouldn't even occur to you.

And then you walk through the various, you know, examples.

So I think even just the first part, just to sort of know the playing field of choices that you're going to face in a large project is incredibly helpful to people.

Thank you.

Yeah, I think a lot of times, a lot of these things come down to exposure, right?

A lot of times as a developer, anyone at any stage in their career, right?

There's often just things you don't know that you don't know.

So it all comes down to exposure.

After about five years, you've got it all figured out.

You've got it figured out and you know nothing.

yeah yeah so the goal with the book was kind of like here are some things i've found myself

thinking about and trying to solve um so right you know as someone a few years earlier in your

career if you start thinking about those now you'll be in really good shape yes so i have to

ask so people come to you you have a python book what advice do you give on installing python

because there's I would say there's a lot of options and I don't see any what do you tell

people when they say should I use pip should I use poetry should I use pipenv should I use

you know pyenv how do you answer that question uh yeah that's a tough it's a really tough one

I mean it's nice to just say of course it's installed and works perfectly on your mac

windows linux chromebook this is appendix a right yeah or docker that's what I did my most

recent book i was like we're just going to docker everything so don't worry about it yeah it's like

what's docker uh just download this copy this file and pray that it works yeah uh in so i have

an appendix in the book that talks about it um i'm not sure that it's as comprehensive as maybe

i'd like if i if i were talking to someone face to face i think i would go into more detail in

some areas or or um suggest maybe a slightly different approach and i think the best approach

to me is one where you build off of the basics and really understand what's going on behind the

scenes a bit um because things like poetry and pippen especially are you know they're fantastic

um in their own right but they also do abstract a ton of things away from you and if and when

they break which some some of them often do um it's kind of hard to know how to correct course

if you didn't do those underlying things yourself before, right?

So a really good understanding of pip

and dependency resolution in general

would be a good thing to do

before sort of just letting Poetry or pipenv

do all the work for you, right?

But I think you've got to know what VMV is and how it works.

And, you know, we always have this...

Yeah, I think that's the big one.

Because, like, JavaScript, you don't have that, for example.

Great, because a lot of people, JavaScript's the first one,

and then they hit Python, they're like,

Yeah, it doesn't make sense to them why they need virtual environments.

And it's difficult for beginners.

I appreciate there is a learning curve to vInf, but you've got to have that.

Yeah, so I have this installpython3.com site because I've written about this and that's open source because I'm trying to sort of tackle this issue.

But what I find is that the problem is that beginners have already mucked up their local computer by the time they get to the right answer.

They've gone to python.org, they've downloaded a couple of TARs or whatever it is.

They've messed up their path, you know, so they've half downloaded three things.

And then when they go on their command line to type Python, what does that even mean?

And so even if like on a Mac, for example, I recommend Homebrew because I think I like using Homebrew.

But their path is already messed up.

And to explain to a beginner what path is, like I can't.

Um, so anyway, so I see, I almost, I do tell people sometimes like if

you can just wipe every, like get an extra.

hard drive wipe everything truly and then start from there but that's a bad place to be in the

community but that is the reality like if you ask a normal person face to face to do python um they're

going to struggle yeah um something that so i wrote an article as well on uh on real python

about um python environments and um shell environments in general so it kind of walks

through what is a shell what is a terminal yeah what are python virtual environments uh what are

tools that manage python virtual environments um okay we'll link to that yeah i must say

go ahead well sorry i just real you mentioned real python it's like you know that's been on

my radio for a little while but recently it's just been blowing it out of the water it's just

super it's just so much good content on real python at the moment i really recommend it to

whoever it's like yeah um it's like it's like a super friendly group of people too i'm in the

like the slack channel uh and they're just constantly like adding new people too and

everyone's you know welcoming each other and it's if you're thinking about writing and want sort of

a channel other than your own to write on i would definitely uh look into joining that group because

they're great yeah dan's done a lot of work there i mean because he he took it over from my um from

my friend michael herman and i think only two years ago and um yeah it's i mean it's amazing

that he's able to um the crew um is able to maintain the standard quality because it's

quite a lot of work to have contributors and to have a consistent level of quality um but they've

been pulling in some of the people i i've seen individually writing fantastic stuff and yeah

they've been doing great not short pieces as well like really extended you know in-depth

wows of type things anyway real python um yeah i mean you know we're talking about the the book

editorial process i think one reason that they're so strong is that they also have a very robust

editorial process um so every article is not like you just write it and then it goes up um

oh real python yeah yeah um yeah you know it there's a lot that goes into quality content

people can actually learn from so how do they handle updates that's always my question i mean

there's no easy answer with i mean python stuff is a little bit easier but web framework stuff

because in two years you know python 3 whatever is going to be out i wonder how they handle that

because that's that like for me if i think of like well maybe i want to run a django magazine

i don't know the answer to that yeah like that's the one that really trips me up i mean they

encourage people who are writing articles to go back and and update them um they also you know

anyone on the team who notices an article could use updating is welcome to to voice it and maybe

make the update if you know whoever wrote it isn't around or needs help with it um so yeah

stale content is one of the most frustrating uh things as a developer today i would say

well and it's frustrating as a creator because in six months it's stale and you're like

oh geez like you know yeah i'm just speaking you know hypothetically never happened before

well i mean i don't know if i said this before but i mean so for me i like i have this learn

django.com site and i'm building some stuff out but i i envision only something like

50 maximum tutorials because i have i would like to keep them up to date which means at

least every nine months and so you know it's a limiting factor but at the same time you know

yeah i don't want to read something that's old and i think the challenging thing is that

if you're a professional you can kind of you know 90 95 of it is helpful and you can fill in the

gaps but if you're not at that level you will get stuck on maybe a minor implementation thing but

you've lost the entire thread yeah and so that's kind of the yeah that's the reality of it when

you talked about um sort of people people doing a lot to screw up their machine before arriving

at the right answer um and i think yes stale content on the web contributes to that too because

um you know for instance a lot of people don't even know that vnv exists in python 3 standard

library now right um yeah i think it's three three five yeah i think um and it's you know

they're finding content that's like first easy install virtual and wrapper yeah no i mean i i

have an older post that talks about using that and easy install yeah it's a hard so good yeah

easy install set set was it setup tools isn't that the other one there's a couple out there yeah

yeah but it's gotten better um but it's still like i would you know if i put my hat on i would

say the two things that hold python back are the packaging and then in terms of like how do you

share python and then just installing it um when you have the the anaconda community and things

like that too yeah well yeah what is up with that because i don't like so i recommend using like

mini conda for the chromebook i have a section on that because in that case a chromebook the

more recent versions you can go and use the linux um and i've found that using conda there

is by far the easiest but i i do see i mean for example um the django crash course the new a new

book by the um uh daniel and audrey greenfeld who did two scoops of django they recommend anaconda

from the beginning interesting and that yeah that that's the word i would use too i'm so we're

gonna have him on so he can talk about it um it's i guess it makes sense in a data science realm to

me but if it seems yeah i don't know enough about it yeah i did a little bit of research for that

article i mentioned about environments um because i i had never really tried anaconda conda mini

conda any of that stuff um all the flavors yeah um and you know it does provide a lot of the same

things we're used to around uh virtual environments if you will uh and package management um and i

guess the another value add that it has right is that you can install non-python things with the

same package management system um so you know right well and then interesting well and then

there's um you know many students get a free pycharm license and pycharm abstracts away the

virtual environment basically you do it within there so i've seen students who didn't even

really know what a virtual environment was because it was all handled within pycharm

so they were going through my book and they're like yeah we just skipped the virtual environment

part and i was like how'd that work out they're like oh we're in pie charm and i you know asked

a couple follow-up questions and was just like it's pie charm um and you know maybe that's you

know plenty of professionals use pie charm as well but that was interesting to me because it's

that trade-off it's like i don't want people to get stuck on installing it and these details but

i also don't want it to just be broken and not work yeah um and yeah so it's the double-edged

sword i guess right like uh like i was saying earlier it's often helpful to build from the

ground up so you understand the the foundations but at the same time the reason we encapsulate

and abstract things is so that you can start at a high level and then eventually work your

way down to the details if you need it's hard to know which way to go yeah well but if you think

about again just thinking of javascript it's was it babble you know where where they you know you

can use any basically any version of javascript and i know there's been versions sort of like that

with python though i don't think they're widely used where you just like you know could use

everything from 3.8 down um that would be nice certainly in javascript that was a huge i think

i'm saying this correctly i think babel's name of the package because there was that big switch

in javascript where they like waited 10 years and then nothing happened and you know and now it's

all kind of like handled in the browser for you which is also nice so just out of interest but

again python like you call it just out of interest you call it the tower of babel

babel babel i say babel i say babel okay is that the american version carlton because babel

i'm a british person babel would have two b's in the middle right because it'd be the tower of

babel but anyway no it's just you gotta flatten it out that's fine that's cool

um yeah so babel is like this transpilation uh approach that lets um you can sort of target

whichever browsers you need to support for your website and it will produce something that's as

compatible as possible with that set of things um well i mean it's specifically python i don't know

i find it's the the f strings so three six um that's kind of where because i use them in my

books and i you know i do say i use python three seven um but you know beginner right like nine

times out of 10 that the tell that they're on an old version is that the the f strings and again

you know strings i mean if we're going to pick on python what there's four different ways to do

strings in python i think yeah these days i mean i well you're the python pro which one do you like

i like f strings but you're talking like string templating specifically right well yeah we could

yeah i sure um so there's like percent formatting and dot format and all that uh i was a big

proponent of using dot format um i think it it seems more readable to me um i think so then

yeah then the parenthesis was at the yeah parenth uh yeah parentheses at the end whatever that's

called um i guess using percent formatting you can maybe find more errors uh you know it lets

you specify what data type things should be um which can be helpful um whereas format will work

as long as you can turn whatever object it is into a string um and then uh i mean nowadays i

definitely use f strings as much as i as much as i can but but the thing good just going back to

your point about three five quickly before we move on it's like especially when you're looking

at beginners you've got to imagine someone picking up you know a computer that's any old computer it

could be five years old and it's got whatever version of python it's got on it and it's really

it's just so good if what they type just works right and if as soon as we start accelerating

the support matrix so we start saying well you know three five is still you know it's still

got another year or so to run before it's end of life but we're going to drop support early then

we're cutting out those and obviously we can't support three four three three three two forever

and ever and ever we've got to cut off somewhere but i just i don't want to see us leave those

people who are picking up a computer that's a few years old and it's just got python they just need

it to work because if they hit an error the chance of them getting over it like really low

yeah it increases the friction right yeah um i think that's where that that bootstrapping if

you will uh that will's talking about could really start to be helpful if we found a good solution

for that yeah so let's talk about some of the other parts of the book it is a book-length

treatment what is some of the feedback you've gotten from readers about about the book because

you cover a lot i do um like what's what sort of um what are people saying oh i didn't realize that

or maybe what's yeah what's the feedback like so i i guess recently i asked a question on twitter

about sort of which chapters were most helpful to people um oh i saw that yeah i have like a chance

to make a free um you know i like i select a couple of chapters from my book a couple of

chapters from other books that kind of have a common theme. So I asked people what the most

helpful chapters for them were. And a couple of different people said the chapters about

separation of concerns and flexibility and extensibility were kind of what resonated with

them. So earlier in the book, there's a chapter about separation of concerns. And then later on,

there's this chapter about putting that stuff into practice. Um, so I think the reason I see that

maybe, maybe why people are saying that one was helpful, the, the one about putting it into

practice, um, was because a lot of these concepts, especially if you haven't been exposed to them

before can feel very abstract and it's easy to just kind of pontificate about them and say that

they're good things to do um but it takes a different kind of uh learning to actually

apply those things um and and to see examples that actually do that in a useful way that you

might do that in a real code base to what extent do you think that it's useful to just read something

like this before you even know and then you know six months later 12 months later 18 months later

you're doing a bit of code you think oh i could apply that you know that idea from dane's book

I guess while I was writing this book, as I introduced to this concept,

I forget the name that it goes by, but the concept is essentially this idea that

learning happens in a spiral. And so, you know, each, each axis of the spiral is a different

concept that you're learning and you start in the center of the spiral, uh, or maybe on the outside

of the spiral and you work your way in. And so each time you reach that axis, you're like relearning

something about that concept, but that's sort of a different fidelity, right? Yeah. Um, and I think

that is a really useful way to learn so the idea is to first introduce the concept and then start

to show some examples and then give someone like a project that actually uh they they sort of need

to do that thing um and i i think that's what leads people to use the thing when they need it

rather than look for a nail for their hammer right which works as well right you know

copy paste from stack overflow yeah exactly i mean that's that's i tried to kind of shy away

from design patterns too strongly in the book because i think uh when you learn just this

library of of things at your disposal without necessarily seeing how they can be used in

practice you you tend to try and apply them to every single thing you work on right um and that's

you end up you end up with kind of a mess so but one thing that i liked about the original design

patterns thing and like the book that inspired it by somebody alexander whose name i can't first

name i can't remember but the the idea of the the design patterns they create a pattern language

which then enables communication so i can say to you oh we're going to use the decorator pattern

here and you know exactly what i mean and you know we're able to fluently communicate about

the domain in a way we wouldn't. That's an astute observation. I think shared vocabulary is one of

the most important parts in a lot of this. And I was talking about a design system earlier that

we're building at Ithaca. And part of its value is exactly that same thing, just applied to sort

of visual interfaces, right? You're talking about a button, and then you're talking about a buy

button and you're talking about specific buttons and everyone knows in their head the same button

that you're referring to right but um that kind of thing is really important um especially with

software engineers who are sort of you know stereotypically poor communicators or or grumpy

people um it's really nice to externalize a lot of that thought and make sure that everyone's on

the same page i would also add programmers are often terrible uh not good typists or they make

a lot of mistakes which when i i started off as a book editor before i got into programming

so i sort of assumed that programming you know the code has to be perfect so they're just going

to be flawless typos right and then i didn't know about you know linters and you know all these

things and then in practice i see it's like they're even worse than authors because some

authors have terrible grammar but programmers have just atrocious grammar broadly speaking

but it's just self-corrected for them so it comes out looking pixel perfect we obsess about the

tools if you're well but you know it's yeah it's it's like i i say it's it's basically like

microsoft word plus grammarly on steroids and everyone uses as a default so anyways yeah aside

for for beginners um it's not true there's a lot there's lots of things programmers don't know

including you know video conferencing carlton i mess it up every time so everyone's on zoom

right now it's like how many you know django professionals does it take to do video conference

um i'm thinking back to like we just we just installed uh pilot and black into a lot of our

shared packages so i know what black is what's pilot pilot is uh it does a lot of things um

it checks a number of pep eight things for you i think it's like flake flake eight on steroids or

i think it yeah it might include flake eight directly if i can't recall for sure but um it

also finds uh some things that flake eight won't catch um i can't think of any examples off the

top of my head but um it finds common things that might be you know dangerous down the road whether

it's, you know, mutable default arguments or something like that. Um, maybe flaky catches

those two. I don't remember, but, uh, yeah, so it's, it's a kind of code safety and, um,

code quality tool. It tries to be objective. Certainly some measures are always going to be

subjective, but. So if someone walks up to you and says, Oh, you wrote a book on Python pros,

does anyone ever say, you know, what's the short list of what I need to know?

or how would you answer that i mean obviously it'd be nice to say you know look at the book i

wrote on it right people ask me questions i'm like i already answered this somewhere i don't

know where like you go look it up but it's nice to have a bullet list response yeah like what

are the sort of i mean we mentioned sort of separation of concerns like how do you prioritize

that stack of beyond beginner python knowledge it's a great question i haven't received it

directly. So I'm thinking a little bit about what that list really would be. But a lot of what I've

been learning lately is because of sort of shared package management that I've been doing. And a lot

of it comes down to the various aspects of the package management lifecycle, which are testing

and formatting, consistent formatting for people to have an expectation of what the code is going

to look like wherever they jump in. I guess I wouldn't necessarily tell just anyone off the

street, right. Uh, to, to know all the things from my book, because a lot of those really are

meant for someone who's advanced on to these larger projects. Um, but separation of concerns,

I think is something anyone can benefit from. And then testing, I think is, is pretty important to

get into early on um yeah yeah i don't have i don't have that like i feel like i need maybe

like five or six points on that list uh not coming to my head readily but okay that's that's quite a

few things already though well i like that you mentioned the aesthetic aspect because

to make another javascript analogy i mean i recalled so javascript whitespace doesn't matter

so before this package named prettier came out a couple years ago it was just a nightmare everything

look different um you know python at least white space does matter you it's easier to eye check

look at something and say that seems oh that seems okay i mean like one one tell i have is like if

your function or your functions are super long i sort of knock some points in my head

i don't know about you carlton what do you think i uh like if i see an if i'm like oh i'm sure we

can put that somewhere and if there's a four i'm like yeah i'm sure that's a subroutine and

you know like but like the thing is though you don't want to where's the generator you don't

want to break things yeah exactly that kind of thing you don't want to break things up too much

right because um then you've got to go looking for the implementations um whereas if you've if

it's all if it's you know only 100 lines it's easier to read it in one single function than it

is to break it up into sub routines and do you see where i'm coming from right receive it gets

if it gets really long and you're having to go well what's this bit doing and then you're reasoning

about that well then pull it into a different function and give it a good name and then it's

really understandable but there's no hard and fast rules but don't don't over don't over factorize

right don't don't have functions that are two lines long what you know yeah we're just sharing

our aesthetic thoughts on python code um it's more about what theme you use in your editor

oh it's no it's carlton it's what font you use are you using operator mono are you using

i shout out triplicate font if you know triplicate font i give you props that's what i use i haven't

heard of this one i'm gonna go check it out though i use fiber code yeah that's good i mean triple

how condescending can i be sorry when i get tired my phone's better than your ability goes out

no no yeah people check out triplicate it's it's dope sorry what were you gonna say though dane

uh i was gonna say to carlton's point about uh about factorization i think um

it's another case of like, if you use separation of concerns for every single thing you can think

of, uh, you do end up at this like litter box of, of one line functions or something. Right.

Right. Um, so you kind of have to define what a concern really is. Um, and often the granularity

of concerns changes depending on, you know, where you are in the stack, right? Like, um, granularity

have a django view concerns in the django view are going to be probably a slightly different size

than if you were um you know building a real-time millisecond response time api endpoint or

something i guess those have some overlap right but right well there's some things that are yeah

if it's like too perfect it's sort of i wonder if that's the best use of time right you can

yeah over factorizing these things whereas i would say like test coverage basically can't do

enough of that but i got i got this rule of thumb which is um it's only a rule of thumb but for over

20 years i've kind of come to it is if i'm having if i've got like four or five files open in the

editor and i'm having to jump between them and go back and forth to kind of like oh what's this oh

i've got to go and look in that file and then i go back to where i was okay okay okay oh what was

this i'm in off another file at that point i'm like no this is this is bad code like because i

should i should okay nice encapsulation it's in one file and i use it from another but i don't

have to go and jump and look at the implementation the whole time that's where it becomes too much

like hard work it's like you're sweating the brow just to understand the code yeah and that gets to

this idea of cohesion right you want things that are working together often to be in the same space

yeah exactly cohesion i knew there was a word for it well i was gonna if we're talking favorite

programming quotes i have to say my my two favorite and actually i look back i have a blog

post on this so if anyone wondered about my like inner snob it's it's totally an outer snob but my

two favorites one is by linus torvalds if you need more than three levels of indentation you're

screwed anyway and you should fix your program it's a very linus hard love approach um but the

one i really like is by ryan doll who created no js who said the only thing that matters in software

is the experience of the user and he has a whole blog post on this because you know it's easy to

get caught up in the tooling but at the end of the day whether the the user is the developer or the

you know website it's the yeah sometimes you lose track of that but i do take that to be true

especially i have a whole post on this carlton i'll share it with you there's like eight quotes

in there so i'm now trying to pull my favorites out of the archive like let's see you don't have

a blog post on this i've got a blog with nothing on like that's what i've got i don't blog like i

try okay i'll i'll read you no no i'm gonna tell you my quote i remembered it i can't remember who

he's by but it goes like this it goes i want you to listen i'm talking i'm talking now go on you

talk you talk again from linus bad programmers worry about their code good programmers worry

about data structures and their relationships yeah there's another one like there's a similar

one like that about show me the show me the data the data structures and i'll understand it you

You know, show me your methods and I'll be wondering forever.

I can't remember.

But what were you going to say, Carlton?

The one I like is you can engineer code so there are obviously no errors or no obvious errors.

Yeah.

These deep truths.

Yeah.

And, you know, you see the personality of the, you know, person in them, too.

Yeah.

There's different ways to come at the same idea.

Well, so we're, we're wrapping up on time here. I know that we have links. Um, we'll put in the

show notes, pod Django 20, that, uh, listeners get 40% off the books, which is a pretty nice

discount. So they should use that. We'll link to your book. What else would you like to mention?

Is there a way people should get in contact with you? What, what do you have? Are you working on

a second book? Um, I'm not working on a second book at the moment. I've taken a little bit of a

a break, but maybe, maybe someday soon. Um, I'm easy as Python on Twitter. Um, that's probably

the sort of best entry point to, to get in touch with me. Um, I made a website for the book

recently called the python pro.com, which will also be in the, in the show notes, I imagine.

And that's probably, that's probably it. I would say, say we'll do one of those two things.

Great. Well, thank you so much for taking the time to come on. Um, as I mentioned,

i really enjoyed your book i think it's one of the best out there on python so i really appreciate

that i hope people read it yeah thanks so much carlton anything you want to add no no no just

thanks for coming on don't super really good interesting chat thank you yeah it was a pleasure

all right bye bye everyone see you next time bye