Python Bytes - #148 The ASGI revolution is upon us!

Episode Date: September 18, 2019

Topics covered in this episode: Annual Release Cycle for Python - PEP 602 awesome-asgi Asynchronous Django Sunsetting Python 2 Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/148

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 148, recorded September 11th, 2019. I'm Michael Kennedy. And I'm Brian Ocken. And this episode is brought to you by DigitalOcean. Check them out at pythonbytes.fm slash DigitalOcean. More on what they have to offer later. Brian, I feel like Python doesn't ship often enough.

You know, it's like an 18-month release cycle. That's a really long time to wait for these features to come out, especially in the world of Agile and Scrum and two-week sprints. A year and a half is a long time to see an idea and have it happen. What do you think? It's like eons in Internet time, right? Right, for sure. I'm actually excited about this.

It's not been announced or decided yet, but there's a PEP, PEP 602, which is under discussion. We've got links to both the discussion and the PEP, but it's to bring an annual release cadence. So every year, every 12 months, instead of every

18 months. And there's some specifics around it, which are kind of neat. It does not mean that people will develop each feature, each release in 12 months. It's actually a 17th month cycle, which is weird. It's interesting. It totally makes sense when you read it. My first thought was, how do they fit 17 months into 12 months? You go really, really fast and then you change a little bit of space time. There's five months of unversioned overlap time where some of the new features can get worked on

and they're not doing releases. Yeah, that's really interesting because they have a cool graph in here that shows them overlaid and actually all the releases laid out. I don't know, it's about a third, a little more than that down the page that we're linking to.

And it shows, okay, we're going to work on the alpha features, which is creating the feature. And then beta is kind of where it stabilizes and gets cleaned up. But as it switches to beta for one, it kicks off for development. Maybe more a little bit later. But there's this overlap where you stop working on one and you also concurrently start adding new features. That's what happens in software projects anyway. Like in a commercial world, you're wrapping up one release while people are starting to work on features

for the next release anyway. It's just this reality anyway. I think it's good. There's some rationale and goals, smaller releases, less stuff within each release. One of the big ones is there's often a rush to get stuff into the first beta because if it didn't get in, it's not going in this one and it has to wait 18 months.

And waiting a year, it's only six months difference, but that's a big difference. So there are also some weirdness with how, I mean, there's annual sprints and PyCon, which is about the same time every year. But having the release cycle be sometimes offset by six months every time just was weird. Yeah, it means like the sprints can more carefully align with, say, the alpha stage or something of the next version, right? They time it right. There's also a mention in the non-goals section about switching to an annual release calendar is the last for more natural calendar version so for example python 320 3.20 might be the one released in october 2020 the one python 3.23 would be the one

in october 2023 and things like that. That might be nice. Yeah, but we're only up to like 3.8 now. How did we get from 3.8 to 3.20? Yeah, switching. It goes 3.9 and then 3.20. That's like, that's how you count. Yeah.

It's pretty good. Yeah, so this is proposed by Lucas Lenga, and he's currently the release manager for Python. So he's the one with all the skin in the game. And yeah, I think this is nice. I've always thought it was weird to have such a long release cycle, so I'm happy to see this. I mean, there's risks and downsides, of course, on the other side. Also, with that same graph, you notice that there's five versions supported at a time instead of four.

So there's the test matrix of people doing distributions. They got to test five versions instead of four if they're testing everything. It is what it is. So yeah, it's interesting. There's some rejected ideas as well. Keep the current 18 month release cadence.

This is rejected. We don't like it. Double the release cadence to achieve nine months between major versions. But it's too irregular and too short. And just slow down releases and don't freeze them at beta one. Yeah, I like it.

This is pretty good. I mean, it wasn't even considered to have weekly release cycles. I'm not sure why. Yeah, we just ship whatever is on the master branch. Yeah, daily, nightly builds. Nightly builds. Might hold off on that. So this next thing I want to talk about, it's pretty awesome, Brian.

