WSGI 2

Hello, and welcome to podcast. In it, the podcast about Python and the people who make it great. You can subscribe to our show on iTunes, Stitcher, TuneIn Radio, or add our RSS feed to your pod catcher of choice.

You can also follow us on Twitter or Google plus, and please give us feedback. You can leave a review on iTunes,

send us a tweet or an email, leave us a message on Google Plus or our show notes,

or you can also join our community. Visit discourse.pythonpodcast.com

for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas.

I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.

For details on how to support the show, you can visit our site at pythonpodcast.com.

Linode is sponsoring us this week. Check them out at linode.com/podcastinit

and to get a $20 credit to try out their fast and reliable Linux virtual servers for your next project.

I'd also like to thank Hired, a job marketplace for developers and designers, for sponsoring this episode of podcast.init.

Use the link, hired.com/podcastinit

to sign up and double your signing bonus. Your host as usual are Tobias Massey and Chris Patti. Today, we are interviewing Corey Benfield and Andrew Godwin about a proposed update to the WSGI

specification.

So could you please introduce yourselves? Corey, how about you go first?

Sure. So I'm Corey Benfield.

In my day job, I'm a senior cloud engineer at Hewlett Packard Enterprise, and I work in HPE's upstream team, which means that I basically get to spend my time working on Python open source projects that

HP doesn't know it needs yet.

So I've been doing Python open source a long time now, 5 to 6 years,

and

mostly working on HTTP and Python

so that's been things like Python requests where I'm a core developer

along with urllib3.

I also do a bit of TLS cryptography stuff on the side so I work on pyopenSSL

and I try and help out with the Python cryptography project from time to time.

And the thing I've been spending my most of my time on recently aside from WSGI

is HTTP2

in Python.

So I worked a bit with the IETF to help standardize

HTTP 2, and I've written a couple of Python HTTP 2 implementations.

Andrew, how about you?

Yeah. So I'm Andrew Godwin. I currently work at Eventbrite as a senior software engineer, sort of wrangling our back end stack there.

But my sort of involvement with Python, on the open source side is with Django. So I've been working with Django for about the last 8 years or so. I'm a Django core developer these days.

Previously, I've been working on stuff like

Django's database,

migration back ends. And now I've turned to

adding in much more native support for WebSockets to Django and stuff like

that. I've had a long history with

HTTP stuff in Python in general.

Most of my work with it has been web based. And I've used to do quite a lot of WebSocket stuff back when it's still being developed by Google. But it's now developed into sort of more full on

getting it into Django, making it work properly kind of angle.

So how did you get introduced to Python? Let's start with Andrew this time.

So my introduction to Python,

I think it was

around,

I'd say, 9 years ago at this point. Past past past past past past past past past past past past past past past past past past past past past past past past past past past past past past past past past past past past past past, early later than that, actually. And so at the time, I was doing PHP, like many people were at that point.

And I stumbled across TurboGears,

which at that time was, I'd say,

probably

the leading, if not 1 of the leading web frameworks

around. Yeah. It's just sort

of amalgam of different bits of Python glued together with some code. But it it it was similar. You know, it had templating. It had an RM,

DRMs

SQL object, which is very similar to Django's RM these days. And I

shifted from PHP to Python,

doing turbo gears over a year or so.

And then I think it was 2000 summer 2006,

I,

went to work with Simon Willison. He's 1 of the, cofounders of Django, as it were.

And

a very enthusiastic

if you know Simon, that's very much how he is. 6 or 7 weeks later,

I was very much involved with doing Django stuff. I had taken my turbo gear. So that's all my path into this kind of stuff. And then

I accidentally became a core developer over the following years by developing stuff for Django that seemed important enough. People said, like, Andrew, you should probably

yes. And so in the end, I sort of just got ended up in this,

position where I'm writing lots of core Django features. But it was a very sort of gentle road, and HP was definitely my sort of first language on the web as it were.

So I have a slightly less long and storied history than Andrew does, but, I did also come to Python from a different language, and I came to Python, perplexingly from Mathematica.

So I picked up Python in

university where I'd started doing computational physics,

as part of my undergraduate degree, which involves lots of writing Mathematica.

And there's lots of great things you can do with Mathematica, but they're almost all maths.

And,

I wanted to do some programming in my spare time because programming was much, much more fun than actually studying.

And

I,

I needed to pick something up, and I wanted to to work with web APIs.

And there were only so many things that were installed on my Mac at the time,

and Python happened to be 1 of them. So like any good university student, I was using

the system Python on OS 10, which I would not let my past self do if I had to talk to myself now. And I started grabbing playing around with web APIs, which of course led me directly and immediately to requests.

From there I started proposing patches

to requests for little things just to get involved and to get my hand in. And that kind of snowballed, and now I find myself here now

without really knowing how I got here.

Haven't we all gotten to that point? How did I actually get here? Yeah. It's it's confusing.

Yes.

I was gonna say that I think the route, you know, the the mathematic or the Python route is gonna become less and less perplexing these days with all of the excellent numerical and data science,

tools that Python has. Right? I mean, like, I'm sure that though back then that was kind of an unusual thing,

I'm guessing it'll become more and more common.

Oh, yeah. I'm like, without question. So so in university, I bought myself a student mathematical license, because I needed to to work away from the computer lab because the computer lab was a hateful place.

And,

I now with IPython Notebook and

Matplotlib

and all of NumPy and SciPy, I don't think I would have bothered. I think I would have been perfectly happy with IPython.

So first off, what is WSGI? And some people may have heard it pronounced wiz gi.

Yeah. I pronounce it wiz gi.

Yeah. Me too.

I I'll do a I'll do a bit of high level summary, and Andrew can just leap in if he thinks I'm,

misleading everybody.

But but WSGI

is,

probably the,

least well known, most important

Python

standard interface that's that's floating around. WSGI is the web server gateway interface, the Python web server gateway interface, and its basic purpose is to have a

a standardized framework for a web server to talk to a Python web application.

So the context for this was, was originally standardized,

proposed in 2003

by PJ Eby. And

this was in an environment where we had lots of, lots of different web framework, like turbo gears that Andrew was talking about,

that could all,

that all basically had ad hoc methods being called by web servers. Like, some of them would include web servers themselves, like Twisted, which had twisted. Web, Twisted's web servers internal,

some of them had kind of ad hoc frameworks for a say to Apache to call into them using something like mod Python.

And what that meant was your choice of web server was often quite heavily dictated by your choice of web application framework. So if you wanted to write turbo gears, then you couldn't necessarily just pick up any HTTP server you wanted. You probably had a limited range of options.

