The Python Podcast.__init__

Share on social media:

[00:00:12] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With 200 gigabit private networking, scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new API, you've got everything you need to scale up.   And for your tasks that need fast computation, such as training machine learning models, they just launched dedicated CPU instances.   And they also have a new object storage service to make storing data for your apps even easier.  

Go to python podcast.com/linode,   that's l I n o d e, today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show.   And you listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis.   For even more opportunities to meet, listen, and learn from your peers, you don't want to miss out on this year's conference season.   We have partnered with organizations such as O'Reilly Media, Corinium Global Intelligence, ODSC,   and Data Council.  

Upcoming events include the software architecture conference, the Strata data conference, and PyCon US.   Go to python podcast dotcom/conferences   to learn more about these and other events, and take advantage of our partner discounts to save money when you register today.   Your host as usual is Tobias Macy. And today, I'm interviewing Tom Christie about his work on Django REST framework, Starlet,   async and Python, encode, and all of the other areas that he's been involved with over the past few years. So, Tom, can you start by introducing yourself?  

[00:01:55] Unknown:

Hi. Yeah. Sure.   My name's Tom.   I'm,   currently working on open source software   full time.   I'm running   a small, at the moment, 1 person business called Encode.   I'm working on   all manner of things   Python web related.  

[00:02:15] Unknown:

And do you remember how you first got introduced to Python?  

[00:02:19] Unknown:

Sure. So well, I say sure. I'm not sure that I I completely do because I've been in the game long enough that it's gotten slightly wooly.   At some point along the line,   oh, it went from,   oh, this language,   see, this new thing seems   nice. This looks like a much better way to do the stuff that I'm currently doing with Pearl and   Bash scripts.   I was,   I think it was probably when I was working for a content distribution network. And   all of a sudden,   having been used to working with Perl and and Bash scripts or or with c,   there was suddenly this   this new language just appeared on the scene for me and it was it was just so productive and so nice to work with.  

Yeah. Like that.   But as I say, long enough ago now that   I'm not entirely   sure quite when it was. Yeah. It's definitely  

[00:03:18] Unknown:

interesting to try and catalog back of how did that get started. I I know I started in Python pretty early in my career, but I don't remember exactly how I first came across it. So Right. I don't blame you for not remembering the specifics. What got you into programming in the first place?   So I actually ended up getting my in computer engineering, and so that was my first introduction to actually   writing code. And my first class was in c plus plus. So by the time I got to Java in the next semester, I said, oh my gosh. This is so concise and easy to write. And then as I got introduced to more dynamic languages, like Yeah. Yeah. Well, actually, it was, I first got introduced to Ruby because I was working at a place that did Ruby on Rails, and,   it just never really sunk in and never stuck. And, somehow or other, I ended up with Python, I think, because I was working as a sysadmin and just trying to figure out, like, what what are all these things doing?  

Once I actually figured it out, that was the 1 that really fit my brain and stuck, and that's the 1 I've been working with for the past, I don't know, 10 years or so now. Yeah. Yeah. Yeah. I mean, I when I  

[00:04:20] Unknown:

was first going, it was all lots and lots of back end stuff. I'm working in c and c plus plus and   I I kind of I moved into the web space,   as I progressed because I wanted to get more of that. Yeah. But I wanna be able to build things that I can see   and I wanna be able to, you know, like, actually build services. And when you're working in very, very back end centered stuff, you know, like I did a lot of speech recognition   and then lots of core networking stuff. And you're always part of this much, much bigger company.   And you're always building stuff that feels so far away from the customer that they're moving into Python and the web space   just felt so much more enabling, you know. I can actually build stuff and put it out there and show people. Yeah. Definitely  

[00:05:10] Unknown:

useful to be able to have something that you can point to, particularly if you're talking to somebody of what is it that you do? I say, you can say, I build that.   Because otherwise, it's, oh, I build things that do this other thing that you might use, you know, 3 or 4 steps removed.  

[00:05:26] Unknown:

Yes. Although it's still difficult describing it at the moment because most people, you know, people will say well what is it that you build or what do you do?   Well, I build software for people who build software.   Yeah. Exactly. That's about as close as I can get.  