Is it? Yeah. It's called Awesome ASGI or ASGI. I don't know. I'm not sure what the phonetics of ASGI, but we have WSGI, which are the WSGI servers. This is like the traditional web service gateway interface where basically all the different web frameworks like Django, Flask, Pyramid, and so on implement that. And then all the servers like MicroWhiskey and GUnicorn and whatnot support that. And that's like how they click together.

That's their docking mechanism. And Whiskey is broken, fundamentally irreparable, broken for building asynchronous web apps. That's unfortunate because async and await and async IO is most important on the web server. What do web servers do? They wait on databases. They wait on the network.

They wait on third-party APIs like Stripe. They just wait. That's mostly what they do. And so if you could let your server do other stuff while it's waiting, you could massively amplify the concurrent number of users for the same amount of hardware and things like this. So enter ASGI. I'm going to go with ASGI for now until somebody shows me the right way to say it. So ASGI is a new interface for this successor to WSGI. And it came out of Django Channels,

which is a way to add some asynchronous behavior to Django. And it's also got boosted by things like Starlet and UVicorn and so on. So what this is, is it's an awesome list for all sorts of things around asynchronous web Python things. So we have async web apps, async web frameworks, async web servers like UVicorn and so on. So if you are wanting to build some sort of high load, highly scalable website and you want to figure out what should I be using, it's super confusing right now because things come and go so fast like japan was really this big thing

until it wasn't stop getting worked on it right like there's like the shelf life is no longer 10 years it's maybe you know a couple months so knowing what's happening in this space is pretty hard there's some good uh frameworks talked here. Bocadillo channels fast API here is really good. Core is a solid one for converting Flask to Async. Responder, Starlet. Starlet seems to be the foundation of almost everything these days. So it's

really probably the most important here. But a nice grouping of all these various things that you might want to work with. Yeah, and they also want to try to do more than just applications, but also libraries and middleware items as well. Yeah, so this is not as popular as, say, just a straight awesome Python list or Mamoud Hashemi's awesome apps list or something like that.

But I do think it's important, and hopefully people go out there, if they have some ideas, they can contribute some projects to the list. It's not too hard. Yeah, definitely. All right, what's next? Well, there's if they have some ideas, they can contribute some projects to the list. It's not too hard. Yeah, definitely. All right, what's next? Well, there's another awesome, a couple other awesome projects, but they're not awesome lists. Two awesome projects I want to talk about, sort of, are Jupiter and Pangaeo. This comes up because there was an announcement titled that Jupiter meets the Earth, which is kind of fun.

Plus, they're both circular logos. Earth has a logo. Looks like the Earth. Yeah. This is a write-up about a really cool announcement that the National Science Foundation is giving $2 million of funding over three years as part of an EarthCube grant program to go towards Jupiter infrastructure and Jupiter Impanio. And hopefully it will be pretty cool. It's actually a really neat write-up talking about how the adoption of open languages like Python and on top of that,

Jupiter and others have really been taken up by a lot of different science backgrounds. And we really need some more Earth-based science to utilize this. And so this will help it out quite a bit. It's kind of neat. This is super cool. And it's really great to see them getting so much funding. You know, Jupiter is definitely doing well in the funding space. And I didn't know where Pangea was before, but it sounds like this puts them really solidly in the stable and growing, getting lots of support space. One of the things I love about Jupyter and Python being the center of around and some of the data science is the openness.

So people are really pushing for open data as well so that anything that gets published can be seen by other people. I think that pushes science forward really far because just even people in their bedroom might have a cool idea with the data and find some things that other people can't and help contribute. It's really kind of incredible to be part of this. Yeah, absolutely. And one of the use cases is for climate data, climate change studies, and things like that. So definitely need some attention on that. I'm sure there's plenty already, but more is good here. So this write-up is by Lindsay Hagee and Fernanda Perez. And just want to mention, Lindsay was on TalkPython quite a while ago

talking about Pangeo and her earth science research she's doing. So geoscience, things like that. So if you want to dive deeper, check that out. Yeah, very cool. Yeah, for sure. Now, before I spring some pretty big news on people, let me tell you real quick about DigitalOcean. So all of our infrastructure runs on DigitalOcean.