The goal of WSGI was to take, a bit the idea of of CGI, the common gateway interface, and to apply it specifically to Python. So to say, alright, well, if you're writing a Python web application,

here is how servers promise to call you,

to to get you to render the data back. And

on the other side, saying to servers,

here if you promise to call web applications like this, then all web applications will work with you just as well as they'll work with anything else.

And that was a pretty good idea. Got specced as

PEP 333,

which is a pretty easy number to remember.

And because it was very, very simple

and very, very powerful,

it became enormously successful.

So WSGI is is a big enough deal

that for people in the know, it gets mentioned on, things like the Accidental Tech podcast from time to time. It inspired a whole lot of other languages to copy it. So Perl's got a version, it's got PSGI,

the Perl server gateway interface.

RAC for Ruby is heavily inspired by WSGI and,

like it mentions WSGI and its

documentation, for example.

So

WSGI was arguably a barnstorming success

and has been very, very

reliable

and

useful. So it's still sitting here 13 years after being originally specified

and and going just fine.

And I'd like to start to step in and say, like, give people a quick outline of what WSGI looks like as a spec. Because, like, you mentioned it was very simple, but, like, it is astonishing simple. Like, WSGI just says an application should be a callable that takes 2 arguments and returns

a generator or a string. Like, it's a incredibly simple interface that is almost beautiful in in how it's managed to

stay with the times. Right? Like, you know, this is a 13 year old thing, yet

the basic idea of a callable object

being the

entire way that you interact with something is is stay very true. And I'm you know, personally, I find that very nice about whiskey.

Yeah. That's absolutely true. I mean, whiskey is it sits in a in a very interesting place in in the Python ecosystem as as something that is kind of You've heard you've presumably heard the saying about, programming languages, which is that there's only 2 kinds of programming languages, which is ones people hate and ones no 1 uses.

Yes. Like, whisky is in exactly that space. Like, lots of people don't have very many nice things to say about whisky, but they have these not nice things say about whisky because they use it and have used it for a long time and are kind of comfortable with the warts that it has. And,

it's it's really really important to remember that whisky is

astonishingly good at what it does.

And if you compare, like, you know, 1 of its contemporaries, like, DBAPI 2, which is the Python standard for database drivers. Like, it's a massively more complex API,

and, like, there's some much more variation it hasn't invented. So, like,

comparing to other things even inside Python, like, it's, I think, done very well at being this sort of nice simple thing.

Yeah. Agreed.

As you mentioned, it's been around for a long time and has managed to adapt pretty well to changes

in programming and in our uses of HTTP over that same time frame.

So since this is a conversation about your proposal for a new revision of the WSGI specification, can you elucidate some of why

that is necessary given the flexibility that it has

shown up to this point?

I mean, yeah. I I think so. I I think 1 thing that's really important to to clarify here as well is,

1 of the questions that's on the table, 1 of the things that we are discussing is

not just, you know, how how should we revise whiskey, but do we need to revise whiskey? Like,

1 of the kind of core questions,

that I really would wanna get away is, like, is do we do we wanna actually say that for what whiskey does right now, is that perfect?

Like, do we wanna not,

revise or, you know, update Whiskey, but instead,

extend Whiskey?

Leave what what it does is right now exactly as it is,

and add new features either in parallel specifications or as whiskey extensions, optional whiskey extensions.

But there are there have been some there has been some strain put on whiskey, I think, is the way to to think about it, as as time has moved on.

And it's

not necessarily

capable of expressing everything a modern web application developer might wanna express.

Yeah. I mean, it's 13 years old. You know? Like, the web has changed in the intervening decade and a bit. And It's changed a great deal. Yeah. I think it's not surprising that, you know, you know, my astonishment that it's done so well is is that. Like,

it's it's from a place where, you know, images were an optional thing, and and that's come all the way through to a place where the web looks very, very different. So I think that's 1 of the sort of things that led into this discussion. Like, you know, a, do we need to change it? And, b, how should we if we need to? Yeah. So for some timelining stuff here,

HTTP 1 dot 1, r f so standardized in RFC 2616

was standardized in

1999.

WSGI was standardized in 2003,

4 years later.

HTTP

was then,

that so RFC 2616 was updated in 2013,

to

to to basically bring it into line with what was actually happening. The web had evolved so much beyond it that the IETF felt there was a need to rewrite those specs. And then also HTTP was updated again much more recently with HTTP 2.

And Whiskey has been left entirely unchanged. So Whiskey looks exactly as it did, back when we first, spec'd.

Modulo 1 small change in 2010.

Yeah. I mean, you know, talking about the web has changed a lot in 13 years. I I would say it has changed by orders of magnitude. You have only to go to the way back machine and pick any site from 13 years ago. And like you said, you'll you'll see it is it is a dramatically different experience.

Yeah. Absolutely. Web pages are much, much larger than they were. They're much more complicated than they were. There's all this stuff now for the real time web and trying to develop things that are as fast as possible and as up to date as possible and as interactive as possible. And there is a legitimate question about whether or not WSGI

fits really well into that kind of paradigm.

And not to mention that HTTP has kind of become the de facto

language or not language, de facto protocol for talking between different things. Like, it's not just websites now. You've got all the different, you know,

like machines and utilities and consumer devices all talking HTTP to back end servers. Like, it's almost this common way of just having apps and devices talk to back ends

now. So dovetailing into that discussion, what are some of the ways the current WSGI spec has fallen out of step with the needs of modern developers?

So I think the I mean, the primary answer for me here at least

and kind of the reason I'm here is is WebSockets.

So

WebSockets are perhaps the most significant change to the flow of the web that's happened in in those intervening 13 years.

Even HTTP 2 is still

mostly request response. You know, you send a request, you get a response. Whereas web sockets, it's just like it's a socket in some sense. You open a socket, and things can just flow either way.

And that really doesn't mesh terribly well with WSGI's callable nature. You know, this idea that

you can send multiple things, but things can be received during that time, and there's no necessary sort of ordering or structure

to that. And to me, that's the the major way to open that step. There there are obviously other things as well. I think, Corey, you put in some other than I do.

So I can certainly leap in. And and I'll just follow on directly from Andrew for a second, which is that, 1 of the reasons it's quite good to have both me and Andrew here is that where Andrew cares a great deal about WebSockets, I care a great deal about HTTP 2.

And Andrew is right that the basic model of HTTP 2 does fit into whiskey. So the request response totally still works. But HTTP 2 is a massively more featureful protocol than HTTP 1 it was. There is much more you can do and a much more

there's much more control you can have over the way the requests and responses flow and the way the connection looks, And WSGI doesn't expose any of that option. So, essentially,

from a Python developer's perspective, the only thing HTTP 2 does is make your server moderately more efficient. But it doesn't give you any more hooks if you're behind WSGI.