[00:05:41] Unknown:

And in talking to people in the Python community, there are a few different eras   particularly in the web that people have come in on. So some people will have cut their teeth on Zope. Other people will have come in more in the Django era.   Where were you in that overall journey of Python and the web when you first started getting involved in it? I think Django was pretty much my first  

[00:06:03] Unknown:

web framework that I started working on Python with.   Yeah. And   it it wasn't really that long since I've been working with Django before   I had the idea for,   oh, here's this neat API framework that I'd like to build.   Yeah. I I I got some contracting position for,   a little Django job somewhere first. And   I've just moved to Brighton, and I was just noodling away on that and then   started working on this side project.  

[00:06:39] Unknown:

And so that has become Django REST framework, which is now sort of the de facto standard for people who want to build   well structured REST APIs   in Django. So I'm wondering if you can talk a bit about some of the history there of how it came to be and how it came to be so popular. Yeah. Sure. Well, it's been quite a long time now. So it's been going for more than I think more than 10 years.  

[00:07:04] Unknown:

The original   impetus for the project was   this thought of why is it that   we're building all of these web APIs   but they're not,   you can't interact with them natively in a web browser. Why are these web APIs   not web browsable?   And   I had a few few little thoughts about, well, how would we approach this?   And I looked at a couple of the existing projects in Django. I think it was Piston was   the big 1 that was around at the time way back.   And so, oh, no. I can't quite make it work with this. I'll I'll just start my own thing in order to show how you would do this.   And   I was so keen on the idea of web browsable web APIs   that it was this big motivation to kinda keep improving the project   to try to get the idea out there.  

And   it, yeah, it kind of it carried on and it carried on.   And TastyPie was   really, for a long time, kind of more   feature complete than than REST framework,   but just kept plugging away on it. And then got a little bit lucky with the timing because   at some point, I kinda thought, okay. I can see   how I'd like the next version of this to look.   And   the timing just happened to be right that there was kind of   a big enough need for it in the community.   So that when we ran a a very first Kickstarter   for it,   that ended up being pretty successful. We raised like   £30, 000.  

I was   working with,   a small company called Dev Apps who are really keen on the idea of doing this. So we kind of we organized the kickstarter together   and they said, oh, okay. You know, if you make this much money, you'll be able to allocate that much of your working time   on it.   So even though I was working in a full time job,   we managed to figure out a nice way to make a kickstarter work and be able to free up a bunch of time. And and that really progressed the project massively   from there.   Then a few years later,   I thought, okay. Well, I can see what I'd like to do for the next tranche of work on this. And I was thinking about how am I gonna approach this? Am I gonna do another Kickstarter   or so?  

I didn't really want to do that because   really what I wanted was a revenue model that was ongoing rather than 1 great big lump sum of, right,   here's a chunk of money, go and do a bunch of work.   And again, kinda got lucky with the timing because Mozilla had just released   their big open source grants program, and Mozilla happened to use Django Rest framework.   So I applied to Mozilla   for 1 of these grants   and   at the same time was thinking, okay, well, I'd really like to launch a recurring model.   And when we were successful and the Mozilla grant came in,   that gave me   enough runway   to be able to say, okay.  

I'm gonna give this a shot. Let's launch an ongoing funding   program for it.   So   I stepped away from my job, and I knew that I had   6 to 9 months   of safety cushion   and launched the the recurring sponsorship model with ENCODE. And I've been working   funded   by that for the last   3 years or so, 3 and a half years.  

[00:10:57] Unknown:

From your work on Django REST framework,   I know that that is still an ongoing project and 1 that's still supported. But with the introduction of asynchronous capabilities   in the core Python runtime,   I know that you also decided to revisit   what APIs mean in that landscape,   and that took the form of Starlet. So I'm wondering if you can talk a bit about what the Starlet project is and how your work on Django REST framework influenced your thinking   with this new project and how the 2 sort of play off of each other or relate to each other or not? Yeah. Sure.  

[00:11:34] Unknown:

So   I could see that there were lots of new async   web   frameworks coming up.   And   Andrew Godwin   was also working in this area and   introduced or was just starting to talk about introducing   ASGI.   So you you have WSGI,   which is the interface layer between   the servers such as Gunicorn   and the web frameworks.   And it provides this really nice separation that means   you don't have to really be concerned at all with any of the gnarly stuff   that the the web server has to do when you're in application space.   And   WSGI is designed   to work   with thread concurrency pros stand standard threaded concurrency programs. And when Async came along,   there was this new need for something similar, but in the async space,   that was able to additionally, you know, as well as handling HTTP,   also be able to handle web sockets   and various other stuff like   long running   HTTP   requests that are streaming data back down and, and other stuff,   like   dealing with background tasks more gracefully.  

Yeah. So Andrew Godwin had started working on ASGI in order to bring async some async capabilities   into Django   through Django channels.   And what I wanted to do was build on the work that he was doing with ASGI,   and bring that into the wider   space of Python web frameworks more generally. So rather than ASGI being just centered on, it's this Django initiative,   How do we build up a whole web ecosystem,   a whole Python async web ecosystem   based on ASGI?   And Starla is right. Here's the foundational   set of tooling that we'll need in order to be able to do that.   And   there's a few other projects now where people have then started building higher level web frameworks on top of that, like fast API, which is fantastic.  



[00:13:52] Unknown:

Yeah. The it's definitely interesting how   much of an explosion there is now in new web frameworks that are exploring the async capabilities of Python, where it seemed like for a while, it had sort of stabilized around Django and Pyramid and Flask as being sort of the   main core of the web ecosystem in Python with a few different   special cases here and there. But now that async is rolled out and particularly with the new ASCII specification   as a standardization   that people can orient themselves around. There's a lot more activity happening,   and new frameworks seem like they're coming out maybe every few weeks. So it's definitely interesting to   revisit the web space in this new landscape of asynchronous capabilities and how that plays into the performance characteristics and the language choices that people are making. Because for a little while, there was a bit of an exodus to things like Go or Node because of the native async capabilities. And now that that's built back into Python, people are starting to maybe come back into the the fold and rethink about   what it means to write a web application in Python.  



[00:15:02] Unknown:

Yeah. I I don't really know how much that message has gotten out, but I think it's,   you know, it's been the landscape,   the async   web landscape in Python has been coming along really, really quickly.   And   it you know, for me, 1 of the big things that I try to promote with it is that it's all about trying to hit   a sweet spot between   for for Python   for both productivity   and performance.   As well as, you know, I'm I'm starting to look at, well, what cool stuff can we build that's   making use of web sockets and how can we make better use of   neat   real time,   stuff that we can plug into our web applications as well, which is gonna be really interesting too.  



[00:15:52] Unknown:

And digging more into   the funding and sustainability   model of the work that you're doing on Starlet and work within the ASGI ecosystem.   You mentioned before that you had a couple of experiences   of things like Kickstarter or this grant application for getting lump sums to support your development as well as doing freelance work. I'm wondering what your current thinking is on the overall sustainability of open source   as a business model and as an individual contributor,   and what your current hopes and goals are with the encode organization   as a umbrella for,   with doing all of this work? A bit hard to say  

[00:16:34] Unknown:

wider. I can talk about my experience,   You know, at the moment, Encode   just about   manages.   So   we have   a pretty simple model and there's 3 different tiers that companies can sign up to.   And   the the monthly recurring revenue that we get from that is just about enough   to cover a salary for myself.   I think I you know, ideally,   I would like Encode to   find a way to bring in another another revenue stream as well on top of the sponsorships.   I've got some thoughts about   something that we could bring into the product space there, perhaps,   that built that   is still an open source product. But so for example, in the way   that Sentry   managed   to   both remain an open source product   and yet massively succeed as a company. I think those are the the obvious kind of   if you can do the same sort of thing that they've done,   that   that's where I love for obviously, I'm not expecting anything on that magnitude for in goats.  

But I would like to follow their kind of model   sometime. Or, you know, the other thing would be just keeping to   press for   what   a solid return on investment the sponsorships   offer and try to get the community as a whole   pushing   for more of these kinds of models,   but with   larger amounts involved. Because the pitch that I generally make if I'm on the stage and there's a whole bunch of people out there is,   I wanna work for your company   full time   for   a $100 a month or a $150   per month. And I'll be working full time on building out   all of the stuff that you're using day after day after day.  

