Transcript: Django 3.0 Preview

Hello and welcome to Django chat, a weekly podcast on the Django web framework. I'm William

Vincent joined as always by Carlton Gibson. Hi, Carlton.

Hello, Will. How are you?

I'm great. And today we have exciting news. We're going to talk about Django 3.0, which

is coming out this December, but I believe the feature freeze has just gone into place.

So we're going to talk all about what to expect and a little bit about the process that the

jango fellows such as yourself go through to make it happen yeah so the feature freeze was the 9th

of september and then we put the um alpha out on i think the 10th or the 11th maybe the 10th

um and so that's available now so you can go to the website you can um you can download that you

can pip install it and then you can um you can test whether your app is compatible with jango 3.0

and if you can do that that's super so the take-home message from this podcast is go

get the alpha run it against your test suite and then please report if they've broken anything

because it's this time what we'd rather have is reports that we broke something now rather than

the day after we released the final in december right so let's maybe talk about so what's going

to be included and then we can talk about what you know missed the cut and we can have looking

forward to in 3.1 3.2 okay super so the big headline feature is the ascii support the hgi

support which is the async support so um this is the first step in the road to making django async

um and django from 3.0 will speak asgi which is the equivalent of whiskey so whiskey what's that

it's the web services gateway interface it's the um the standard for python web servers to

communicate with web application frameworks at the back end um and so django is a whiskey

Django is a WSGI framework, Flask is a WSGI framework.

They're all WSGI frameworks.

And up until now, Django has supported WSGI.

From the step away, the evolution of that is towards the asynchronous gateway interface,

which is ASCII.

And Channels speaks ASCII already, and Starlet speaks ASCII,

and there's a few other frameworks out there that speak that.

But that was now coming into Django Core.

And so from 3.0, you will be able to run Django, your old synchronous, your exactly existing Django, with an ASCII web frontend, so Daphne or Uvicorn or one of these ASCII frontends.

But what's interesting at that stage is then you can embed that in an ASCII app.

So you could have, I don't know, a dataset application running alongside your Django application, and you could serve those from the same frontend.

they just sit next to each other or you can wrap your um your existing django application in an

middleware and then serve that via an ascii server all kind of interesting things like that so that's

the that's the sort of main headline and this will be opt-in so the default will still be whiskey or

what's the plan on that oh yeah you just so you'd um you'd configure and so you yeah you just you

start project is exactly the same um you know nothing changes you run it with gun and corn

exactly as you always did and then if you want to you can create an instead of a wsgi file you can

create an asgi file and there's docs on how to do that and what you include and basically the only

difference is instead of get whiskey application or whiskey you import the whiskey get default

application function which wraps up the whiskey handler there's the same for an ascii application

which wraps up the ascii handler and it's really the only difference and can you do this on an

app-by-app basis was that what you were saying no so that's so that's the main right it's project

level you decide yeah it's project level so the the main handler which takes incoming requests

and returns them back to the server is either a whiskey handler or an as right and you were

giving the data set uh example which is a simon willison project as if you used ascii you could

have that be piping into django um asynchronously whereas you would need a background worker well

Or at the moment, you'd route that separately.

So you'd have your base ASCII application,

and part of that you'd send to your existing Django app,

and part of that you'd send to Dataset.

So you'd have them sort of side by side at this stage.

I imagine we'll do a lot of talking and explaining about this going forward.

Yeah, this is almost going to be every episode for the next two years.

We're going to talk about Ace.

So before we get more into it,

so who do we have to thank for doing the heavy lifting on this?

Because we've had some guests on,

but I always like to call out names,

Because I feel like most people, there's people in the shadows who do the heavy lifting to make this happen.

Who are the names that come to mind for you?

Yeah, so it's Andrew Godwin at this stage.

He's done all the conceptual work on going into this on channels and then on the ASGI ref, the specification and then the sort of core library around ASGI.

He's created that.

Well, I mean, with other inputs from, you know, Tom Christie and others, you know, so

it's not just him, but he's done that.

And then he's bought...

pulled this together at um it seems almost just out of the blue at the DjangoCon Europe sprints

in Copenhagen um we went from oh ASCII's gonna come we're not quite sure when to oh there's a