The other big, big concern

that a lot of people have had with WSGI is the way that WSGI limits some of what you can do in Python.

So, Andrew mentioned that WSGI is defined as a Python calling convention. So you call a callable, you get passed some Python objects, and you return a generator or a a a string.

The problem with this is that this means that in most cases,

the server and the Python application are running in process together,

And this limits some of what you can do with the concurrency model. So for example, if you wanted to write yourself a nice modern Python 3.5 application

using asyncio,

so you've got a nice asynchronous, you know, bit of logic and you don't wait on the database and all this other stuff,

the server really kind of needs to play ball with that. The server needs to go, alright. That's totally fine.

We're gonna, we're gonna do this appropriately. And it's quite tricky for a server to do that. And as far as I'm aware, no server does.

There's some question marks. You can maybe do gunicorn with gevent and some other fun stuff. But generally speaking, particularly asyncio,

is not well supported by web servers at all.

And this means that, generally speaking, if you wanted to write asynchronous web applications, if you wanted to write something that uses

asyncio or Twisted or Tornado, you kind of have to throw away whiskey

because this doesn't really work. And that means you also kind of have to throw away your web frameworks.

So asynchronous web applications

for Python basically have lost the big game that Wixky gave, which was that you didn't have to care what your server was. You do have to care what your server is. Your server is probably going to be, twisted dot web, if you use twisted. Tornado's built in web server, if you use tornado, or aiohttp,

if you use asyncio.

It's not like a sorry. Go on. I'll tell you, we're already seeing quite a lot of this as well, like, with with Django. So, like, obviously,

the biggest pressure here is is something like WebSockets, where you can handle WebSockets in Wixi thread. You can just get the raw socket object and upgrade it. But because there's no concurrency, that limits you to 1 socket per

process or thread, which is an incredibly inefficient way of serving this stuff when most of their time is spent open in an idle state. And so we're seeing more and more people adding things like, as you said, tornado front ends or twisted, or even things like, Go or something like that, like a separate language that is more capable of handling these asynchronous

kind of communications in

front of a more traditional WSGI server or website stack.

And I think that's, you know, not a great split to have if you're trying to keep 1 code base.

Yeah. Go's a beautiful example of this actually because this is

you'll see people at PyCon stand up and say, well, how do we fight the the hemorrhaging of people to go? And this is 1 of the things that causes people to leave to go is that they can

use the built in the the Go web frameworks that are being developed, and they're pretty young compared to something like Django, but they do exist. They can use them with WebSockets, with HTTPtwo

built in standard,

and it's all all joyous.

Now there's some efforts to, like, fight this problem. So, for example,

Twisted is the example I know best because I know Twisted best.

There is a version of there's a Django alike, I think is the best way to call it, that exists that runs on Twisted. It's called Hendrix and there's a Flask alike that exists on Twisted. It's called Cline. They've all got, you know, clever punny names.

But the core problem is they're not Django, they're not Flask, and you can't program like they are. You can't take your Django application and start chucking in, you know, WebSockets and Twisted Deferreds and expect that to work.

And of course the other problem the problem then is there's no WSGI equivalent for websockets, there's no WSGI equivalent for HTTPtwo's special function, so a server, even if it wanted to, has to define its own, essentially proprietary extension,

which things like uWSGI have done. UWSGI web server has done this for WebSockets, I think. But its extension is proprietary and it's built to work best with uWSGI,

which means that it may not port so well into something like modwsgi,

which has got some exciting calling conventions,

or into,

Nginx with its ModWSGI, etcetera, etcetera.

Those those are are real problems.

And I just wanted to sort of jump in real quick here and say, also, you know, talking about the other things like Klein and, Hendrix and the like,

I'm sure from a developer perspective, if you're going to have to port your entire code base to a different paradigm anyway,

there must be some temptation there to say, okay, well, maybe we need to take a step back and say,

is Python the right platform for us to be doing this job in? And like you said, at that point, things like Go or or Scala or any number of other languages, you know, can start to look a little more attractive because they're sort of mainstream

has excellent, you know, concurrency support sort of baked into, you know, to their DNA.

Yeah. That's absolutely true.

Yeah. I I think that's definitely true. Like, 1 of the things we see is, you know, Django as a framework sees is this sort of, like, you know, we're not limited by Python necessarily, but there are people always want more things, and some of those things are fundamental features of Python. And certainly, even at November, we've taken

a couple of projects and tried them in Go, you know, things that were just very heavily asynchronous. And and, you know, we're we're still on Python 2.7 there as well, which is a different matter entirely.

And I think

there there are there are some nice things at other languages, but also,

there's a lot less

sort of library support and maturity in the frameworks at this point. So I think it's not so much a problem as stemming the flow. It's just like,

you know, improving the experience of people who are already here. Right? We we can make people's lives a lot easier, stop having much fragmentation

of different

kinds

of components in different languages, and hopefully have a bit more sanity. But people's there's still a good reason to use other languages. I'm not saying there's not, but I'd like to see people choose them purely on merit rather than being pushed away.

Yeah. So I I'm I'm definitely in agreement with Andrew there. And so, again, like, I have written and will continue to write some web services in Go because sometimes writing in Go is just they're gonna be the fastest way to solve the problem. But but but I think I wanna draw attention to to something that was said earlier, which was that,

that Go has this kind of concurrency

baked into the language.

And

I think 1 thing that's

that that I see a lot that I think is a little bit unfair is,

is that people will often be talk about how Go's got these fantastic currency

patterns, and it's got a HTTP server built in and, and all this stuff. And I've there's always been a little part of me that wants to go, well, Twisted has these things. Like, we do have this in Python.

But, of course, 1 of the problems and 1 of the reasons that something like Whiskey is really important is that for a lot of Python programmers, Twisted does not feel like Python.

Its coding style is different, and it calls things all different names than they're used to things being called. And and that's a real problem. I'm not trying to minimize that problem. I think it's real. And that's part of what WSGI helps is well, actually, with the existence of WSGI, you can run Twister as a web server. If you want a pure Python stack, you could run Twister as a web server and run your Python.

Twisted will call into it, and it will all be Python and it will all be twisted y.

But,

generally speaking, that's not very popular.

I get the sense that Twisted has kind of a

a reputation for being kind of a steep learning curve,

which is unfortunate because, obviously,

it's really great at what it does, and there are a lot of people using it to great effect

in production. And even in my company, there's a ton of twisted in production. So it would be an interesting social engineering

experiment to see if we could tackle that and get people to feel more comfortable

working with it.

Yeah. With with Twisted, I've got a

I don't wanna I don't wanna turn this into a How Great is Twisted podcast. But,