The, you know, the stuff that's been built   out as a result   of Enco being sponsored,   You know, over the last 3 years,   there's been Starlet   being   an ASCII web framework. There's Yupikorn being   a web server.   There's   a whole stack of work on Django REST framework.   There's been HTTPX,   so a new a new HTTP clients   that, you know, so much stuff has come out as a result of the funding. And yet, any 1 individual   company,   their outlay on that has been minimal compared to the price of paying for a full time developer.   So, yeah, maybe trying to push for   some higher sponsorship tiers as well might be an option.  

But what I think 1 of the 1 of the difficulties for people trying to get into it is it's a lot easier to make the case for sponsorships   if you're able to actually free up the time to put in the work as a result.   Right? So,   I kind of was very fortunate to be able to get over this hurdle of,   right, I've got enough coming in that I can afford to work on this full time.   It's much more difficult if you're actually in a full time job   to go, well, how am I gonna launch a, you know, how am I gonna make the case for   I'd like your company to give me this amount of money in order for me to keep working on this   when you're only able to ever work on it as a side project and your time's constrained anyway.  

So getting over that kind of initial jump, I think, is is 1 of the really difficult things as well.  

[00:20:30] Unknown:

And I find it interesting too that you've decided to go about this independently   and build your own organization and try and establish these direct relationships with sponsors.   And I'm wondering what your thinking is on the benefits of that, at least for yourself, versus going with something like the Tide Lift model or the Open Collective model   of using   the,   sort of broader reach of these organizations as a means   of establishing relationships   that you are maybe 1 step removed from, but still being able to use that as a means of gaining funding?  

[00:21:05] Unknown:

I mean, first off, I don't think either of I don't think Open Collective existed   when we launched the model. It might have done. Tidelift certainly didn't.   I'm a bit   lukewarm   on   the tide lift model because   basically, you know, it brings in an extra intermediary   And there's already   so little   cash   in the system   that   I don't particularly wanna be paying somebody else to sit between   me and and the sponsors.   But Open Collective, I think, is actually, as it happens, seems to be organized much much more similarly to the way that we do our sponsorships.   And, you know, Stripe is   Stripe and also now that GitHub   have their own mechanism   for getting sponsors to sign up. You know, there there isn't actually that much work to do   in terms of   what infrastructure do you need if you just wanna be able to start taking payments from folks.  

So, yeah, having that direct   relationship   certainly works for me at the moment. There's other things that I would consider as well, like,   you know,   for   for HTTPX   and some of this, you know, there's a whole load   of   vital   HTTP   infrastructure   for Python that is   really underfunded.   And I'd be really interested to see a model   where   it's not going directly to encode,   but instead we got a whole bunch of people together   and   try to launch the same sort of funding model, but maybe have the funds go directly to the PSF   who could then contract out for work,   you know, or something like that. So, yeah, I'd be I'd be interested in   alternatives 1 day. But   certainly,   having a direct relationship   to the sponsors   has been   quite freeing   over the last 3 years.  

Although there's I suppose there's 1 thing that has   been a bit of an unknown to me is   they were originally launched as Django Rest Framework Sponsorships   and that's still what they're build at and that's still   how the kind of the package is presented.   But that's not where all of my time is dedicated though these days. There's Django rest framework, but there's all the other stuff that I'm doing as well.   And the   should I start calling these encode OSS sponsorships?   And   is that a good sell for most of my sponsors or not? It's still a bit of an unknown for me. So but, I mean, realistically, that's where it actually is at the moment. So Yeah. Marketing and sales are hard.   Yes.  

Yeah. And branding too. Absolutely.  

[00:24:07] Unknown:

And,   in terms of the particular   market that you're focusing on, you mentioned earlier that you're spending a lot of your time and energy on the web   and the Python ecosystem therein.   And we've also mentioned how a lot of your current focus is on some of these different aspects of async within the web context.   And for people who are familiar with Python web programming   in the context of WSGI and this threaded model where everything is synchronous,   what are some of the practices that they need to unlearn or some of the communal knowledge that is no longer accurate in this new land of async?  