pull request implemented well it makes it easier to say what's what's new in 3.0 it's like oh

actually there is something async there yeah yeah because before it was like well we're targeting

this and you know but Andrew's you know he's an absolute superhero and he's done it not all by

himself but largely all by himself yeah well the good news is this episode we won't have a lag on

it so we'll be releasing it tomorrow so if you see andrew at jango con us where you and i will both

be starting uh this weekend um or online please do send him tom christie and others a thanks because

they don't get much thanks for the work that they do but we all rely on it yeah and they really are

pushing the the whole ecosystem forward here so that's super um what can i say what else can i say

about asgi um i just say that actual async views which is kind of where the really the really

interesting bit comes will be 3.1 now targeting that um where you'll be able actually to write

async um these async views which are super for things like proxying to a third party or collating

several endpoints into a single response or you know any kind of io blocking endpoint you know

people have five to five years ago you'd have gone to node.js for that and now you just don't

you don't even have to go to a different python framework which you have done say a year ago

18 months ago you'll just be able to carry on in django land as if you know nothing changed and so

that's a real um that will be a real milestone that'll be a real step forward so if you put on

your projection hat how do you think this is going to impact background workers you know celery

redis i mean i know we don't know but it has the potential to massively disrupt how you would

set that up because right now you have to use a background worker to do async like behavior

yeah um so i think queues in the short run queues aren't going to go any away because they're kind

of stable and they're mature and they're tested whereas this stuff is all new and it's bleeding

edge and so it won't work as smoothly as you want but yes in starlet for instance you can already

spin up a background um can you say what starlet is for the listeners oh yeah so sorry so starlet

is tom christie's um a a async um frame micro framework i guess you'd call it i mean it's

a bit more than a creator of jenga rest framework yeah exactly um and so he's he's done a lot of the

the um theoretical work here by laying out starlet and it was all from um a clean plate so it's not

nice and you know there's no crusty bits because it's it's fresh and it's a lovely little thing um

and it's super and it does really show the way forward and so he gave a talk at um jango con

europe um about a possible redesign of jango where basically he was talking about starlet and what

he's been doing with um you know an orm there yeah we've linked to that before but we'll definitely

link to that again because it's a fantastic like 50 minute talk and he explains async as well as

anyone i've seen what's going on with ace yeah actually same with what's going on with the hgi

and yeah and i actually same with andrew godwin his talk at um pycon australia or jango con

australia he also lays out the plans for async so we'll link to those two yeah and i think he's got

his talk at jango con coming up next week i think he's on this same topic as well yeah so be on the

lookout you know but like the thing was that with tom's talk is it was about starlet but it was

supposed to be about a jango redesign but it's exactly how jango is going to end up you know

it's going to look very similar to the code that tom's demonstrating there and it's it's much easier

to show it with actual code

than it is to wave your hands

and say, here's some ideas.

Right. Well, and this async stuff

is really exciting for Django

because I get questions all the time

about Django versus some other framework.

And we've talked in our episode,

we've talked about Flask.

You know, Flask is intrinsically tied to WSGI.

So it will be interesting to see

how it handles async.

We'd love to get one of the big poobahs

of Flask to come on and talk about that.

But also Ruby on Rails,

we're going to have David Hennemeyer Hansen on next week.

And I don't believe that Ruby is async or that Rails is.

So that'd be an interesting question for him.

How are they thinking about that?

I'm sure he'll have opinions.

But this is something in terms of why Django?

It's another feather in the cap of, you know, it's not mature yet, but it will be.

And it means that Python has, you know, the ability to do all these node-like features

that right now, as you said, people say, oh, you've got to use Node for this.

Yeah, you shouldn't have to change your language just because you need higher throughput.

I mean, sure, there will always be some kind of really tight embedded situation where Python

is not the language of choice, right?

But that shouldn't be the 90% case, that should be the, you know, the one in a thousand, one

in 10,000 case, not, you know, 10% of cases where I've got to change a language.

So you don't want to have to change language and asyncio really brings that, enables

you to stay in python and then with django being as it is you shouldn't have to change web framework