I I have a personal belief, which is based on my experience with Twisted, which is that I reckon most Python programmers have cover this kind of trajectory where they first come into Python and everything's wonderful. Then they start wanting asynchronous stuff and someone says, Oh, you should look at Twisted. And they look at Twisted and it's all terrifying

because nothing is the same and all the it's camel case all over the place where they're not expecting it

And they can't find any documentation or the documentation is out of date. And they see all this terrifying other stuff and their libraries don't work, and they go away from it, and they come up with this idea that Trusted's terrible or it's, you know, too old or any of these problems. And I reckon that once you get past a certain point of having used Python long enough, you you kind of find your way back to Twisted eventually, and you look at it through fresh eyes, through the eyes of an experienced programmer who's comfortable with different coding styles

and different terminology. And you suddenly go, oh, hang on. This is this project that's 14 years old, older than whiskey, I should clarify here. Twisted is older than whiskey and has survived

all kinds of different trends and is still here to talk about it and

perhaps has some ideas that are worth paying attention to.

Yeah. I think this plays into sort of the larger story of the stuff is that, like, I think twisted twisted is the end of the path of socket programming. Right? It's this like, if you want to do all the horrible things like, you know, I used to write, like,

Minecraft binary servers in Twisted. Like, it it has all the things for that stuff. Right? But

it's the end of that path. And if you go there straight after you go into Python, you you haven't gone down a path enough to really appreciate it. And it's kinda the truth with with, like, Django as well. Like, 1 of the things I think I think makes Django so good is this sort of gradual revealing of what's behind each layer of curtains. Like, you you go in upfront. You do some simple views, and then we pull the curtain back, and it's more behind it. I think whiskey is kinda nice like that too. Like, you know, whiskey is this upfront apparently simple thing, and then you pull the curtain back, and you can see exactly how it's implemented and, like and then you sort you sort of learn its intricacies and its problems. But I think that

ideal of this sort

of initially simple and its levels of understanding is is a good thing to aim for in any kind of spec.

So bringing this back to to the topic a little bit, how did you guys come to be involved with the new WSGI specification?

What brought you into the process?

Let's start with, Corey this time.

Okay.

I I guess the the simplest thing is I I brought myself into it. It. I reintroduced this idea in the the start of January, and, I say reintroduced because

reintroduce is absolutely the word. This is not the first time we have,

the Python community has looked at whiskey and said, okay, well, what can we do to bring this forward?

But I got here because I've been working on HTTPtwo.

So I worked I've been working on HTTPtwo for 2 years now, partly IETF.

And this included writing some Python implementation. So I wrote a Python client implementation, and then I wrote a much better general Python implementation of HTTP 2.

And this led me to start talking to Robert Collins.

So Robert Collins also works at HP,

and

he does a lot of different things. He works in the same team as me. He works upstream. But he was interested in WSGI, specifically in the future of WSGI

and how that would fit in with HTTP 2 and WebSockets. So we started talking, and I agreed to collaborate with him on some of this in the web sick, the Web Special Interest Group in 2015.

And we got some way forward. So,

Rob corralled some people and we started talking about it. And he proposed kind of an initial,

thin draft of a PEP, but he had some personal commitments, which meant that he no longer had time to pursue this. In that intervening time, I got hired at HP,

to work on open source software full time,

And this means that I now have the time to,

to lead this conversation, whereby lead, I mostly mean,

corral

and,

keep everyone try and keep people on topic and try and kind of get consensus, which is actually quite a lot of work.

And I agreed that I would restart that this year. So this year I, started this year, I sent out an email that basically said, alright. We're gonna try this again

and, tried to kind

of shape,

the way that conversation was gonna go. Yeah. My my part in was a little bit different. So the story behind,

my side is that, basically, I've been wanting to put native WebSocket support into Django for quite a long time now, a couple of years. And this year, Mozilla opened up their, Mozilla Open Source Support Program, which is a program to fund

sort of well known open source projects to implement new features. And so we applied for a grant for them, for a thing called Django Channels, which is our initiative to basically bring WebSockets and background tasks and other things into Django itself.

And

we got that grant, and so I started work on that. And part of that work is a very separate specification inside Django,

which is currently code named in a slightly

optimistic way ASGI.

But that is a much more high level spec around

how

different processes or threads communicate

basically

about HTTP or background tasks or WebSockets or things like that. So it's sort of this

higher level encapsulation of stuff,

designed for use inside Django so that people are writing 3rd party Django back ends, for example,

can understand how to write 1 of those.

And as part of that, it's, you know, it it sort of

touches in some things of where WSGI is as well. You know, it it defines a way of encoding and responding to HTTP requests among other things.

But it's also meant to sit on top of WSGI. And so

I was working on this and sort of making it plantations and that kind of stuff.

And then the,

whiskey 2 compilation start up again in earnest, And I woke up to about

5 or 6 different Twitter mentions and 3 emails in my inbox

and was then hurriedly dragged into the conversation about Whiskey 2. You know, as,

you know, both the representative of Django in our general interest in web stuff as well as somebody who wants to see this WebSocket stuff go ahead as well.

Yeah. And I know it should be clear here that the fact that Andrew ended up in this is not an accident,

and there had been plans to involve,

Andrew

in his specific role as someone working on channels

in this discussion.

Yes. But there was also

a very concerted effort to get people

from,

communities that already use whiskey.

Because the worst possible thing we could have done is talk about how to develop a new whiskey specification without involving anyone who actually uses it on a day to day basis. And that would have been very very bad.

So,

there was a big outreach effort to try and ping people who who were

skilled or relevant in this conversation to try and get them involved.

Do you think that the WSGI name itself brings a lot of expectation, or do you think it'll be good to keep it as a well recognized Python landmark?

The whiskey name brings a load of expectation.

Whiskey, like, as both Andrew and I have said,

very positively, Wizy is is a very, very good thing and it's extremely successful. I can't think of many Python,

either projects or

specifications

that are as successful as WSGI is.

And from where I'm sitting, it seems like in the wake of the kind of initial call for comments,

the consensus seems to be that,

Whiskey is a good name

and should remain the name of the thing we already call whiskey.

So

any new work should try to avoid co opting the name of whiskey

because it it should,

exist on its own as a a completed piece of work,

judged in its own right without

being contaminated by the later work that we do?

Yeah. I think,

you know, WSGI

1 of the biggest expectations

is really, like, the issue of backwards compatibility and things like that. And

WSGI has grown a few

annoying problems over the years.

1 of the main ones being that it the way it encodes data is different on Python 2 and Python 3 for historical reasons. So I think, you know, sort of taking all of that stuff and wrapping up and

