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 Okken.
And this episode is brought to you by DigitalOcean.
Check them out at pythonbytes.fm/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, you know, especially in the world of Agile and Scrum and two-week sprints.
Like, 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.
There's an announcement.
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 like this overlap, right, 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.
There was 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 allows for a more natural calendar version.
So, for example, Python 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.
Well, it goes 3.9 and then 3.20.
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, that would be 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.
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.
And 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.
It's 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.
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 MicroWSGI and G Unicorn and whatnot support that.
And that's like how they click together.
Right?
That's their docking mechanism.
And WSGI 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.
Right?
Like 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.
It's mostly what they do.
Yeah.
And so, if you could let your server do other stuff while that'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 Starlit and UVicorn and so on.
So, what this 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, Jepronto was really this big thing until it wasn't.
Stopped getting worked on it, right?
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 frameworks talked about here.
Bocadillo, Channels, FastAPI here is really good.
Core is a solid one for converting Flask to async.
Responder, Starlit.
Starlit 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, like, just a straight awesome Python list or Mamu Tashemi's awesome apps list or something like that.
But I do think it's important and, you know, 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 another awesome – a couple other awesome projects, but they're not awesome lists.
Two awesome projects I want to talk about, sort of, are Jupyter and Pangio.
This comes up because there was an announcement titled that Jupyter meets the Earth, which is kind of fun.
Plus, they're both circular logos.
The Earth has a logo.
It 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 Jupyter infrastructure and Jupyter and Pangio.
And it's – 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, Jupyter 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, Jupyter is definitely doing well in the funding space.
And I didn't know where Pangio 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 –
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, you know, 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 Fernando Perez.
And just want to mention, Lindsay was on Talk Python quite a while ago talking about Pangio 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, you know, MySQL and Redis also are as well.
And Redis kind of plays an alternate role anyway.
It's, you know, 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, 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 separate project, right?
Yeah.
Until now.
Yeah.
So tell me.
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.0 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 Python.
So you've 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 can check that out.
But the big news, I think, here is ASGI support for Django 3.0.
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 expecting 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.
Okay.
It's going to be interesting, the database story.
Like, Django has a built-in ORM, and it says things like there are some side effects to be aware of.
Like, 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 really got into that before, so that's kind of an interesting side story as well.
Yeah, absolutely.
Anyway.
So there's all sorts of stuff we're linking to in Django 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 a possible.
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?
This 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 like 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.
Has unproductive and productive days.
Fails from time to time.
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 is 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 like that.
Maybe Commodore 64 font.
It's beautiful.
Yeah.
At least it'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.
Oh, yeah.
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, you know, 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.
Yeah.
And then it says, how long is it until the sunset date?
The Python clock will tell you, it says, which is three months, 20 days, 10 hours, 31 minutes, and 37 seconds.
That's less than four 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 know, 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.
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 our software conferences, the Python announcement mailing list, Python blogs, textbooks, technical articles, social medias, and companies that sell Python support.
Oh, and podcasts.
Does it say podcast?
No, I've amended it.
Yeah.
I believe we have talked about it.
Now that I've gone through it, 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.
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 you got you want to throw out there?
Well, there's two big newses 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, we, 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.
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 from, if you listen to this, the moment that we released it.
So there'll be some time, but not a lot.
And there's like $1,000 worth of stuff for $15 or something like that.
Seems like a good deal.
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 wah me.
But I'm going to put my, I guess, effort where my mouth is and start a west side 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 like, you know, steal their thunder or something.
I've talked with the Python meetup dude from Portland and 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.
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.
Sounds great.
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.
So.
Nice.
All right.
Well, thanks for being here as always, Brian.
All right.
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 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 Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.