just to do these yeah no it's it's you know i need a higher throughput endpoint you shouldn't

have to change your web framework for that so you won't have to and that's for me is really super

but we didn't finish talking about background tasks so install it you can already spin up a

lightweight background okay um and yeah i think we'll bring that in and then that will that's not

going to be a full queuing solution you're always going to need you know something more robust but

which may be built on top of Async,

but as you scale up,

you're always going to need something more substantial.

But for, I want to send an email,

I want to render a PDF,

those kind of basic tasks,

out of Request Response Web 101,

you'll be able to just do in the framework,

spinning up a background task.

That's on the roadmap,

but that's how it's going to be.

Yeah, I know, it's really exciting.

Looking into the crystal ball.

And so, is there any other major 3.0 features?

I mean, that's a pretty big one.

Oh, yeah, yeah, yeah.

So the other one, other big one is MariaDB compatibility.

So up until now, we've supported SQLite, Postgres, MySQL, and Oracle.

And the MySQL fork, open source fork, is MariaDB.

And whilst that's kind of has, there are compatibility differences.

And so it's kind of been compatible, but not quite.

And now from 3.0, it's officially supported.

So all database features will, you know, get the same love and work and attention that we give to all the backends.

Well, in our chat with Adam Johnson, he talked at length about MariaDB MySQL.

And so folks want to learn more about that.

So if you're in the MySQL world, then MariaDB is the way to go, I think, now.

It's the open source option.

And I think it's, if I'm correct, it's pace of development.

It's faster.

And, you know, it's where you want to be.

It's where all the mind share is.

So what about features that just missed?

Because I saw there was some talk on JSON fields.

Well, hang on, hang on, hang on.

Before we, you know, because my other favorite one is that,

so these are my sort of top three,

is enums for choices for model fields.

Oh, yeah.

So you've been, you know, you've always been able to,

so string field, the example is school years, right?

So you've been a freshman, sophomore, senior.

That is the canonical example, yeah.

Right, well, that's from the docs, right?

So you've been able to define that using strings.

And that's all very well and good.

But what you really wanted to always use was an enum,

which is a constricted list of specific values, right?

So, you know, it's something that Python didn't have was enums.

And then, I don't know, three point something or other enums came in.

But they weren't particularly user-friendly in that you couldn't,

you had to compare, for instance, the enum value with the enum value.

You couldn't compare it with a string and get the right kind of result.

The natural API usage wasn't very good.

And so there was, anyway, that's all been worked around.

And you can now use, for your model choices, you can use an actual enum.

And the nice comparison APIs that you want are all being implemented.

So it works how you want.

So that's a really good feature.

And I think for most users, that's actually the most significant feature.

Yeah, that may sound subtle, but if you've done anything with choice fields, that's a really big one.

I mean, didn't anyone use Django braces and it had a choices thing which tried to implement?

And that was great, but then you got sort of caught in this,

oh, I've used this Django braces field and I can't quite work out how to escape from that

because it added this whole scaffolding around choices.

Well, use an enum.

An enum is almost always going to be the natural.

There's enums, special subclasses for string types.

So if you want a freshman, sophomore, senior type enum, there's a special class for that.

Or if you want integers, there's special classes for that.

So, you know, one, two, three, four might be your choices.

Or you can create a subclass for your own field type, you know.

Yeah.

I don't know what you might put in there because those are the obvious ones.

But for most users, that's just an awesome addition.

Yeah.

So who do we have to thank?

Again, I always like to call out for both for MariaDB and then for the enum.

Who's been leading the charge developmentally?

Well, Shay and Nick Pope are the big ones that have been doing it.

They, yeah, so Nick pushed that over the line finally.

That took a lot of work.

It was because there was some debates on the mailing list

about how it couldn't be this way and it couldn't be that way.

And there was a bit of pushback.

So that it's in is awesome and credit to it.

So three major features for 3.0.

There's some symmetry there.

Yeah.

Oh, well, speaking of the docs too,

I wanted to separate from the Google developers list

because there's also

the Django users

Google group

which I think

most people can agree

the format is maybe

not ideal

I think Andrew Godwin

launched a discourse page

that's on

I think

we'll link to it

I think it's

forums.django.com