making something that still presents as whiskey and having people accept that is a very difficult prospect.

And in many ways, I think that

having it be called something else would be an easy way around that. You know, it's 1 of the reasons my attempt at this inside Jango was nowhere near related to whiskey.

I just know trying to go near that territory is gonna,

I think, end

in problems where, like, you can't promise somebody a new whiskey and then have it not look exactly like it, I do

think. And do you think it would be better to make a clean break and implement an entirely new set of APIs and style of interaction, or is the intent to try and maintain some backwards compatibility to provide an easier upgrade path for the existing web

frameworks? Compatibility to provide an easier

upgrade

path for the existing web frameworks? That's a tough 1. I think well, I mean, there's no there's no consensus yet. Right? And we all have our own opinions.

If you read through the the list where this is a bit all being discussed,

everyone has this, like some people want extensions, the existing 1 that can be declared.

Some people want a whole new thing. Some people want basically have it entirely divorced and not have it like a movie at all. And so, you know, I can I can speak to my personal opinion? And my personal opinion, you know, I think is

a fresh start is needed,

which is what I'm working on. But I'm not sure if that is even a feasible way of doing things in terms of the magnitude of work. So, you know, I'm I'm still personally

unsure at this point what needs to be done.

Yeah. I can definitely imagine that if you were to

do a complete clean break, that

we would potentially end up in a similar situation of the Python 2 and 3 schism where you have a huge body of

web frameworks that are already tied to the WSGI specification, and

there's a very nonzero amount of work necessary to be able to

bring them to the point of being able to implement the new specification. And then there would also be a need, potentially, for,

specification. And then there would also be a need,

potentially, for

maintaining compatibility

with both specifications simultaneously

depending on the use cases of the people who are implementing their applications and also depending on how the new specification

plays out in terms of how it interacts with the HTTP 1 dot 1 specification?

Yeah. I I think, like, any

if there was ever a brand new spec, it would have to have

interoperability both directions as client and server with WSGI. I think that's that's basically the only way you'd stop any fragmentation. And this thing, you know, that I think everyone agrees in retrospect piping 3 should have done is a more gentle upgrade path. I think,

any if there is a wholesale replacement, should have, you know, a way to plug in whiskey clients and servers into it, just at least in the interim. So I think, you know, it it whatever we end up with will be a super se. It won't be more restrictive than what we have now. Yeah. I I think Andrew's,

Andrew's got that there. And it seems to be a consensus of the working group as well is that,

it might be best rather than

creating a new version of WSGI that you have to opt into that includes all this other stuff is to keep WSGI as it is, as a a functional already existing thing, and to supplement it with

new functionality and new APIs,

rather than

try to to kind of create this brand new thing out of whole cloth and hope people,

people take it.

And how has the response been to your call for comments, and what are some of the most frequently raised concerns or suggestions?

The sponsor's been great.

The sponsor's actually been outstanding. I I was delighted with how well this went. We received feedback,

on the list already from,

I would say, something nearing 10 people, and I I received some off list feedback as well from, 5 or 10 others. And that included quite a lot wide range of opinions. So I think 1 of the the most interesting things was that their,

the mailing list

contained a very small cluster of commonly requested things and then a very, very long tail

of,

of other ideas that people were interested in.

So from from where I was sitting, the things that I the most frequent concerns were really about this 1 of scope of,

like, do we wanna coop the name of whiskey? Do we wanna

extend whiskey? Does whiskey need extending?

To what extent

should we

try and build a brand new thing versus trying to build new things that supplement whiskey instead of co opting it?

Although, the other thing that

that was very common was what Andrew mentioned about, WSGI behaving differently on Python 3, and in particular,

its slightly perplexing choice that it encodes,

HTTP headers as Unicode strings using Latin 1. There was a remarkable amount of negative feedback about that design choice.

Yeah.

Understandably so, I imagine.

Yeah. Well, I mean, I I I found that mildly surprising, because actually from where I was sat, that seemed

like maybe the best of a bad set of options.

But, it certainly seems like the consensus now is that while that might have been true at the time, it's definitely not true now.

What are some of the proposed changes to the specification

or supplements to the existing specification?

Again, I'd say there were quite a few.

Some of them were proposals that had hung over from previous,

discussions and some were new. But the the proposals really ran the gamut. So there were lots of big proposals, like, let's change the calling convention to 1 that's built on top of asyncio and coroutines.

So wholesale change to WSGI. And there were some smaller ones, let's add

supports for WebSockets into WSGI, so that a WSGI HTTP request can go into WSGI and get upgraded or automatically turn into WebSockets using some magic API source that we hadn't decided on yet, or

make it possible to extract the socket object that the server has from WSGI. So if the application decides that it doesn't want the server involved anymore, it can just grab the socket and say, alright, I own the protocol now. Just be a dumb data pipe for me, please.

Or completely

1 of the other ones was completely rewriting whiskey. So say, alright. Well, let's adopt something more like ASGI, for example,

and abandon WSGI as the kind of legacy approach.

And then there were some smaller ones, like, much more tightly scoped. Here are some specific concrete problems with WSGI that we should address,

Some problems around, the WSGI file wrapper,

which is something that I suspect not many people use,

in part because it's got some

ambiguity in it and some nasty little edge cases,

and,

pet handling, again,

which came up as something that was not enormously popular and people would like addressed.

So are there any future directions that you think WSGI should take that perhaps haven't been considered yet?

I wanna hear from Andrew on this because I think we covered everything.

Yeah. I I think we we've definitely had pretty much every possible suggestion on the sun so far.

I think I'm certainly playing for the more extreme end of the of the range here, which is basically

subsume it with a brand new spec.

But, again, like, my interest is much more,

like, internal to Django. Like, whatever as he ends up being, it will be possible to plug it into WSGI or whatever its accessories ends up being. So it's much more

like a internal Django where it's saying, this is how Django encodes requests. You know, some of the way we have a Django request class. I do think we've covered pretty much every possibility.

You know? Like, the range of voices on this topic has been very wide.

And 1 of the issues is that. Right? Like, some people want just incremental fixes, like how chunked encoding works.

Other people want to basically throw the whole thing on the bus and start from scratch.

There's probably a happy middle ground in the middle of that. But,

yeah, there there are a lot of options here, and

I can't think of

anything more crazy than 1 of the ideas that's been brought up yet.

Yeah.

And that's gonna be 1 of the fun things about this whole process is the desire is to ensure that everybody gets

something that's close to what they want. And that means that whatever we build needs to work with with Django's channels because Django is important, and we don't want Django to, to walk away from the Python community and design its own things and start co opting Twisted, for example.

And