[00:24:47] Unknown:

I'm not I wouldn't exactly say that. I mean, you know, I would bring as much as   Django,   you know,   Django   is such   a solid   kind of best working practices guide   that   I would say, you know, look to how Django does stuff and try to do stuff as similarly as possible to that. The difference is more that because   in a lot of cases, you're having to build everything up from scratch again,   You can   revisit   some of the finer details of how you're approaching these things. Right? So for example, you know, Starlet,   it's built all the way through to try and be a very   low complexity   stack while still being super capable. The but the 1 the 1 thing that   I have tried to approach a little bit differently there is   trying   to build   more components that are reusable   across different frameworks   rather than being tied to a particular framework.  

So for example,   trying to promote   ASCII,   ASCII middleware   rather than framework specific middleware,   trying to promote, like, pluggable   ASCII applications   rather than everything being coupled to the framework. So for example, in Starlet, there's a component which is   a static files app, and you can plug this static files app into   any ASCII web framework.   And   also, you know, like, the the middleware is all just ASCII middleware, so you can plug it into   any ASCII framework.   They,   same with the test client. The test client is built to interact with   the ASCII interface. So you can use the test client with any ASCII web framework.  

So, trying to improve the   by having components designed kind of at that level.  

[00:26:58] Unknown:

And another   major   recent occurrence is the final deprecation   of Python 2,   and I'm wondering   what your thoughts are on   how that's going to impact the overall growth and direction of the asynchronous web in Python now that there are   fewer people who are going to be trying to maintain backwards compatibility with Python 2   and   will free them up to be able to be more forward looking in their usage of the language and its capabilities?  

[00:27:31] Unknown:

Not sure really. Although   it's been nice moving on from actually,   like,   being able to drop support for 3.5.   And before that, I think, you know, originally with Starlet, I can't remember whether we're working 3.4   as well or not. But   really, it's only   from,   you know,   the the more recent set of releases. So certainly 3.6   onwards   have had enough of there there were a few async primitives   that weren't there before.   I'm gonna forget right now, but something like, you know, async generators also. Some bits and pieces that would be really fiddly to do in earlier versions of 3. So it's been nice seeing   Python 3 really start to mature and all the new versions there start to come along.  



[00:28:22] Unknown:

As you continue   down the road of working in these different libraries   and the current set of frameworks that you're supporting   and continuing on building your career around open source,   what are some of the areas of potential focus that you think are worth more attention and energy for yourself and also just for the broader community?  

[00:28:43] Unknown:

For myself,   where I would where I would really like to be is somewhere   is focusing   on   how do we   bridge the gap between   framework space   and product space.   So what I mean when I'm talking about that is   if you've got a team who wants to start working on a new,   say, web back end at the moment, they've kinda got 2 options. You can go for a hosted service, something like Firebase,   where you're then kind of completely   in on that product,   and you're not really ever gonna be able to migrate to anything else. And if there's something that the product doesn't do,   then you're kind of out of luck.  

Or you go   for something like Rails or Django and you build everything   up from scratch.   And I think there's this huge space in the middle for how do we start to build   more and more evolved frameworks   that   start up, you know, they they you can get started with them   like a product. So here's the page where you wanna start fleshing out your new API   and be able to start plugging a front end into it because there's already a service there that's live and and going.   But,   okay, you wanna take complete control over that   and actually get the source code for the thing that's running at the moment and   change it and start hosting it yourself. Well, here's this big button over here that will let you do that, so that   we're giving developers this really nice   easy on ramp to get productive really, really quickly,   but without locking them in to a particular product space as well. So that's kind of where I'd really like to focus.  

And I think, you know, like, the opportunities   there   that   I would like to try and tackle, you know, stuff in the API space,   in the real time APIs   in particular.   And,   you know,   both GraphQL   and   and REST as well because I still see so much potential for improvement in   the   standard REST web APIs that are being built out and improving that space.  

[00:31:15] Unknown:

And another area that seems to have been 1 of the slowest to develop, particularly in the asynchronous environment,   is   the database connection and being able to handle that in an asynchronous fashion. And I know that you've got the ORM library that's looking to tackle that problem. So I'm wondering what your thoughts are on some of   the inherent challenges in that space, and then just some of the direction that you think that that can go and some of the directions that you like to see it go as far as being more   widely adopted and more ubiquitous to   remove some of these different layers of synchronicity   in the overall   process flow for these web applications?  



[00:31:59] Unknown:

I guess there's a couple of different things. Right?   When   when I first started looking at the existing   asynchronous   database drivers,   there wasn't really a standardized   interface   for those.   So   where when you're working with Django, if you wanna switch to a different database, you just need to switch the database URL   in your settings. And   in a whole bunch of cases, that's gonna be the only thing that you need to do.   Otherwise, everything's transparent   and, you know, you might be running your tests against SQL   lite,   but in production staging your postgres.  

Although the application code looks exactly the same in both cases. So   trying to build   layers   of interfacing with this stuff in the way that you're not locked into,   like, this is the 1 particular async database drive that I'm using. But instead,   let's have a sensible level for   interacting with the database   that doesn't need to know about those, and just be able to plug in whichever   database driver we want underneath that or swap out to a different 1 if there's   some particular gnarly problems with it and we wanna use something else.   So that   and then   trying to introduce   really nice   modularity   in the different layers of concern. So I've got 2 different projects as databases,   which is the kind of lower level.  

We just want to   execute   SQLAlchemy   call   statements. And then there's   ORM on top of that, which is   how do we then   build a kind of a fully featured   ORM on top of that. So   trying to look   at NICE   layering   and also,   again,   how do we approach this in a way that's not framework specific. Right? So   the Django ORM, if I was working in the sync space,   would be kind of my preferred choice because I just find it, like, the easiest   thing to work with.   But   I find it a bit of a shame or, you know,   I   I think it would be lovely to have a project that's as mature as that but isn't specifically tied to 1 particular framework.   And that's   not even always because   I want to choose to use it with a different framework, but sometimes it's because, well, if I wanna go and understand how this component works,   if I know that it's   properly bounded, then I've got this kind of 1 set of stuff that I need to look at, and I don't need to think about,   oh, is there something magic in Django settings that's changing this thing, or   do I need to look at how this other module interacts with that? It's just about kinda keeping the complexity nicely bounded   at at each different  

[00:35:13] Unknown:

level. Yeah. It's definitely nice being able to treat different layers in isolation without having to try and figure out what are all the additional layers sitting on top of it that are actually manipulating the request along the way or adding different context so that I have to try and figure out how to fit into my head to be able to comprehend the overall flow of what's happening. And it doesn't make sense to do these things with Django or Django's ORM because they're so mature and they're they're in their space.  

[00:35:43] Unknown:

But, you know, when you happen to have a great big new green space   that needs building up anyway,   that's the time to kind of that's the the time to do it.  

[00:35:57] Unknown:

And are there any other aspects   of your work with the encode organization   or your work in the web space and async in general or any of the other aspects of the Python language or community or your career that you're focusing on   that  

[00:36:16] Unknown:

we didn't discuss yet that you'd like to cover before we close out the show? Well, I guess there's HTTPX   is the   newest project that I've been working on.   Haven't   talked a lot about that today. So that's   a new HTTP client where we're aiming for feature parity with requests,   but also adding support for both   sync and async APIs with it,   and also bringing support for both HTTP 1.1   and HTTP 2. So that's the the big thing that I'm working on at the moment.   And   other than that, we'll see what comes next.  

[00:36:51] Unknown:

Yeah. The h t t p x project is definitely pretty ambitious given the ubiquity of requests   across the entire community.   So I'm wondering what your thoughts are on the API design of requests as far as   is it a benefit to you because you don't have to think about that interface and you can think about just the plumbing of things? Or is it acting as a constraint because maybe there are different things that you want to be able to do because of the async capabilities that you're adding No. Heading in. It's it's a it's massive  

[00:37:21] Unknown:

a massive benefit.   You know, it's easy to kinda take for granted, but it   it it just it takes away so many   places where you would otherwise have   an open API design question and you go, okay. Well, I don't really have to. I mean, it was   quite involved   trying to figure out   the right way to approach   bringing both an async and a synchronous API to that. And there are a few places where   it diverges from requests because of that,   but not having to kind of think about all of the rest of that space has been really helpful.  

[00:38:01] Unknown:

And are you keeping an eye on what's going on with the HTTP   3 standard that they're trying to introduce right now? And what are your thoughts on the just sort of direction that the web is moving?  

[00:38:13] Unknown:

Yes. So Jeremy Lane   is doing a whole bunch of work on that, and we've been chatting.   And, yes, I can see   HTTP   3 support coming to   the HTTP x library at some point.   I don't know whether there's necessarily   as much benefit in Python or other dynamic languages as there might be in   other different contexts.   Like, you'd, you know, you'd you'd need to actually   look at the the   because it's more compute intensive.   Right?   So   there might not be as much benefit for Python as there would in some very, very   low lower level languages.   But, yes, I I can definitely see it coming to HCCX   at some point, and   it'll be a case of   looking at the evidence for seeing, well, how much difference does this make? And it's more likely that it would be, look, here's this   optional   thing that we have at some point in the future   that if you want, you can try it out and give it a go and see does this make a difference in your case. And it's likely to just be some   more specific kinds of use cases where it actually makes a difference for users.  



[00:39:33] Unknown:

Yeah. It's definitely interesting to see how the web has sort of accelerated its evolution where we had HTTP 1.14   decades, and then all of a sudden there's HTTP 2. And then only a few short years later, they're trying to add a new protocol on top of everything else. Yeah. Yeah. And I think it's worth folks as well  

[00:39:52] Unknown:

taking quite a balanced view onto it as well.   The   even going from HTTP 1.1   to HTTP 2,   I think, you know, there's so there's so much extra complexity   that that brings,   and it should definitely be treated as a   okay. Let's try using this.   Does it does it actually improve things or not? You know? Don't just blindly go, oh, wow. HTTP 2. That sounds snazzy. That's got to definitely be the thing that we ought to be using. Right?   So, yeah, I I kinda have slightly mixed feelings about the the ever growing complexity of HTTP.   And HTTP 1.1, that is enough   gnarly edge cases in it anyway.  



[00:40:40] Unknown:

Well, for anybody who wants to follow along with your work or get in touch, I'll have you add your preferred contact information to the show notes.   And so with that, I'll move us into the picks. And this week, I'm going to choose a couple of movies that I watched with my kids recently.   The first was a movie called Abominable   that was just   very well done,   visually appealing and humorous   about a group of kids who are trying to get an abominable snowman across China back to his home in the Himalayas. Oh.   And, the other 1 is Maleficent mistress of evil, which is a sequel to the original Maleficent movie, which   is taking a different view of the, oh, the Sleeping Beauty story,   and giving it a bit of a spin. So   just very well done visually, good storyline.  

Had a lot of fun watching that as well with the kids. So if you're looking for something to watch, definitely worth checking out either of those. And so with that, I'll pass it to you, Tom. Do you have any picks this week? Alright. Sure.  

[00:41:38] Unknown:

So   out of nowhere, let's go for The Lobster,   which is   just a very strange film. That's all I want to say about it. Strange and   sometimes funny, some quite dark.   Yeah. I won't say anything about it. It's just odd.   And   something that I've just about finished reading recently,   a book, The The Master and His Emissary,   I found   really, really interesting. It's about   the 2 different hemispheres of the brain and the author's particular take on the the kind of the cultural implications   of what the 2 different hemispheres   each focus on and what their kind of the world view that each of the hemispheres has. So that's, the master in his industry,   by Ian McGillchrist.  



[00:42:33] Unknown:

I'll definitely have to take a look at that. Well, thank you very much for taking the time today to join me and share your experience of working in the web context with Python and delving into async and your experience of   approaching sustainability of open source. Definitely a lot of complex and interesting topics. So I'm glad that you are making progress and having success with those, and I hope you enjoy the rest of your day. Cheers. Thank you so much, Tobias.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at data engineering podcast.com   for the latest on modern data management.  

And visit the site of python podcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host@podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.