with Marcus

and Tobias

yeah a bunch of people

but I'll link that, and I want to be pushing that

because I think that's a really welcome addition to the community.

Yeah, so that's a discourse forum, right,

with discourse being the back-end software that's used to run it.

Yeah, and that's something I've thought about just doing for a long time

because there isn't a great user-friendly place

where kind of everyone hangs out to answer questions from users.

Yeah, and I think that's the thing.

Everyone hangs out.

I mean, so, you know, you or I might start a forum,

but it's just you know it's just a forum on our website we know but because it's you know forum.jangoproject.com

hopefully we can get the critical mass needed to make that into a welcoming and definitive

yeah location to get support exactly and yeah and we'll put the link but it is i typed in

forums.jangoproject.com it wasn't working i was like what's going on but it's forum

so we should probably get a redirect on that so that's exciting news too so uh oh so i um

so 3.1 so maybe json fields or yeah so that's that was um a google summer of um project uh

summer of code project that went on over the summer and it's so nearly ready um but it was

just coming in too hot so sage whose last name escapes me momentarily um did that and he's done

a brilliant job and it will be you know it needs another going over a couple months more and it

will be merged in and that will be 3.1 but what that gives us is um json field for all the supported

dbs including maria yeah um and so that's that's just awesome like so for me one of the i not

always use json field but i use json field a lot and what that has meant for the last few years is

that even just spinning up a um a test project about an idea on my laptop or i'm just playing

around i've had to um spin up postgres now i've always got postgres spin up but it's just

that one extra hurdle was what i really want is to just use sql yeah i really like sqlite i just

want to use that and i want to use that until the point at which i've got concurrent rights in which

case then i'll you know think about switching and i haven't been able to do that um now you can or

you will be up with the json with the built-in json field i'll be able to do that and i think

that would be super because people will be able to explore json field without this whole extra step

of spinning up a separate um right which there is i mean i'm thinking of this in the context of

my talk at django con is going to be on search and we're going to do an episode on that but

to use postgres's built-in full-text search which is built into django you have to spin up postgres

and that's not an easy task and there isn't um you know i'll show a way to do it um i like doing

it with docker and i show in chapter two of django for professionals my new book you can read that

for free online but um there's a lot of different ways to do it and it's a big hurdle even for me

just going through the examples thinking of the talk i was just like oh god i gotta like you know

escape sequel light start project land and you know make it a little more real so um it's really

nice not to have that hurdle to play with the fields yeah but i mean just out of interest

There's full-text search support in SQLite, too, right?

But not built into Django.

Right, okay, so let me just write that down.

We've got to get that working.

I mean, Simon Whitteson has done amazing stuff with search on SQLite.

Yes, he has.

Why aren't we robbing all of that and putting that into Django?

We can ask him at DjangoCon.

Yeah, he's started his fellowship at Stanford.

Okay, so anything else?

That was the high points.

I wanted to, you know, these releases come out.

the version numbers is really scary to beginners and in practice it's you know django is quite

mature there aren't are there any breaking changes that's actually a good question i know there'll be

a full write-up yeah there's a list but they're not major nothing like it's not like when we

changed the middleware for 1.10 or something like that which even that wasn't a big change you just

had to you know change the middleware classes to middleware in the settings and you had three

versions in order to do that so it wasn't the end of the world but like um there aren't any big

structural changes like that is what i'm right and we'll we'll do a full episode and i'll probably

write some tutorials in december when it launches live but for now if you're listening please do

go get the alpha try it out yeah if you've got continuous integration and you could run an extra

build on your continuous integration with the alpha then that would be amazing because that

tells us either that we did break something in which case we can fix it before um the final

release or it equally importantly tells us that we didn't and you know yeah that's a win either way

All right. Great. Well, this is a shorter one. We want to do some more shorter ones instead of the lengthier ones we've been doing recently. So yeah, if you want to give us feedback, we're at chatjango on Twitter. And all the episodes are at jangochat.com. And we have a new newsletter. So if you prefer to get an email telling you about what's happening, there's a link to do that on the website as well. So I'll talk to you next time, Carlton.

All right. Take care. Join us next time. Bye-bye.