we wanna make sure that the people who want WSGI to just be a slightly better version of what it is, they get what they want. And that the people who think they need WebSockets directly, they get that what they want. And there there probably is a design goal that will work for this, and I think we're kind of beginning to come towards consensus on what that would look like. But that's the the thing that's really exciting is trying to make sure we can build something that fits all of those criteria.

And has your opinion or vision of the proposed update changed as you reviewed responses to the conversation on the mailing list? I think mine definitely has. Like, you know, I I I came into this with a very greenfield approach, and

I I always knew, you know, internally that

there's no way 1 could simply go from scratch. I mean, that's and, like, a lot of the responses

about

places where Zigg falls down, I think, prove, like, the difficulty in

getting something this mature. Right? Like so I think my my my view has changed much more towards

more iteration and building on the past because

there's a lot of learning in those years of whiskey, and there's a lot of code built around it. And

I think I mean, I I'm experienced enough developer at this point to know that trying to build something from scratch is always a bad idea,

but particularly in this case where HTTP

still has its little tricky issues,

that you've gotta work around and

how, like, all but 1 header can be combined, but 1 header can't be combined. Shit. So it's particularly nasty.

Yeah. I'm with Andrew on this 1. I definitely

opened I began it in my original email. You can go and look at it. Had all these grand, you know, oh, let what could we do? Think about,

all the kind of wacky things we could do, all kind of architectural craziness.

And I got brought back to Earth very, very quickly,

by by people who

very, very effectively argued that whiskey, as it stands, is a valuable thing and

can be improved without being abandoned,

and that's that's a a path really worth considering. And and that argument more or less entirely won me over,

So I I'm now kind of prepared to go with the argument that says, let's try and keep as many of the the lessons that were learned in WSGI as possible

and and build

new things that don't ruin what we already have. And

that's the advantage of having to consult with a lot of, lot of experts in the field. There are people involved in this maintenance discussion who've been working with Whiskey for 12 years.

And 12 years ago, I was 13. So I think their feedback is is fairly important.

And do you have any ideas of how to design the new specification in order to avoid a similar situation of needing to deprecate the current standards in order to accommodate new web protocols?

So I think that's basically impossible.

Like, if you make like, making something ultimately flexible makes it ultimately complicated. Right? That's that's the that's the problem. That's the trade off you have there.

And I think, you know, we could

have this wonderful

extensible thing where, like, oh, you can just have anything, and it goes anywhere.

But then you lose a lot of the nice conciseness and simplicity of WSGI. So I think there's a there's a middle ground there as well,

where, like, you know, we know the current protocols that the web needs, which is HTTP 1, HTTP 2, WebSockets,

possibly WebRTC.

There's a couple of things like that as well that's sort of more in the

developmental

stages that aren't quite there yet.

I don't think we should try try and anticipate what people are gonna try out can't move 13 years from now because I think the web will be very different. Like, again, you know, imagine what's happened in the last 13 years and then add that to the web now. Like, will they even recognize what's going on then? You know, will will asynchronous even be a thing? Or will we will we have changed programming paradigm? Who knows?

Yeah. Unsurprisingly, I agree with Andrew.

And I think it's worth clarifying here a couple things. Like, 1 of them is,

I I suspect now as a working group, we're not likely to deprecate whiskey. I think we're likely to say that whiskey, works just fine.

And the the way to think about whiskey is not as something that is deprecated,

but as kind of,

I guess, I would call it an evolutionary dead end.

Like, it works really well on what it works on now, but it won't necessarily evolve to kind of cope with or encompass new protocols.

And that, actually, that limitation

is a good approach for interface design. Like Andrew said, generality,

absolute generality is a problem. And so it often helps to say, well, okay. We we know the limit of this thing.

Let's build to that, and then when we need to replace it, we replace it. There there's nothing wrong with replacing things. There's nothing wrong with saying, okay. This thing was good enough, but it's not good enough anymore, and we need a new thing. Protocols are only as useful for as long as they're useful. And once they're not useful, we need to not get too sentimental about replacing them. And and that's progress, and we we shouldn't necessarily mourn it. But that doesn't mean we should take a flamethrower to what's already there, same as HTTP 1 dot 1 is still perfectly good, and it's not going away anytime soon just because HTTP 2 exists.

It's good at what it's good at, and for most cases for a lot of cases, that doesn't need to be changed.

What we have an opportunity to do here is to

pave the way for this kind of discussion again.

So This is what HTTP

2 did. Like, HTTP 2 was very painful to specify, but having done it, everyone feels a lot better about their ability to specify

hypothetically, an HTTP 3. We kind of know how to do this now. We know what the the rules are and what the difficulties are. And that's the opportunity we've got here, which is that we can pave the way for having to do this again. So we can go, okay. Here's how you kind of come up with this new

Wazigie equivalent for your protocol of choice.

And that's the thing we 1 of the things we really need to be looking at is making sure that these lessons can get, can get learned

and understood for the next time we have to do this.

That's really interesting. So I'm sorry. So so, basically, you're sort of putting effort and and development manpower

into the process and making the process efficient. Like, we know things are going to change. Let's let let's get really good at designing new specifications that adapt

to the new conditions in the field

as opposed to

putting so much effort into creating this all singing, all dancing, super generalized thing, and you end up with something like what, and I hate to say this, the Java community did where you have 6, you know, 100 lines of XML configuration

for hello world or something like that.

Yeah. I I think that's absolutely right. And I think 1 of the lessons that are is slowly being learned,

by by the wider program community is that it is okay to have specialized tools that only do 1 thing or and and do it as best as they can. And it's tempting to kinda look at that and go, well, that's the UX philosophy. But that's not really right. I mean it much more on the level of, like, it is okay to have an application stack that involves 8 different programming languages. So long as they can all communicate with each other and work together, then it's not a problem to use the best tool for the job. And that lesson should be learned,

in terms of interfaces and protocols like this. It is okay to have something that is tightly scoped and works really, really well at the 1 thing it needs to do.

So what are some of the points of contention or rigorous debate that have kept previous WSGI 2 attempts from succeeding?

Well, there's been a lot.

But

but it mostly comes out of how widely deployed WSGI is.

Despite all of its warts and and difficulties. Like we said, it's been really, really successful and really, really widely deployed. And that means a lot of people

have got a lot riding on on whiskey in its current form and the future of whiskey.

There are lots of people who have

either their job relies on whiskey in some form or their reputation relies on whiskey.

I don't wanna call anyone specifically here, but there are a lot of people who the vast, vast majority of what they've done and a lot of their

most notable work has been in the WSGI arena, and they have done excellent work. And they understandably are defensive

about

wanting that to to remain valuable. And I think that they're they're right. Their work is good. I don't want to throw any of that stuff away.