They've been big supporters of the show. Their newest thing is that they just launched two new things as a service. So you can, instead of have servers to manage, you just check a box and now you have services at your disposal. Those are MySQL and Redis. So if you want to use MySQL or Redis, you can now start doing that over at DigitalOcean. Previously, they had Postgres as a service, and Postgres is very popular in the Python space. But MySQL and Redis also are as well, and Redis kind of plays an alternate role anyway

as a traditional relational database, caching and things like that. So check that out, along with a bunch of other good things, Pythonbytes.fm slash DigitalOcean. Now, I told you about the cool awesome list, right, Brian? The awesome ASGI, I'm saying? Yes, asynchronous is here to stay.

It is here to stay. Now, there is a very notable absent framework in there. Talked about Quart. That's kind of the async version of Flask, if you will. There is some talk that maybe those two projects will work together and just make Flask itself asynchronous. But that's a different story. But there was nothing in there really for Django. I mean, there's channels, but that's a different story but there was nothing in there really for django i mean there's channels but that's a separate

project right yeah until now yeah so tell me i'm i'm excited what's going on yeah so i don't know exactly how recently this was announced because there's no dates on the announcement which makes it tough to know but django 3.0, all the details for its roadmap are now out. So the release notes for Django 3.0 are here. It's expected that Django 3.0 is going to be released December 2019. So that's like a Django Christmas present or whatever, something for the holidays, right? Coming soon. And there's tons of changes, right? About, for example, Django 3 only supports Python 3.6 and above. They are dropping support even for 3.5.

And if you want 3.5 support, you have to go back to 2.2. And of course, 2.2 or 2.0 already dropped support for legacy Pythons. You got to even go farther back to get way back there. You don't want to go back there. No.

But that's all good. There's a bunch of other changes. Marriott and DB support and various things. You don't want to go back there. No. But that's all good. There's a bunch of other changes, Marriott and DB support and various things. You can check that out. But the big news I think here is ASGI support for Django 3. They say Django 3.0 begins our journey to making Django a fully async capable,

to making it fully async capable by providing support for running it as an ASGI app. And that doesn't mean they're dropping WSGI support. They're expected for these to sort of pair together, as you might expect, right? A lot of these can be run in either way, but you have to run it on an ASGI server to get the async features,

as we kind of hinted at before. Pretty cool, huh? Yeah, that's very cool. Yeah, so you don't need to change anything about your code, but you'll be able to start writing asynchronous methods. So when you're waiting on that database or that web service, you can now wait on 1,000 of them instead of one in the same process with about the same amount of work,

which sounds like a pretty awesome change for almost no effort. Well, you said you don't have to change anything. Does Django have an upgrade migration path for people to upgrade? Well, I think you just have to start rewriting your view methods. You've got to add the async keyword, async def instead of def, and you've got to start using async libraries. It's going to be interesting

in the database story. Django has a built-in ORM, and it says things like there are some side effects to be aware of. Django is now aware of the asynchronous event loops and will block you calling code marked as async unsafe, such as ORM operations. So maybe, I don't know what the story is around the ORM and async.

Maybe it's not totally clear, but it seems like a really good place to actually have async because the thing you wait on most is databases, so you should probably be able to wait on them. Yeah, and I actually am also interested in the MariaDB. I hadn't't really got into that before so that's kind of interesting side story as well yeah absolutely anyway so there's all sorts of stuff we're linking to in jenga 3.0 but i think the big news is front and center async support right in the main project and i wonder if the drop of 3.5 is because people like F-strings.

Yeah. Yeah, I think so. Yeah, it's like, we can't not use F-strings. I want to run Flint on this project, but I can't because it might run in 3.5. Let's make that impossible. Yeah, yeah, okay.

I've heard about this possibility of different software engineers having different levels of effectiveness. And oftentimes, this is referred to as the 10x engineer, right? The special person that makes all this money and actually makes the startup do its thing or whatever. John Carmack and Doom.

So you found another kind of engineer? Yeah, I really like this list. I found the 1x engineer. The 1x engineer, awesome. What constitutes a 1x engineer? Well, there's a whole list and you can contribute it because it's based on a GitHub repo.

