One of the major areas of innovation in Python, especially Python 3, is advances in async and
concurrent programming. Yet when working with any of the major web frameworks, Django, Flask,
or Pyramid, there is basically no concurrency option. That's why Andrew Godin decided to tackle
the issue on the Django side with his project Django Channels. This is Talk Python to Me,
episode 98, recorded January 17, 2017.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter
where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm
and follow the show on Twitter via at Talk Python. This episode is brought to you by Metis and
Hired. Thank both of them for supporting the show by checking out what they have to offer
during their segments. Andrew, welcome to Talk Python.
Thank you. It's very nice to be here.
Yeah, I'm excited to have another Django topic on the show. I don't cover Django that
often and people really love it. And I'm excited to sort of mix together the worlds of asynchronous
programming and Django and this cool project that you're working on called Django Channels.
Yeah, I'm excited to talk about it too. Like it's combining one of the hot new things in
Async with one of the boring old things in Django, one might say. But yeah, it's going to be a good
thing to talk about. Hopefully people can learn some stuff from this.
Yeah, I'm sure they will. I'm sure they will. And before we dig into that though, let's hear
your story. How do you get into programming?
So I have sort of those almost cliche stories. Like I got into programming about the age of 14
or 13 or so. Just like sort of the young sort of programmer model. I started off weirdly on a,
I think it was a Palm Pilot 3 X. Just writing in like sort of simple basic program running small
games. And that quickly went into like doing JavaScript and websites and then doing PHP.
And then finally about, about 10 years ago now going over into doing Python. And I've been doing
Python ever since pretty much.
That's really cool. What language did you program the Palm Pilot thing in?
It was like a weird variant of basic. Like I need to go back and like find the actual program,
like posterity, but it was like a very simple basic, had like basic graphical stuff and audio
stuff. Like a simple breakout clone, a sort of touchscreen keyboard, a few things like games
and interactivity has always been a big part of my attraction to programming. So like that's,
that's why I started out doing definitely. And that's kind of almost still where I do a lot
of my hobby stuff outside of web stuff.
Oh yeah, that's cool. Games, games are definitely fun. Although they're both easier and harder
these days, right? The programming languages are better. The tooling is better. But if you're
going to make a serious game, like that's a, that's a team of people for a year, right? Like
it, it's not just, you can throw out something really simple and it'll sort of compete.
Oh, like starting a game is super easy. Finishing and polishing one is the hardest thing in the world.
Like I've, I've released one of them. It took me like almost two years for a simple puzzle game.
So I'm very aware of how hard it is. I have a lot of respect for those teams that make actual
proper games.
I do as well. Absolutely. I worked on some 3d simulators and stuff for a while and
after that, I'm like, okay, this is really interesting and it's probably not something
I want to do anymore. So, so you said you got into Python about 10 years ago. Like what was the,
how do you get introduced to it?
Oh, it's all a bit hazy now. So I know in particular that, actually it was more than 10 years ago.
It's about 12 years ago now. So that the first thing I ran into, like I was running PHP apps at the
time for, you know, for about three or four years before this. And then I ran into turbo gears and turbo gears
back then was just sort of a couple of other packages glued together with extra stuff.
And that was my introduction to web programming in Python in particular. Like I was looking for an
avenue away from PHP and you know, the number of security vulnerabilities, even in my first open
source product back then was astonishing, including the ability to read the ETC password file. So that
was fun.
So I was like looking, I was looking for a sort of alternate language and I think Python
cropped up as like a common suggestion and turbo gears was one of the big things at that point.
Django was around, but very young and new as well. And so I sort of started out doing turbo gears for,
for a couple of years. And then I had the opportunity to go and work at an agency with Simon Willison,
who's one of the co-creators of Django. And it is those four or five short weeks with Simon,
who is, if you ever meet him, one of the most enthusiastic people in the world that converted
me from turbo gears to Django by almost just force of personality. And I've been doing Django pretty
much ever since.
Oh, that's really great. It's, it's lovely to be around people that are so excited about technology.
It just, it draws you in, doesn't it?
Oh yeah. I learned so much. Like I, I, I basically pair programmed with him for like,
you know, three weeks continuously almost. And I just learned so much both about like,
not only like how Django works and how Python works in general, but also like a lot of the
philosophies of like, you know, things like the Zen of Python that you don't necessarily learn going
into the language per se, but you sort of pick up along the way. So that's the kind of stuff that's
really valuable.
Oh yeah, absolutely. That's really, really great.
Let's talk about this project that you've created, Django Channels. Can you just kind
of tell us briefly, you know, what is Django Channels?
It's a very hard thing to describe, but I'll have a go. So Django Channels is actually,
it's kind of two things. It's important to, as we talk about it more in the podcast.
So first of all, so the headline feature as you were is Django Channels is a way of having
WebSockets supported in Django. And we can, we can go in later on as to why that's difficult and hard,
but needless to say that until Channels existed, WebSockets was very hard to do in Django just
due to some of the technical limitations therein. But the second part of Channels is sort of this
underlying layer of like to solve the problem in WebSockets, there's a lot of interesting
technical challenges that go with that. And so part of it is like, well, how do we solve the problem of
writing semi-asynchronous code, not fully asynchronous code, but semi-asynchronous code with Django and having
things like the Django ORM and the middleware and stuff and things that people are familiar with
still work. Like how do we keep all that stuff familiar yet also have an extra power in there?
And so it's sort of this two-faced story of the underlying solution that powers everything.
And then on top of it, the nice layer of, and here's WebSockets support to go on top of it.
Okay. And just making that really easy and giving people a great API for it, huh?
Yeah. So like, you know, the channels part, sort of the top layer is very much the let's have a nice
design thing with a good developer experience that says, hey, you can WebSockets. And more importantly,
it's very hard to shoot yourself in the foot or deadlock or live lock or any of the things that
asynchronous programming gives you as like sort of loaded ammunition very easily.
Absolutely. So before we dig into your project too much, like let's talk about how asynchronous
programming in Django without your project works today.
Today, Django doesn't really do nearly anything asynchronously. So like if you are at all familiar
with Python's asynchronous solutions, Python really wasn't designed to have asynchronous programming in
it, which is fair enough. It's a very old language. It's incredibly old at this point in some ways.
And so especially in Django, which itself is over a decade old now and was built back when Python
2.4 was fresh and young, a lot of the ways Django is built are not built around the ideas of async.
And in Python, you have to build with async specifically in mind and build around things
like async, hyalur, twisted to have support for that stuff. And so before today, you just couldn't
do it in Django. Like there's no way you could like yield and let something else run. Like if you wanted
to do say, go and fetch a couple of web pages, you might be able to fetch those in parallel in
one worker process, but that's as much as you could do. You couldn't share the load. And in particular,
things like WebSockets, you would have to tie up a single Python process for every terminated socket,
which as you can imagine, quickly wastes all of your worker processes. Like for HTTP, it's great. Like
the process spins up, does a request. You know, if you've got a good site, like maybe two,
300 milliseconds, finishes the request, moves on to the next request. With a socket, it holds open
forever. And so you're quickly going to run out of those non-asynchronous worker threads. And like,
that's kind of the problem that you butt up against very quickly.
Yeah. You're going to run out of space really quick. If that's the case. Sorry, our website is busy. We
have seven people on it. Could you come back later? Yes. You're in a queue. You're number five in the
queue. Exactly. You could give them a cool little countdown. That would be nice. Oh yeah, no. You can
make it really not a really nice experience around this really whole full internal programming you have.
Nice. So what was the motivation or what pushed you to go and create channels? Like it's one thing to say
Django doesn't support this ASIC model super well. It's another to go and I'm going to fix it.
Yeah. And you think I would have learned as well. So like for this list is not familiar. My path into
Django core team in particular was based on writing South, which was Django's sort of what one of the initial
migration frameworks for database migrations for Django. And over the time, about eight years it took, I think,
it became the de facto solution and then the only solution really much. And then finally it was moved into core.
And so I had basically just finished like doing all the porting into Django core. I finally,
like after eight years had a bit of a break. And of course I went, what other hard problem
needs solving that I can go and look at? Like this is the awful part of my sort of like idle thinking.
And in particular, I've been interested in WebSockets for quite a while. So like since they came on sort of the browser scene,
well, four or five years ago now, I'm not, I can't remember the timeline perfectly. I've been looking at them
sort of very intently. And like in particular for game related reasons, right? Like WebSockets are this
unique thing in the web where you have very low latency, bi-directional communication with no overhead.
like Ajax is like one way. It's got quite a lot of overhead. It's quite slow.
And it's hard to even send things from the server to the client without prompting. So I was like, okay,
I'm interested in this. And then back then I sort of played around a bit. I used eventlets and sort of
kept up with the ever-changing WebSocket specification, sort of fixed eventlets as the
spec changed a little bit and tried to keep up for it. And then, and then dropped off for a while.
And about that time, Aymeric Augustin sort of took on the challenge of WebSockets and Django himself.
And he made his own attempt to this where he had a different arrangement to it. And I sort of played around
with that, like, okay, this is, this is pretty interesting. I like that.
And there were lots of other attempts. And a lot of the common pattern was that you would,
you would have Django running normally with WSGI. And then you would also have a separate process.
And that separate process terminates WebSockets. And then somehow, often with either mystery or some
kind of magic, the two processes communicate with each other. And you can hand off things from Django
to WebSockets and vice versa. But it was always sort of bolted on. It wasn't, it wasn't really a good
sort of like clean solution. It often didn't feel like Django as well. You know, it was,
this extra server you ran just WebSockets. And I was like, at some point, you have to have that
separate server idea, as we'll come to later anyway. But I wanted to sort of like, how can we make the
solution that is more encompassing, that supports both WebSockets, and also other things that need
the same kind of problems, like long pulling HTTP, and sort of other protocols, like incident of things
protocols are often like this too. So how do we encompass all those problems into a common thing
that also feels like Django integrates really well with Django?
Right. That sounds like a great, great goal. And really definitely something to start working for
to bring all that in there. I think one of the challenges is you want to support WebSockets,
but you also talked about like HTTP long polling. And there's a few other styles as well.
Some kind of like frame, like long, slow frame or something like that.
Yeah.
What's that called?
There's lots of different names for it. Like, I forget. The idea in particular is that you open a,
you have a response and you send it in the chunked encoding. You send like one chunk and then wait.
And browsers can actually, the JavaScript doesn't actually look at chunks that come in. So you sort
of like fake a one-way socket that way.
Exactly. So the challenge is you've got WebSockets, which when you started this project, what year was that?
The project was conceived in late 2014, I would say.
But there was a long period of me playing around with prototypes and ideas and a lot of failed attempts
and failed API versions at trying to make a good API before it sort of emerged in 2015, pretty much.
Okay. So you didn't have too much of the problem of browsers not supporting it, but still,
if you support WebSockets, long polling, some of the other variations, you've got to have like graceful
fallback and negotiation and all sorts of interesting things that not just implementing pure WebSockets
solves, right? You've got kind of a better solution than that or a broader solution.
Well, actually, so no, so channels doesn't do fallback. And it's one of the things that's
interesting and like one of the things we plan to do, but like, so in terms of scoping, one thing I have
learned from South is trying to keep scope small. And in particular,
I wanted to solve the problem of the core problem of how do we have basic async stuff in Django
initially without having the fallback stuff. And we are working on fallback, but like in Django,
in channels today, you can do long polling. You can do the sort of frame by frame push. You can do
the fallback stuff. And so the fallback stuff isn't there mostly because I didn't want to reinvent the
wheel in that regard. I wanted to reuse one of the existing solutions like Sock.js or Socket.io,
one of the other ones that already exists in the JavaScript world. And so the initial version was,
okay, let's build initial great support for just WebSockets, just long polling, just pushing stuff.
And then later on, come and then join them together into a more sort of cohesive whole,
if you will want that stuff.
I see. So even though you support the different protocols, it's basically you're saying like,
look, if you want to use this in your web app, put some bit of JavaScript that will select it for you.
And we'll just stick with that one rather than having some really complicated negotiation.
It's partially that. And partially also what I tell a lot of people is that in some ways,
if you're just using one of the wrappers around sort of that hides all the different things it's
transporting over, you don't have as many guarantees, right? Like if you have a wrapper,
you don't know your underlying connection is actually good at bi-directional communication.
It might just be a long poll Ajax call. And those are really bad at say,
pushing data from the server to the client. So in many ways, I'm encouraging this for,
if you really need WebSockets, like a hundred percent, like, you know, you're doing
real time-ish kind of stuff or programming or games or whatever, or chat stuff,
then this is the right stuff to do. Like you've got the right level of abstraction.
If you want that sort of wrapper around stuff, sure, you can do it, but you might be better off
just building anything long pole anyway, because then you can build to a set of guarantees that you
can sort of understand. Right. That is the problem. If you let the system auto select
basically different transport protocols is you don't really know what you're going to get, right?
Yeah. And of course, WebSockets are more efficient. Like often you want to pick them
over long polling, but in terms of scoping and trying to sort of pick what to work on,
I pushed that stuff back in favor of just getting it working first.
Yeah. That makes a lot of sense. So I haven't checked can I use.com for WebSockets in a while.
What's the likelihood that people coming to my site would be able to use the best version,
the WebSockets?
So you have a deadly combination of it's mostly supported by all the new browsers.
So, you know, like your new Chrome's new Firefox's I think even Edge has support for it these days,
but you've got problems like mobile Safari, I think still doesn't support it properly.
The old Android Chrome's probably won't do it properly either.
And then on top of that, you have the problem where WebSockets isn't normal HTTP.
And so a lot of proxies and corporate firewalls just block it entirely.
And even then, if that works properly, your server and your hosting has to support HTTP 1.1
to correctly get this protocol.
So what happens is it starts off HTTP and then sort of upgrades itself midstream into a binding protocol
and just binary happens in the middle of it.
And so if you don't understand 1.1, then your HTTP server is going to go like,
what's happening?
And just like basically return 200 OK and break everything.
So it's really sort of you need to trio things to work properly.
And sometimes that can be pretty tricky to have.
Right.
And you don't always have great visibility, especially with the proxy servers or the firewalls.
Yeah, the firewalls are the worst thing because like browsers, you can test in JavaScript pretty easily.
And the server side stuff you have control over.
But sometimes those proxies or firewalls can really sort of throw a wrench in the works.
Oh, yeah, absolutely.
So we talked about WebSockets and log polling.
What are some of the other features that you support?
There's things like custom events and tasks and a number of other things as well, right?
This is what I mentioned in the beginning.
Like it's not just the support for WebSockets on top.
Like there's this whole underlying layer that's basically an event driven layer inside Django.
And it happens that on top of that, there is WebSockets and log polling.
But also you can use the same code for whatever you like.
So if you want, you can have a custom set of events or custom channels that you send things to.
You can have custom protocols, interfaces.
So right now that people working on things like a Slack interface that sort of there are channels for when you get a Slack message into your server.
So you can write bots very easily.
So you can do things like if there's like 10 people on the site, one person could send a message and you could like broadcast that out to the other people who are around.
Exactly.
Yeah.
And so like that in particular, the thing called groups and groups is a sort of built in primitive for almost like broadcasting to multiple and receiving channels.
So it's like basically channels is a couple of primitives.
Like there's a channel where you can send and receive stuff.
There's a lot of guarantees around the way it's designed.
There's groups for broadcast and then sort of this interface or API for sort of low level talking and communication between processes.
And on top of those primitives is built.
The WebSocket spec is built the HTTP spec.
And if you want to, as we're doing it at Eventbrite, in fact, you can then take that low level spec and build, say, a service oriented architecture system on top of it as well.
And that's what we're doing at Eventbrite.
Oh, very cool.
So you guys are using Django channels at Eventbrite?
Well, so in particular, the underlying layer.
So the underlying layer is rather unimaginatively called ASGI or ASCII.
And what it is, it's definitely not a whiskey replacement.
100% not.
And what the idea is, it's like ASGI is a specification for there is a thing that can pass messages around on named channels.
And you can send to named channels and you can receive from them.
And it gives you a few basic guarantees, the methods to call on objects, a bit like dbapi2 is in Python, dbapi2.
So things like, you know, there is a send method, there is a receive method.
You can do groups in certain ways.
And if you just have that, you can take things like the Redis transport we've built that Django channels runs on and use it for whatever you like and do message passing inside just pure Python.
Like you don't even need Django.
Like that part is a pure Python library.
That's really cool.
So basically, if you've got something that can act as a transport like Redis, like a Redis Q or something, then you're good?
Well, yeah.
So it's more than that.
So like what happens is like the ASGI spec gives you certain guarantees.
For example, it guarantees messages delivered at most once.
So either you get it or you don't.
The opposite choice being at least once, meaning you get it or you get two of them.
And that's a choice you have to make.
And it has a lot of those choices like, so you have a message expiry, so you get like 60 seconds.
You have back pressure, so you know if a channel is full.
Sort of all these sort of guarantees that if you're building any sort of distributed system, you want to know what these guarantees are and sort of program against them so you understand your trade-offs you're making.
And so it comes with a preset set of trade-offs and then code built against those ready.
So like there's one that uses Redis for transports using lists.
There's one that uses a local shared memory segment.
There's one that just works inside a process for like sort of unit testing.
So you have a nice lightweight one to write unit tests against.
And also we have somebody working on a RabbitMQ one right now as well to use RabbitMQ if you want to use that stuff.
Oh, yeah.
That sounds really cool.
A lot of options there.
Let me take just a moment and tell you about Metis, a sponsor of this episode.
A data scientist's responsibilities can range far and wide.
How can you be sure you have the necessary skills and training to enter the field or keep up with emerging technologies?
Metis, a data science training company based in New York City, San Francisco, Chicago, and Seattle, provides full-time immersive boot camps,
evening part-time professional development courses, online resources, and corporate programs,
all with a goal of training you to become a data scientist and help you stay on top of new and necessary skills.
Metis has a long list of professional development courses starting soon in any of these four cities taught by industry leaders.
Interested in honing your skills?
Then these courses are for you.
How do they work?
Courses on topics like data visualization, deep learning with TensorFlow, machine learning,
and statistical foundations run two nights a week for six weeks during the evening hours that fit into your busy schedule.
These courses are laser-focused on relevant topics and skills that are sure to enhance your career.
They have a special offer for you at thisismetis.com slash talkpython.
Be sure to check out what they're offering.
It helps support the show.
You talked about ASGI, and people are familiar with WSGI, Web Service Gateway Interface.
What's ASGI?
What's the A for?
Asynchronous?
Asynchronous, exactly.
As I said, it's very unimaginative.
Essentially, I had to find a name, and I stupidly chose to go with changing one letter of WSGI.
It's not even that similar to WSGI.
It does also have a way to transport HTTP over it, and that's kind of where it's semi-related.
But also, it's basically more of a specification for message passing at some point as well.
So, not the best name, but it's now stuck in everywhere, so I can't really change it.
Right, absolutely.
Well, and if you look at the WSGI interface, the API, it's really, really simple.
And there's really very few hooks for asynchronous programming in there, right?
Especially bi-directional stuff.
Exactly.
In fact, one of the things I love about WSGI so much is how simple it is.
The interface, literally, you must be a callable.
You must take two arguments.
That's the entire interface of WSGI, pretty much.
There's a specification of what the environment looks like and where you get your stuff from,
but it's very, very simplistic.
And so, certainly, that was an inspiration to me of like, well, I want something that's
similarly very simplistic that you can write against as well.
And so, that kind of came along.
But the thing, and the place where WSGI falls down, is that it has no support for asynchronous
programming at all.
Like I said, it's a callable.
It's not a yielding thing.
It's not a twisted deferred returner.
It's just a blocking callable that returns when the request is done.
All right.
That's like the exact opposite of asynchronous APIs.
Pretty much, yeah.
Interesting.
So, if I write some code here against ASGI, how interchangeable is that?
Like, what web servers kind of run around?
Like, a micro WSGI, G-Unicorn.
Like, does it plug into any of those?
Or what's the story there?
There's two separate things.
There's ASGI, which is like sort of the same.
Like, here's the thing you can send messages to.
And then there's the HTTP over ASGI specification.
That's kind of the WSGI equivalent, right?
That's like the, here's how we encode requests.
Here's where the URL variables come.
Here's how you send a chunk response.
Like, that stuff is specified as like the format of messages you send over the channels,
basically.
And because of the way it supports more than WSGI, it is, of course, not directly compatible.
And so, in particular, right now, there is one reference server, which is called Daphne.
Daphne is basically bits of Twisted and bits of Autobahn, which is the really good Python
WebTockets library, sort of hot glued together in a way that just sort of does the specification.
And people are also working on, there's been a micro whiskey plugin being worked on.
Somebody has very bravely been working on a Microsoft IIS plugin, which is really impressive.
Oh, yeah.
That's interesting.
Serious work going into that one.
But in particular, there's also the idea that it's a superset.
And so, an adapter from one to the other is not hard to write.
And in fact, there is a half written adapter already in the code base, where you can plug
in an ASGI backend to a WSGI server.
It sort of just translates between them.
But the key problem is, of course, that doesn't let you run WebSockets because WSGI doesn't
support WebSockets.
And so, that lets you sort of proxy things to servers that look like old traditional
websites, but doesn't give you all the new features that you might want.
And for those new features, things will have to be like natively supported, basically.
Yeah.
So, that's why you've got things like Daphne.
Exactly.
So, Daphne is like sort of the reference server.
And I would love to get like a proper micro whiskey support in there as well.
Like a second option, maybe Junicle.
I just sit down with these servers and like seriously look at them and see if I can like
think of like, can I patch them or like, can I change the design set?
Like just solve that story.
So, I'm not just like here, run my special web server.
It'll be fine.
It's written by just Andrew on his spare time.
It's probably okay.
And change that story.
Like there is a ecosystem of things you can pick from is the idea.
Yeah.
That's really fantastic.
And cheers to the guy doing IIS because when you're hosting on Windows or you want to host
it in somewhere like Azure or something like, that's the only choice, right?
It's not like Linux where there's a variety of things you put together.
It's just like people on Windows, they just use IIS and that's that.
So, that's really cool that it could unlock that.
Let's talk a little bit about the sort of Django patterns.
Like how is this similar or different to the stuff that people already know?
Like the idea is to sort of keep it familiar.
So, obviously, we can't make it the same as Django because like some of the things that
sort of hobble Whiskey also hobble Django.
Like Django views are the same kind of they take a request, they return a response.
You can't really do much inside them.
And so, my goal was to take things that look and feel familiar and crucially have the same
safety guarantees as normal Django.
So, you can code with them the same way but also support these extra abilities.
And so, like the main thing here is and the sort of top of the thing is things called
consumers and consumers map pretty much to Django views.
And the idea is whereas a Django view takes a request and returns a response, a channel's
consumer gets a message and then can send zero or more other messages.
So, for example, if you wanted to listen to incoming WebSocket like chat messages, the
consumer will be tied to the request channel.
And every time you send a thing in on WebSocket, it would be like, okay, I've got a message.
It would launch the consumer.
The consumer can run, handle the message, and then maybe send some messages to other clients
or sort of broadcast it, store it to a database, and then it exits straight away.
And the key thing here is that the consumer, it takes one argument, which is a message object,
which is kind of like the request object.
You can have session and auth support the same way you can in Django too with decorators.
It's like message.channel session or message.user, that kind of stuff.
And also, as long as you stick to the thing of not doing blocking options, blocking things
in the consumer, it actually makes it almost difficult, almost impossible to deadlock the
process because it's not proper async because you can't block or listen to other channels.
And because you sort of have to take the message, run through the logic, and then exit pretty
much immediately, it means that we can actually churn through messages in the same way that
Django might churn through HTTP requests with a very similar kind of set of guarantees and
safety concerns.
Well, that's really interesting.
I hadn't really thought of the views themselves actually having to be so cognizant of this async
world, but it totally makes sense.
Yeah.
And in particular, the nice thing is that views end up being just a subset of consumers
because a view takes a request, which is just a message in channels land, and it returns
a response, which means sending a message.
So it actually means that views end up being a subset of consumers and it all sort of neatly
wraps around.
Sure.
You talked a couple of times about the ability to basically deadlock yourself.
Yes.
I've seen that before in some of this WebSocket sort of callback style programming where you're
waiting and you can't receive the message because you're waiting, but you're not going
to get a response.
Can you maybe describe some of the ways in which you could like wrap yourself around in that
trouble or just sort of give somebody an idea what to look out for?
Yeah.
So the classic thing is where you have a process that sort of it gets a message and say it then
waited for a second message.
It's like, okay, I'm going to send a thing and say, I want X and then wait to get X back.
The problem is if one process says, I want X, the other process says, okay, I've got X,
I want Y to the other process.
They're both then blocked in the thing of waiting for their response, but they both can't serve
the response to the other process.
And that's a deadlock basically.
And that's very easy to get into if you don't have either an excellent knowledge of your
system architecture and asynchronous programming.
Or if you have a framework that sort of builds in or so what channels it isn't, but channels
deliberately doesn't give you full async so that it's much harder to toot yourself in
the foot.
Like we don't let you block on things because that makes it very hard to like, we said,
yeah, you can't, you can't be blocked.
You can't deadlock because you're waiting on something.
If you can't wait on something, right?
Exactly.
And if you want to, if you want to have that sort of low level control, you can just drop
down into sort of normal Python and just write your own async stuff against the ASGI interface.
But the channels level, sort of higher level one that we keep sort of safer and easier to
stomach.
So the idea is like, if you're coming into this as a web developer or maybe using as a
brand new developer, the number of scenarios where you can have not only errors, but errors
that are impossible to debug is greatly reduced.
because deadlocks not only nasty, but knowing they've happened and debugging that that's
what's happening is really difficult.
It's super difficult.
Yeah.
And I heard them described as Heisen bugs.
Yes.
Because, you know, even when you like know that they're there by observing them or interacting,
like putting logging or other stuff sometimes can change the timing, which actually changes
them.
Right.
So super hard.
One of the, one of the worst things is they often happen only under high load.
So like, imagine you have like 10 worker threads.
If you just have like, like five requests a second, it will happen perfectly fine.
As soon as you hit like over 10 requests a second, say, and you use all 10 of the threads,
that could then trigger the deadlock because all the thread, all the work is suddenly consumed
up.
There's no spare workers to handle these extra requests.
And so like, it might be fine in development and you need to point to production.
It's fine in production.
And then one Sunday evening when your website's under high loads, suddenly it locks up and there's
no traceback.
Like what's happening?
I don't understand.
It's like, it's a really nasty sign of error.
Yeah.
It's super bad.
And I think it's awesome that your framework like makes that harder.
That usually that's the kind of stuff that happens right when you need the website to
work most.
We're running a new ad or we got featured on Hacker News or whatever.
Boom.
It's dead.
Yeah.
And it's, it's not perfect, obviously.
Like we can't stop everything, but like the Jenga philosophy is try and make these things
hard, but a fault.
And so that's kind of tried to be reflected here.
Yeah.
That's absolutely a good philosophy.
So some other design patterns around Jenga that are maybe related like routing and messaging.
Yeah.
So in the other things that's familiar.
So routing.
So the idea is when you say, I have a consumer of this channel, you have to sort of say like
a view.
You have to tie that consumer to the channel.
So like, well, this consumer handles incoming messages on the WebSocket.receive channel.
And it handles the ones where the path is slash chat.
And so there's a thing that looks very like Jenga's URL routing, but is channel routing instead.
It's like, it's not quite the same, but very familiar.
It's like a list of regular expressions basically.
And it has, again, very similar guarantees and a lot of power in there.
And then, as I said before, messages are very much like requests and that like they have
information on them.
You can store stuff on them.
There's session support in there.
It's like, it all feels a bit like you're writing Jenga views and URLs, but it's a bit more powerful
with a bit extra, with a few extra options.
Okay.
Yeah.
Very cool.
And what's the programming model look like?
Like how is it the same as Jenga or how is it different?
So to the end developer, it looks largely the same as normal Jenga.
In particular, channels in its default state runs all of your code, the writer's consumers
and stuff, synchronously.
Like you don't ever run into an async option.
And particularly we run the whole of Jenga synchronously too, because like we can't make
Jenga async.
So we just run Jenga synchronously with the sort of, the way design helps us run it in sort
of a worker thread.
And all the async is handled away from Jenga, basically.
So if you're coming in from that end, it looks pretty much like normal Jenga.
However, if you want to do sort of more advanced stuff or handle different protocols or even
do your own async programming, it sort of drops down and becomes more of a pure Python thing
where you can use whatever framework you like that you can use async.io, you can use twisted,
you can use other things.
And then you just call the ASGI API, send and receive stuff as you need to.
So for example, Daphne is a purely asynchronous twisted program that happens to call ASGI in
the right way inside of it.
So like you sort of get the choice of, do you want the familiar happy world of Jenga without
much power?
Or do you want the raw unbridled power of async?
But you sort of need to be prepared to go into that particular world.
Yeah, you're going down the rabbit hole there.
Interesting.
Exactly.
So is this, if I'm doing the async variant, is this still in the same process as Jenga
or is this like a totally different thing?
So it's a different process.
In particular, like one of the things when I sat down, part of that initial period when
I was sort of like trying to design channels and go through the different options, I had
some things that were threading, some things were using the multi-process module, some things
were using green threads or like yielding like generators.
And eventually I realized that if you're building a large system, as you know, as I do at work
on a daily basis, you're always going to have more than one server, which means you're always
going to have to have more than one process.
And so given that, if I made a model that was just natively multi-processed from the get-go,
that would make a lot of sense in like, not just multi-process, multi-server.
Like let's make the model that is by default, it expects to run everything on like a different
CPU entirely with no shared memory or no shared state and work backwards from there.
And so everything is basically done in a separate process and message passing happens
between them.
And so that's how things are coordinated.
So it's a bit like, say like if you've ever used Go, for example, Go, a lot of Go primitives
rely heavily on passing things between Go threads in a thing they call channels as well, which
is similar but different to channels.
Yeah, I was going to ask you that about the relationship.
The name is the same.
The idea is kind of similar in some ways.
Like, was there any inspiration or similarity?
Is it just random similarity or is there more to it with Go and their channels?
Oh, no.
So the direct similarity that they both share a common ancestor, which is the language called
CSP.
So when I went to university in Oxford, they invented CSPs.
They definitely teach it and they're very proud of it.
It's a language for basically proving asynchronous programs.
And so it's sort of a very abstract grammar of like, oh, we have a process that emits event
X onto channel Y and then a process that consumes channel Y and then gets event X and then does
Y.
And in its core, it's kind of this way of sort of like you can write a set of assumptions
and prove that programs don't deadlock, which is an incredibly nice way of doing things.
But it also has these fundamental ideas of processes and channels and splits.
And so that's where my ideas came from.
And then sort of via Go, I think the name channels came from Go as well, but like a different take
on that same core concept of these are communicating sequential processes, which is what CSP stands
for.
Yeah, this whole actor model is quite powerful for avoiding deadlocks and race conditions
and, you know, writing to the same piece of memory at the same time.
And a lot of the threading problems go away, right?
And not just that, but also like understanding as a developer, like reasoning about systems
is much easier when they are very separate components you can read about individually.
Like if it's all integrated into one big lump, then trying to work out what happening is pretty
difficult.
If they're separated out, it's like, oh, here is Daphne.
Daphne just translates HTTP requests to messages and messages to HTTP responses.
Writing tests for that is a lot easier because we just write tests where we put one thing
in one end, the other thing comes up the other end and vice versa.
Yeah, you have very clear, explicit boundaries.
These are the messages.
Here's where the messages come in.
Here's where they go out.
And basically, this is what they consist of, right?
Yeah.
And then that scales up too.
Like if you're doing engineering at scale, as in with a large team, those boundaries then
become team boundaries.
That really helps you sort of distribute not only the testing, but also like the cognitive
workload of understanding what the system is doing at any one time that you can draw the
same boundaries and have teams work on shared understanding in a much better way as well.
Yeah.
That's a really good point to think about how it lets people scale, not just software.
Oh, yeah.
Scaling.
I'm very proud these days that scaling software development is about half code scaling, about
half people scaling.
Like it's very important to get your team all understanding each other and not being at each
other's throats all the time.
And a big part of that is good specs and good APIs.
Yeah, that's awesome.
This portion of Talk Python to me is brought to you by Hired.
Hired is the platform for top Python developer jobs.
Create your profile and instantly get access to 3,500 companies who will work to compete
with you.
Take it from one of Hired's users who recently got a job and said, I had my first offer on
Thursday after going live on Monday and I ended up getting eight offers in total.
I've worked with recruiters in the past, but they've always been pretty hit and miss.
I tried LinkedIn, but I found Hired to be the best.
I really liked knowing the salary up front.
Privacy was also a huge seller for me.
Sounds awesome, doesn't it?
Well, wait until you hear about the sign-in bonus.
Everyone who accepts a job from Hired gets a thousand dollars signing bonus.
And as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python to me and Hired will double the signing bonus to
$2,000.
Opportunity's knocking.
Visit Hired.com slash Talk Python to me and answer the door.
So if I'm going to run Django app using channels, how's this work?
Can I run it the same?
Probably Daphne is involved somewhere, right?
Basic level, you run two processes.
You run Daphne.
And what Daphne does is Daphne terminates HTTP and WebSockets for you.
So that's what you expose to the world on port 80 or whatever, or probably behind Nginx doing
static file serving or something.
And that sort of fills the role that, say, like G Unicorn might fill.
Like, here's a process that terminates HTTP.
And then separately, you run one or more Django worker processes.
And those processes look at the channel queues that are in this sort of channel routing we
mentioned earlier and sort of just run the consumers on those channels as messages come
through.
And so at a base level, you run one Daphne and you run one worker.
And then it just sort of works as normal Django does.
And in particular, I see.
So the request comes in and if it's like a channel request for, say, WebSockets, it just
stops at Daphne and gets processed there.
But if it's something that matches for Django view or something, it will like pass through
to the Django worker process?
No.
So in fact, Daphne does both of them.
So like both HTTP and WebSockets both get turned into messages on channels.
So that's kind of the difference to a lot of those previous solutions I talked about near
the start of the show is that channels has a sort of slightly ambitious goal maybe of putting
everything over channels.
This includes HTTP as well.
So what happens is if you have a HTTP request that comes into Daphne, Daphne takes it, it decodes
it into the ASGI HTTP format, pass that to Django.
And then Django has a native ASGI handler next to the WHGI handler that takes that, turns it
directly into a request object and then runs the views on that stuff too.
Okay.
Yeah, that's very cool.
So it is the same system as the channels running over basically.
Okay.
Excellent.
And you still have things like run server and so on?
Right.
So run server, like as for development, just you type run, like if you install channels
or type run server, it just runs Daphne and worker for you in the same process.
It's no sort of fitting around there.
It's just easy to get going.
And it means you basically, you can pip install channels, put it in your installed apps, and
then WebSockets just work on your development server straight away, which is really nice
to have for sort of hacking around.
And then sort of the other thing you can have, and I sort of recommend, especially to people
who are wary or like people who are like died in the wall ops people, should we say, is
you can run both WSGI and channels at the same time and just route WebSockets to Daphne
and then route normal requests to say MicroWSGI or G-Unicorn.
And so that way you can use sort of more proven software for your main site, but still use
channels for your other stuff if you want that sort of that trade-off.
Oh, that's pretty interesting.
And you're thinking put something like Nginx in front of it and switch on like protocol
or something.
Yeah.
So you can switch these things, switch on as URL paths, like things on us like slash WS
WebSockets, but you can, with a couple of tricks, switch on the upgrade header as well,
which is how you upgrade WebSockets.
So like there are ways and means.
It's tricky to switch dynamically based on what's coming in.
Like you can do it.
It's very hard to.
So generally I recommend like sort of a path-based solution.
And like there's examples in the channels docs and mailing lists about like how that might
run as well and sort of examples how to set that stuff up.
All right.
So what's the extensibility story here?
So channels is in fact, it's very much built around extensibility.
Like as I said before, like it's not that much in the base package.
You sort of WebSocket supports there and that kind of stuff.
But like it's designed to be built upon in sort of a community way like Django's itself.
So things, for example, like the ability to have proper heart beating of people connected.
So, you know, they're definitely still connected.
Like that is a thing that you could put on top of channels.
And so what I'm trying to do is like foster a community of third-party apps that are built
against channels and the common specifications.
In many ways, that's why I took it upon myself to build a sort of more official, it's not the
right, but to build a singular solution that we can sort of almost tout as Django solution
for this stuff.
So that there is a common thing that people can build against.
Because like a lot of the part of Django success is having a common standard people write against.
Like it's a common known factor.
And so really it's designed around that idea of like, yeah, everyone's going to have the
same routing.
Everyone's going to have the same idea of consumers.
Like things integrate the same kind of way and like trying to encourage that kind of ecosystem
as it were.
Yeah, absolutely.
I, you know, that's definitely a hallmark of Django is all the pieces you can bring
together to make it more than what it is out of the box.
Exactly.
Nice.
Are there like some notable third-party packages or projects that you want to talk about?
Not, not, I can talk to my head.
Like I don't know them off by heart.
We have, we have a page on the docs that links to a couple of ones that are already going.
Okay.
Awesome.
There's also a few more that aren't on there yet.
I encourage the developers to add links to the doc.
Okay.
So let's see.
We talked about Daphne a little bit.
Tell me some of the packages that you're using to put this together.
Yeah.
So like one of the things was like trying like Django for a long time is criticized as being,
oh, Django is one giant package.
It's not split in separate bits.
So I went the entire opposite way.
There are five different packages as part of channels.
So you have the base channels package, which is the, basically the Django plugin side of
things as Django third-party app or second-party app, I guess, or first-party app.
But it's a Django pluggable app that you load into Django.
It does all the routing and run server overloading we talked about before and gives you sort of
the nice user experience.
But it doesn't give you the serving.
And so Daphne is the other half of that.
Daphne is the service.
So Daphne is the server that terminates HTTP and WebSockets and sort of translates them through
into channels for you.
If there was something else there, you could just use channels and a different thing that
wasn't Daphne.
But for now, we bundle them together pretty much.
And then underneath that, there is the ASGI packages.
So the things that build this sort of low-level protocol we build upon.
So there's ASGI ref, which is sort of the base ASGI library.
It has the conformance test suite in it.
So you can, like, if you're writing a new ASGI backend, you just load up the conformance
tests and it just tests your spec, which is really nice to have for new implementations.
And it has a memory backend too for testing, like, in-memory for unit tests.
And on top of that, you have two different backends.
The Redis backend called ASGI underscore Redis.
And that is a standard Redis backend, the one we recommend for production use.
It uses Redis lists and blocking pops and Lua scripts and a few other things in there.
And it has built-in sharding if you want to use more than one server to scale up.
And then as sort of a midway point, there's a ASGI underscore IPC backend that only works
on one server.
And it's designed for, if you don't want to run a separate Redis server as well, you
just want to run things on one machine, keep it simple.
It doesn't perform nearly as well, but it is zero configuration.
You just basically just load it up as the option backend, just set the same prefix and things
just talk to each other on the same machine via a shared memory segment.
Oh yeah, that's really nice.
Really nice.
So what's the story with Python 2 versus Python 3 on this project?
So everything is built Python 3 first.
And in fact, Django itself is going Python 3 only very soon.
as of the next major release, I believe.
That's in Django 2.
And so it's built with Python 3 first, but also Python 2 support is still there.
So channel supports the previous LTS of Django and up.
So that's 1.8 and up.
And 1.8 supports Python 2.7.
So it supports Python 2.7 and Python 3.
All my testing and all my developments done on Python 3.
And then we have Travis just running Python 2 tests occasionally.
And I'll just occasionally pop down to Python 2 and make sure things work expected.
But I've seen like one bug that was Python 2 specific in the entire time I've been developing
so far.
So it's not really a concern at all in that regard.
Oh, that's really fantastic.
And I'd love to see you doing this in Python 3 first.
You know, I talked to the guys at the Beware project, and they're doing Python 3 only.
I'm surprised to hear about Django going Python 3, although excited to hear it.
I think Python 3 is really, it's crossed some kind of threshold or critical mass recently,
I feel.
Yeah, like, I feel the same way too.
Like, in the last year or year and a half or so, we definitely crossed that threshold of,
like, things are coming out in Python 3 only, a lot of cases.
We're finding libraries at work now that were like, oh, this great accounting library is only
on Python 3.
And then suddenly, like, we need to move code to Python 3.
It's become almost this trend now.
And, like, it's difficult for a big company like Eventbrite to move to Python 3, of course.
But definitely, a sea change is definitely happening these days.
And everything I write from scratch is done on Python 3.
Yeah, that's fantastic.
I feel like I'm noticing it in that people are apologizing for it being Python 2 in the
cases where it is, or they feel guilty or bad about it or whatever.
Whereas a few years ago, it was kind of like, yeah, it's Python 2, of course.
Like, haha, Python 3, whatever, right?
So this is really cool.
Tell me a little bit about Django going Python 3, if you know any of the backstory.
What's going on there?
So we decided quite a while ago to draw a line in the sand, as it were.
So, like, you know, at some point, we need to do Python 3 only.
In many ways, because Django's job is, in some ways, as a leader in this area.
Like, if Django is Python 3 only, that's a big signal to a lot of other Python packages that,
yes, you can do this too.
It's a huge signal.
And so the line was decided.
And, like, we debated for a long while.
I'd be like, well, like, what version of Django should we do it on?
Like, when should we do it?
And so different core developers were arguing at different times for, like, oh, well, can
we do it now?
So I think, like, two or three years ago, people would say, like, oh, let's just do it now.
Let's just switch straight away.
And then eventually we decided that Django 2.0 is the first release to only support Python
3.
And in particular, Python 3.5 and above.
Because the reasoning being that Python 3 is small enough that people are pretty much
on the newest version of Python 3.
There's not many differences that start upgrading to Python 3.5.
And so what this means to Django in particular is we can remove swathes of compatibility code.
Like, there's so much in there.
Some of the core devs are literally chomping at the bit to just delete huge reams of code
that are just Python 2.0 specific.
And in particular, like, we can use things like all the new features.
We can get some of the class inheritance stuff and get done properly.
Like, all the sort of stuff that we had to sort of keep going with Python 2 and keep it
there is all being swept away.
And the nice thing, too, is that because it's Django 2.0, we can say, okay, this is a nice
big change.
And in fact, like, the Django number system is changing entirely.
So for reference, what's happening is we're making it so that Django's releases are...
There's every major LTS will be the last number in its major number.
So like 1.11 will be the last one.
Then we'll have 2.0, 2.1, 2.2.
Then 2.3 is the next LTS.
And 3.0, 3.1, 3.2.
And 3.3, the LTS.
And that kind of strategy.
And it just happens that it's kind of timed nicely that Python 3.5 support happens in
Django 2.
So it's a good reason to call it Django 2, I think.
We were worried for a while in Django Core that there wouldn't be a good thing in Django
2.
We'd be like, oh, and this is just another maintenance release of Django with some bug
fixes.
But it's nice to have a bit of a sort of big change in there as well.
Yeah, that's really cool.
And I think changing the major version number sends a strong signal like this thing is different.
Exactly.
And it's easy to pull.
I've been doing for the last three or so years now, pausing code to Python 3, really not that
hard.
Once you get your head around what's going on, and if your encodings are already good.
It's like Python 3, and I like this about Python 3, really punishes you for not having good
encodings, like knowing where your bytes come from.
Which for developing channels, which is all about handling bytes over the wire versus encoded
messages or URLs, is incredibly useful.
Like, oh, well, you've tried to pass this byte string to the Unicode string function.
It just blows up.
It's like having, as long as that's all in order and you know where your strings are coming
from, it's pretty painless to port in my experience.
Yeah, that's really excellent.
And it is sort of that network layer that you see some of the differences between Python
2 and Python 3 more when you're down at the string level and taking bytes and converting
them.
But yeah, it sounds really good.
Yeah, it's really good.
Like, my main complaint is that I keep typing print with a space rather than print with a
parenthesis.
Like, muscle memory is a really hard thing to undo.
Yeah, absolutely.
So when we talked about WSGI and we talked about AWSGI, the asynchronous thing, what came
to mind for me was this concept of WSGI 2, which is being sort of brought into existence by
the pressure that HTTP 2 is putting on the WSGI specification, right?
Yeah.
Other pressures too.
WebSockets is part of those pressures as well.
Yeah, absolutely.
Well, I was, you're right.
WebSockets predates HTTP 2.
But all this sort of, we want to run more than one thing over this channel and we want
to sometimes do it in binary, like just doesn't work at all.
So can you talk a little bit about like WSGI 2 and maybe how that like would either help
or is parallel to what you're doing?
Yeah.
So like I actually involved in discussions for a while.
So there's a group in Python called WebSig and WebSig is sort of the place where things
about WSGI get discussed.
And there's been on and off for like a few years now, at least, I came in pretty late to
discussion, this idea of WSGI 2.
And one of the main problems is that if you want to call it WSGI, it has to look a lot
like WSGI and in theory, backwards compatible as well.
And that really hinders the approach.
And like, as of the time of recording, there's been very little progress on WSGI 2 for like
about two years, if not longer.
Lots of different ideas about what should be done or different approaches, like how do we
even make things async?
And so my conclusion to that was that like Django needs something, we needed something
that existed and worked.
And I read through all the threads and tried to educate myself on the arguments and the
reasons behind different people's visions and wants for WSGI 2 and took some of those
with me to the design of ASGI and in particular the HTTP layer on top of it.
But at the same time, I don't want to stride in and declare a replacement for the WSGI
with ASGI, rather it's a different thing.
I also think that a different thing is the right solution.
I think that Python web systems are more than just handling HTTP responses these days.
And so my ultimate goal is probably to try and sit down, get Django and get more implementations
of this going through.
And then when we have a good set of reference implementation, like two references on either
end, it's proven in production, then take that proven thing back to WebSIG and say, hey,
can we decide on this thing that's already in place that has proof behind it?
And then we can see what's happening with it rather than trying to argue in the abstract,
basically.
Yeah, I think arguing in the abstract is really hard to do.
It's very difficult.
Yeah, you can just go around and around and around.
And I, you know, I don't know exactly what's happening internally at WebSIG, but if it's
been kind of idle for two years and HTTP2 is coming, the web is not standing still.
So I feel like, you know, maybe there's some of that going on.
I am perfectly willing.
If someone comes up tomorrow with an amazing WSGI 2 spec that everyone adopts, I will immediately
drop and support that stuff.
But like, given the lack of movement, I felt that someone has to do something.
And so I decided to be that someone and do something.
Yeah, this is really cool.
I mean, if you get this to be successful and proven, like you said, it's really easy to
take it back and go, look, this is more or less working.
Let's make a spec.
Let's extract a spec out of this general idea rather than debate at an infinite item.
Exactly.
I've been trying to keep conversations going with like various authors or luminaries of
Python web stuff.
Like not enough, but like getting opinions and feedback on like the way things are done.
It's like silly things like cleaning up the, like I said, encoding, cleaning up the encoding
of how strings are passed around in ASGI.
Like ASGI has an exact specification of which bits of the request come through as Unicode
and which bits come through as bytes, which WSGI does not have and can kind of never have.
So like I've been trying to keep a lot of those things in mind.
And I don't know if it'd be successful in the end, but I'm hoping that like pragmatism is worth
a lot here.
And even if the message passing sort of asynchronous bit doesn't survive, the basic format of here's
how you take a request and put it into a message dict would still be useful.
Yeah.
I think it's really positive that you're working on this and hopefully, hopefully that can,
you know, fall this, this blockade or whatever, whatever is going on there.
Some point like doing open source collaboration is really difficult.
Like it takes a lot of effort.
So like it takes not just me, but other people.
So hopefully we can get something, something out.
Yeah.
Hopefully.
I mean, WSGI itself has been so important and so successful that it's just really scary
and hard to change.
So I think that's, it's almost a victim of its own success in that regard.
Yeah.
WSGI is like right next to CGI and like how pervasive and successful it's been.
Like every like Python web program runs on it.
It's incredibly, it's incredibly simple.
It's very powerful and the pluggability of different servers is like a huge boon in its
deployment, right?
Like deployment in Python is never as easy as PHP, but it's pretty damn close considering
like we have all these different options.
So that's really something to aspire to.
I think like WSGI is an amazing specification that I am always in awe of, like every time.
Like I'm very pleased that the original authors like decided to settle on it like so long ago
as well.
Yeah, absolutely.
It's been going like 15 years or something and it's still going strong.
It just, it's starting to show its age.
That world was much less about serving multiple things and bi-directional stuff over the same
channel and all sorts of things like that.
Right.
To survive 15 years in software is an incredibly long time.
Like when Django hit 10, I was feeling, I was already feeling like a bit old.
Right.
So yeah, like it's, it's really impressive.
Yeah, absolutely.
Okay.
So that's, that's really great.
So maybe, maybe one final question is how's all this useful beyond Django?
Like it's, it's cool that we can plug it into Django.
What else can we do with it?
So like really my goal, my ambitious goal at the end of all of this, I think is to make
writing distributed systems in Python easier.
And maybe not even in Python, maybe in general, but like, you know, I am, as like my career
goes on, I find myself writing software, distributed systems are the one challenge I keep both enjoying
and the challenges me time and time again.
And like, I would love to have this idea of message passing, this idea of channels and passing
messages and these, these primitives be the way that Python programs in general, like not
just HTTP, but like chatbots and like internet of things systems and like stats systems, all
these things have this common base construct to build upon and talk to each other and message
pass.
And like, I think that's the ultimate goal beyond Django.
There's certainly a long way to get there.
The middle goal is to have other Python web stuff work with it as well.
But I have like, you know, and I think it's nice to have somewhat grand ambitions for improving
Python in general.
Like the, like, I like Python, the language a lot.
Like I'm not just a Django person, right?
Like Python is my real home in many ways.
So I want to make sure that everyone can benefit from this stuff and to really push the state
of the art forward in that respect.
Yeah.
That's, that's really cool that it's, it's got that sort of broader goal.
You know, you're talking a lot about moving to Python three and this is Python three first.
Do you see a world where you could use this idea of channels and this as the infrastructure
for those channels mixed in with like async and await to be, to make Python much more go like?
That's kind of one of the ideas.
Yeah.
It's like, it's like channels in the spec, ASGI in the spec rather, has provisions for a
async code compatible receive command.
So you can do, you can await on receive and how it blocked correctly and do all that kind
of stuff.
So the idea is really that you can, and moreover, like it's not just that you can write async code,
it's that you can also write synchronous code and have that intermixed.
Like, cause I'm a strong proponent of if the code you can write can be synchronous or
at least can be written in a synchronous fashion, that's fine.
As long as it interoperates properly, like synchronous code is easier to reason about.
It's easier to test in many cases.
So if we can have a system that supports both async code natively and synchronous code natively
and they interact properly and you can plug and replace different parts of the system correctly
and like, oh, well, we've written this part of the system, like, you know, this waiting
room system here is in ASUNKO, whereas like this emailing system here is in twisted and
this part of the system over here is in synchronous code.
I think that's also a good goal to aim for, like flexibility is really important.
Yeah, absolutely.
All right.
That sounds, that sounds like a cool feature.
I'm looking forward to seeing it.
Let's hope we get there.
For sure.
All right.
So I think maybe we'll just leave it here.
This is a really cool project that you put together and I'm excited to see it gain
attraction.
Thank you.
Yeah, you bet.
So before I let you out of here, let me ask you two questions I always ask at the end of
the show.
First of all, if you can write some code, Python code, other code, what editor do you open
up?
I'm a Sublime Text user.
I have been for like four or five years now.
It's just, it's got Python in it too.
So you can't argue with that really, can you?
And now it's definitely the home for Python there.
Have you checked out the Anaconda plugin for it?
I haven't, no.
Okay.
I have my own sort of set of plugins and some custom plugins I've collected over the years
that sort of, they sort of work together mostly.
It's pretty decent.
Nice.
All right.
And there's 96,000 packages on PyPI.
There's a ton that you've probably come across that people haven't heard of necessarily or you'd
like to recommend.
What's on your mind?
And the one I've used most recently, I was really impressed with it is Cryptography, which
is actually quite new given the name is quite generic.
It's a really well done crypto package that is designed in a way where it's very hard
to shoot yourself in the foot.
As you know, I'm a big believer in this.
It comes with these amazing, fully featured primitives for, oh, here is a way to do symmetrical
mesh encryption.
Here is a way to do asymmetrical public private key encryption.
And it's just like, there's safe defaults.
It's easy to use.
And as long as you follow the docs, you end up with a really nice solution that is compatible
properly.
And like, it's pretty quick.
And like, that's what we use inside ASCII reddit if you want at rest encryption.
So like cryptography is my current favorite PyPI package.
Oh, that's really cool.
I definitely think cryptography and hashing and password management, that stuff is better
put into a library or package and just really baked in with the best practices and you just
follow the steps.
Yeah.
I do not want to have to think about it.
Like I want somebody else who's more intelligent than me to solve the problem so I can use their
code.
It does that really well.
Yeah, that's great.
I'm going to have to check that out.
All right.
So before we get out of here, final call to action, how do people get started with channels?
Like what kind of support or help are you looking for?
So yeah, so like I'd encourage anyone who's interested to go over to channels.readthedocs.io.
It's sort of the main channels documentation.
You can see installation instructions, a short tutorial stuff there.
And there's also a big list of stuff we want to work on.
So our GitHub repository, which is github.com/Django slash channels.
There's a whole list of issues there filtered by experience level.
You want to have that kind of stuff.
You can email Django developers or Django users with questions about channels.
It's all part of the Django project.
And then if you want to do work on a big project, we even have some funding available for bigger
projects.
We can dish out for sort of things that are, you know, at least a couple of weeks, sort
of bigger tasks that wouldn't be tackled otherwise in spare time.
So if you're interested in any of those things, like get in touch, mainly this or get in touch
with me directly.
I'm Andrew Goldbin on Twitter.
Just all that stuff.
I'm happy to talk about channels.
Oh, that's really great.
So lots of ways people can get involved.
So many.
Yeah.
Cool.
Andrew, thanks so much for taking the time to talk with me and sharing your project.
Thank you so much for having me on.
It's been a pleasure.
Yep.
Bye.
This has been another episode of Talk Python to Me.
Today's guest has been Andrew Godin, and this episode has been sponsored by Metis and Hired.
Thank them both for supporting the show.
Want to learn data science?
Well, don't forget to visit thisismetis.com slash talkpython to learn more about their upcoming
courses.
Get the skills that you need to succeed in the fast-paced world of data science.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python to me to get five or more offers with salary and equity
presented right up front and a special listener signing bonus of $2,000.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart by building 10 apps at talkpython.fm slash
course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my Write Pythonic Code course
at talkpython.fm/pythonic.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and
direct RSS feed at /rss on talkpython.fm.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
Corey just recently started selling his tracks on iTunes, so I recommend you check it out at
talkpython.fm/music.
You can browse his tracks he has for sale on iTunes and listen to the full-length version
of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.
Staying with my voice.
There's no norm that I can fill within.
Haven't been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.
I'll pass the mic.
Bye.
.
you