And generally speaking, these haven't led to deadlock. Like, this hasn't been a lot of people going, nothing must change. Everyone wants change. They just don't all agree on what they want. And so we get bogged down in the weeds. Everyone wants their 1 specific thing and fights their corner. And you we've needed,

someone with time and motivation to kind of push for consensus,

and no 1 has it. No 1 has has got that amount of time, really, because you really need to just be paid to do it. You need to have enough money to sit down and spend it as your day job and kind of corral people together.

We haven't had that as an opportunity.

I think HP is providing that opportunity for me now. And for as long as they're prepared to keep paying me, I'm I'm prepared to try and,

try and get some consensus going here.

Yeah. I I I agree with Corey on this 1. I think, like, a lot of it is that there's so many different interests both on the server side and on the application side that

it's almost impossible.

Like, whichever way you want to poke out of the specification in a new direction, somebody's already

locked down that part. Right? Everyone has their own part that they're coded around and they think is important. And so it's very difficult to find a place to extend or change without stepping on somebody's toes. But I think

there is, as Corey says, a way of finding consensus there with with efforts and time and reconciliation and working out who's doing what. And perhaps, you know, people helping other people. Like, you know, Django is a project that won't have to have other projects if what we want slips other projects' toes. Like, you know, we have the funding to help do some stuff like this.

So are there any questions that we didn't ask that you think we should have or anything else that you'd like to bring up?

I think it's a good idea to to ask just, just quickly whether or not you know, some as as the as someone who's responsible for trying to push this through, whether or not I think I can we can satisfy everyone with this work. Like, do do we necessarily feel like there is a 1 correct 1 correct answer that everyone will be happy with?

Because that's the the question that that I feel like everyone combining a protocol or a specification or anything that someone wants to interrupt with has to ask themselves at a certain point. Is is this work worthwhile?

And I guess I'll just lead into answering my own question because why not?

Where where I feel like,

the answer to that is no.

So, I don't think I think whatever this working group produces, whether that is nothing, whether that is a small revision to whiskey and nothing else, whether that is, a brand new thing like, ASGI, whether that is small extensions to whiskey, I can guarantee to you that 10 years from now, there will be a lot of angry blog posts about how terrible our work was,

and a lot of people getting a lot of,

Twitter equivalent likes, whatever Twitter is 10 years from now,

for for kind of tearing that work down.

And

the reality with this is that when you're specifying something that needs to work broadly and generally,

you can't satisfy everyone. And frequently, you can't satisfy anyone.

There are too many people. They want too many different things.

And as far as I can tell, that's not a reason not to do it.

That's a reason to be aware of,

of

the limitations of what you can do.

Whiskey has been super successful,

super valuable,

and having something like Whiskey for new protocols is a really clearly good idea.

But

beyond that, everything is just

is just about how well you can do what you can do, and whether or not you can build something that's useful.

And that's the goal is to build something that people use enough to hate it.

That's success for me.

Anything better than that is just gravy.

Yeah. It's 1 of those things that's like, you know, classic diplomacy negotiation is that a good negotiation is 1 where everyone walks away slightly unhappy. Like, that's fine that you've done it well. That's a good compromise. So I think

what we end up with will be

good and functional. It won't be this pristine piece of design that everyone's proud of, but I think it will serve a good purpose, and that's really what I want to see out of this particular process.

So 1 last thing that I just thought of. Is there anything that you

feel that our listeners could do to help

sort of get this process

moving in a positive direction and and ideally concluded? Because I feel like as a community,

the fact that we haven't agreed on something like this is kind of hurting us. Right? Like and it would be good to

make it happen. What can we all do to help, essentially?

From where I'm sat, there are are 2 really good things.

The first 1 is to be involved in the discussion.

So, this discussion's not happening in private. We're not a little cabal that meets in a

room in some massive mansion and talks about how we're taking over the world. We're, we're the Python,

web special interest group. It's the web sick. So if you Google Python web dash sig,

you can find the mailing list, and you should join the mailing list. And at the very least, you can read and think about how we're all stupid, and maybe you can also write some emails and tell us that we're stupid because that feedback is important,

if delivered appropriately.

And if you don't say anything, then it is hard for us to take account of your opinions,

and views. And they're valid and important, and and that's that is really necessary.

But the other really, really useful thing you can do if you can use the things that are being proposed and talked about here and provide feedback.

Our work is only as good as the feedback we get. So for example,

Django Channels that Andrew's been talking about, it exists right now. You can play with it. It's,

my understanding, Andrew, is it's relatively early.

Yeah. But it does exist. You can download and play it. You can tell Andrew, oh, here's the things that work really well. Here's the things that have rough edges.

And that feedback is

extremely important,

to try and get a feeling for what works. Because it's really easy if you're just working kind of by yourself in a room

to to lose track of what the wider community needs and is doing.

Yeah. I find it very important to not develop a spec in a vacuum. Like, the idea of

developing specification

without any actual code or examples underlying it, I find very difficult to do. And so for that reason, you know, Django Channels and the ASGI spec and things that talk like spec already exist.

And, you know, those help inform how I change it and how people feedback about it. So I think as Corey says, like, not only

stuff I'm doing, but any other stuff that comes out of this, like, use it, feedback, what you like, what you don't like. Like, that's ultimately

making developers' lives easier is what we're trying to do here. So

that kind of feedback is very important. Yeah. Absolutely. And and in particular, I should mention that

we're we're not not we're not I suspect we're not just working on 1 thing here. We're going to want to make small improvements to WSGI and people need to work with those and play with those. We're going to want to make new things, probably,

either small things that work with WebSockets or big things like ASGI

and maybe both. 1 thing we might end up deciding to do is say, look, ASGI is a good architecture and deserves to be more general.

Let's drag it through the web sig and polish it into a PEP and turn that into a Python thing.

And the better the work is on ASGI, the better that, the better that opportunity is.

So,

the the most most valuable thing that people can do if they wanna help here is to try these new things

and and see how they work and come up with an informed opinion about how these things can be done better because

there's nothing worse the only thing worse rather than designing

a spec in a vacuum, like Andrew talked about, is designing a spec in what appears to be a vacuum, but is actually a Twitter hate chamber.

It is much more useful to rather than taking the feedback to Twitter, to take it to the mailing list so we can take some kind of action on it.

Well, we really appreciate the both of you taking some time out of your weekend to speak with us and our audience about this some more. So for anybody who wants to keep in touch and follow either of you, what would be the best way for them to do that? Andrew, how about you first?

So you can find me pretty much everywhere as Andrew Godwin, but in particular Twitter,

where I do a lot of my

slightly inane tweeting, but often about Python as well.