I think it's definitely a fun take on the 10x thing, but if you look at these lists, I think some of these are really good and I think actually should have been something like maybe 3x or 4x or 8x or something. I'm not sure how high this scale goes anyway, but here's a few of them.

1x engineer has a life outside of engineering, writes code that others can read, doesn't act surprised when someone doesn't know something, asks for help when they need it, is able to say things like, I don't know, constructively participates in code reviews, shares knowledge, never stops learning. So I like that because obviously they listen to Python Bytes, talk Python, and test in code.

Absolutely. Yeah. It has unproductive and productive days. Fails from time to time. It doesn't hate on framework Y when working with framework X. Anyway, we pulled out a handful of these to put in the show notes, but the list is pretty long. And I like it. It's kind of a neat, fun take on just basically this is what we expect from everybody very nice

it says i've never heard of that in lieu of nodding and pretending and also is willing to have a brightly colored desktop background very nice yeah i think the new 10x engineer has pink not black that's right now this actually, this is really great. I like it. It's fun. And it's written in very fun fonts and style, right? There's a button there that says you can go away from the fancy style. Nice.

What is that font? It's like, I don't know. I think it's Atari 2600 font or something. Maybe Commodore 64 font. It's beautiful. Yeah. At least it's not Comic Sans. Nice. Yeah, for sure.'s not Comic Sans. Nice.

Yeah, for sure. Thank goodness. Or Blinky. Okay, now there's a topic that I think is important, Brian, that we should touch on. Will you just tell me if we've spoken about this before?

It has to do with Python 2 going out of the world here. Sunsetting Python 2. Have we spoken about Python and legacy Python? Maybe we haven't. So if we haven't, people should get onto the Python 3 thing. That's right. Now what we're linking to is an official document that formalizes the sunsetting of Python 2. So this is over on python.org slash doc just sunset Python 2 with dashes. I'll link to it. And it's sort of a Q&A

like, what if I didn't know Python 2 was going away? What should I do? And so on. So let me just talk to you real quick about this. This is something good you can share with people who are like, wait, why is our Python old? What are you telling me? So it says officially January 1st, 2020 will be

the last day, or the day that Python 2 is sunsetted. I thought it would be really great. New Year's resolution, write no more Python 2 code, I guess, is the way to interpret this. And it says, Q&A, like, why are we doing this? We need to sunset Python 2 so that we can help Python users. We want to add new features to Python 3

and stop supporting Python 2, even though we're not adding features to it. And it says, you know what, back in 2006, like long ago, we started working on Python 3. And in 2008, we said 2015 was the end of Python 2. That didn't work out so well. So now we're really meaning it 2020. And then it says, how long is it until the sunset date?

The Python clock will tell you, it says, which is three months the sunset date the python clock will tell you it says which is 3 months 20 days 10 hours 31 minutes and 37 seconds that's less than 4 months

that's coming up this is for real yeah it's even faster if we hold off releasing this episode that's right it's already going to be

out of date it says what will happen if I do not upgrade by January 1st oh I'm going to come to your house and ridicule you. No. That's right.

Yeah, you'll be mocked by all your peers. No. It says, look, if people find catastrophic security fixes in Python 2 or software written in Python 2, most volunteers will not help you. You know, over time, you'll find it harder to hire people. You'll find it harder to use modern libraries and so on. So probably not the world is going to end straight away, obviously, but you're going to be in quicksand at some point, right, to some degree. It says, okay, fine, I wrote some code in Python 2. How should I port it to Python 3?

It says, please read the official porting guide here. And finally, I didn't hear anything about this until just now. Where was it announced? Well, we talked about it at software conferences, a Python announcement mailing list, Python blogs, textbooks, technical articles, social medias, and companies that sell Python support. Oh, and podcasts. Does it say podcasts? No, I've amended it. Yeah.