And, also, you can find channels and all my other work on GitHub under Andrew Goldman as well.

And, Corey, how about you?

Unlike Andrew, I like to keep people on their toes. So on Twitter, I am lukasaoz,

l u k a s a o zed. And on GitHub, I'm lukasa, l u k a s a. So if you're interested in my code,

strip the final 2 characters. If you're interested in, hearing me express my opinions very strongly, then keep the final 2 characters there.

Very good.

And with that, we will move on into the picks. And for my first pick today and only pick this week, I'm going to choose the Discourse forum software.

So this was created by Jeff Atwood, who was also behind Stack Overflow, which every programmer should know and love by now. And Discourse

is by far the most advanced and well put together forum software that I have seen of late.

It is written on Ruby on Rails with an Ember front end, but it's

very easily deployed. They've got a Docker container that you can just download and run on your server. That's actually what we're using for our

community forum. So, again, for anybody who wants to join that, it's discourse.python

podcast.com.

And you can try out discourse for yourself and perhaps deploy it for your own purposes.

And, Chris, I'll pass it on to you now.

Thanks, Tobias.

I have a few this week, but 3 of them are gonna be super quick, so I won't will not be taking up too much time. The first is a TV series.

I'm kinda shocked my own self saying this because the sci fi channel since they changed their name to s y f y has been just producing utter dreck in my opinion, but this series is top notch. It's called The Expanse.

The writing is great. It came from a book. I haven't read the book yet. I definitely want to. The production values are very high,

really great special effects. The acting is good. The story is really compelling.

It's it is,

I'm quoting someone else here, some of the best,

science fiction on on mainstream television right now by a by a long margin. So definitely check that out if you're at all inclined.

My next 3 picks are

board games that have been converted to the mobile platform, and Aya specifically in in my case.

I've been getting more into board games lately. I feel like sort of, you know, learning how to strategize will be good for my, you know, overall self and perhaps my tech career. And also, it's just a hell of a lot of fun.

So

the first 1 is Puerto Rico for iOS. It is a really nice adaptation of the board game. The board game has, you know, a fair bit of depth and the iOS port really sort of, you know, shows that that all through.

It's a board game about running your, you know, your own little version of the Puerto Rico

colony in the time of of

the, you know, when when,

when that was new essentially, and managing resources and plantations, and it's just great fun. And there's good tutorials in the iOS versions of all these as well. So if you don't know how to play the board game or even want to know how to play the board game, the iOS version is a great sort of gateway drug to get you going.

Dominion is the next 1. I've already reviewed that on this podcast, picked it. So I won't go into any more detail, but the iOS version of that card game is excellent.

And the last 1 is a card game,

that they've made an iOS version of called Splendor,

which is all about sort of building up a trove of treasure and precious gems,

and attracting the attention of nobles.

All of these are really great sort of, you know, in my opinion, sort of free time slash commute

kinda thing because they're turn based, So it's not like Twitch oriented. So if you're on the subway or something, you can you can play and get a good deal of enjoyment out of it. So that's it for me for picks. Corey, what do you have for us?

So I have 3, and they're all very varied.

But,

I wanted to just go through them real quick.

So the first 1 is,

I'm going really out off off the rails here. I'm gonna talk quickly about knives.

So,

I I like cooking. Cooking is great fun. But, for the longest time, I've been really, really fixated and obsessed on having the best kitchen knife you can have.

I've got various different reasons for this, but the main 1 is that, good kitchen knives make cooking a lot easier and a lot more enjoyable.

And they're also a massive safety tool. Like, having a really sharp knife actually perplexingly makes you less likely to cut yourself, because the knife's less likely to slide all over the place. And,

I have finally found a set of knives that I really love, which are made by, Wusthof, a German knife manufacturer.

So if you cook a lot at all,

you should take a look at at Vostoff knives. Go check them out. They're not enormously expensive, but they are fantastic. And, ideally,

they're the kind of thing that you'll buy once and then will, work for the rest of your life and you'll never need to replace.

Second 1 is sports related. We were talking about sports, pre show, and I was talking about how I think there's a a new renaissance in sports interest for geeks. And for that, I wanna recommend,

all the listeners to this podcast who don't know anything about Australia,

which is probably most of you, that the Australian Football League sports season is starting in March. And Australian football is the most bonkers sport you will ever see.

If you want an idea of what it's like, you should go to YouTube and Google,

AFL or Australian Rules Football,

and you'll see there'll be some kind of 10 minute clips put together. It is utter craziness. It is absolutely fantastic, and you should watch it, because it's just absurdly enjoyable.

And then the final 1, and a much more kind of expected topic for this kind of podcast,

is

video games related, which is that XCOM 2 comes out

at the start of February, February 5th or something, and it's going to be absolutely fantastic. And I have not been I've never been more excited for a video game in my entire life,

So I find myself watching everything I can about it. So,

I couldn't recommend that more.

Andrew?

Yeah. So I just have a couple today.

Mine a bit more general. So first of all, I wanted to,

share with the audience my, particular passion for archery.

So if you've not done archery as a sport, it's this

fantastic thing where it works very well as both like a sort of a solo,

relaxing, do it yourself thing, but also in friendly groups of people.

It's very easy to get into. The equipment isn't that expensive usually for

for a entry bow. And most of these have archery clubs. So,

I've been doing archery now for, like, 3 or 4 years, and I encourage anyone who's listening who's at least interested to go along. Most clubs have a thing where you can just have a go and have have a tryout at it. And it's a sport with a really nice progression. Like, you get

much, much, much better very quickly in your first, say, 4 or 5 months. And if you stick at it, you can get better and better and just keep going. So it's a really nice sort of gentle upslope there.

And my second 1 is,

calling back to where I was 2 years ago today.

I would like to call out the wonderful city of,

in Norway,

which is a rather odd pick because maybe we can't get there. But it's I mean, the Arctic Circle in general this time of year is fantastic. And, if you go up to

or anywhere

inside the Arctic Circle this time of year, you get the most wonderful,

sunsets and sunrises. Like, you know, there's only 2 2 hours of sunlight, but there are 2 hours of sunset and 2 hours of sunrise as well.

And that plus the northern lights, I encourage anyone who's feels that they have the means and the ability to go up north to at least have a go.

Well, again, we definitely appreciate the both of you joining us, and I'm sure that our listeners will get a great deal of enjoyment learning more about the whiskey specification

and some of its proposed advancements.

And they hope you enjoy the rest of your weekends. Thank you. It's been a pleasure. Thanks for having us. Thanks, guys. Bye bye.

The Python Podcast.init

Summary

Brief Introduction

Interview with Cory Benfield and Andrew Godwin

Keep In Touch

Picks

The Python Podcast.__init__