Yeah, I believe we have talked about it. Now that I've gone through, I do remember speaking about legacy Python before. Yeah, we have. And then the last question of how can I make sure that I don't miss stuff like this again? Listen to Python Bytes. That's how. That's right. That's the official recommendation from the PSF, I'm sure.

No, it's a... Or mailing list, I guess. But no, I do think, I mean, we cover, we try to cover this kind of stuff for sure. Yeah. Duh. Yeah. We try to cover this kind of stuff, for sure. Duh. Yeah, so there is the official sunsetting details from the PSF and the core developers. It looks good to me. Yeah.

Cool. All right, well, that's it for our main items. What else do you want to throw out there? There's two big news, and yours is definitely going to happen, and mine is hopefully going to happen. Mine is in the past, so it is more likely to have happened. Okay, so tell me about yours. All right. We have been working, me and a bunch of other folks have been working with the Humble Bundle folks to release another Python Humble Bundle. Not just a bunch of books like an O'Reilly Bundle thing, but a bunch of cool tools and library courses, everything, right?

So we just launched the Humble Level Up Your Python Bundle. And yeah, there's tons of good stuff, right? So we just launched the Humble Level Up Your Python Bundle. Bundle. And yeah, there's tons of good stuff, right? There's three courses from Talk Python Training. There's the Code Challenges from Python Bytes. There's some PyCharm stuff. There's books from Dan Bader, from Matt Harrison. There's stuff from Trey Hunter, all sorts of good things in there. So be sure to check that out. You can get it much, much cheaper for a very short time. So probably, I guess, a week, a week to two left, if you listen to this the moment that we released it.

So there'll be some time, but not a lot. And it's like $1,000 worth of stuff for $15 or something like that. Seems like a good deal. Yeah. Yeah, it seems great. I see this next thing that you're talking about. You're trying to work on my social life, aren't you? Get me out of the house. Yes. But I want to make it really easy on me. This next one is all about me. Well, it's about you too and everybody else in Portland, but mostly about me. I thought it'd be cool. There's a Python meetup every month,

downtown Portland. And I don't live downtown Portland. I don't work in downtown Portland. So whammy. But I'm going to put my, I guess, effort where my mouth is and start a Westside Portland Python meetup. Yay, that's awesome. Yeah, because to get down to the east side of Portland, if you're out somewhere by Intel or Nike or one of these,

a lot of the tech companies here in town, it's like an hour just one way. It's a tremendous amount of traffic you've got to go through. So this will definitely open up a whole other angle for meetups. Yeah, and I'm not trying to steal their thunder or something. I've talked with the Python meetup dude from Portland and we're working together to make sure we don't overlap it. So I think we're shooting for like the second week in the month because they have things on the third and fourth. There's nothing there yet,

but if by the time this comes out, there will be, I registered pythonpdx.com. That's where we're going to announce stuff. Hopefully for October, October, but if not, then we'll get it done for November, but I'm really shooting for October, October, but if not, then we'll get it done for November,

but I'm really shooting for October. This is made possible because Roden Schwartz, the company I work for has this awesome room that would work great for the meetup and they've agreed to let us use it. So that's all. That's great. Yeah. Yeah. Sounds great. That's all I got, but I don't have any jokes. We don't have any jokes. Hold on. I mean, we could just stare at each other for a few minutes, but it's not fun. Ooh, neat. Why did the angry function exceed its call stack size? I don't know. Why?

It got into an argument with itself. What's the object-oriented way of becoming wealthy? I'm not sure. Inheritance. Oh, yeah, definitely. Of course. All right, well, not terribly funny, but these are some good programming dad jokes. Yeah. I'm not sure inheritance oh yeah definitely of course alright well not terribly funny

but these are these are some good programming dad jokes right yeah yeah so nice

alright well thanks for for being here as always Brian alright thank you bye yeah good to chat with you bye

thank you for listening to Python Bytes follow the show on Twitter via at Python Bytes that's Python Bytes

as in B-Y-T-E-S and get the full show notes at Python Bytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at PythonBytes.fm. If you have a news item you want featured, just visit PythonBytes.fm and send it our way. We're always on the lookout for sharing something cool. On behalf of myself and Brian Ocken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.