Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 119, recorded live from PyCascades in Seattle.
All right, it's great to be here. And this episode is brought to you by Datadog. Tell
you more about them later. Right now, I have a bunch of special guests, none of whom are Brian
Aukin. More about that in a second. But we have Trey Hunter. Hello. Dan Bader. Hey, how's it going?
Eric Cho. Yo. All right. And all of us are here at the conference and we thought, why not put
something live together for you? Now, Brian Okken decided to punish his teeth by having a painful
root canal and couldn't join us in some sort of last minute emergency. And that's really unfortunate
because he was looking forward to be here. So everybody, Brian, we miss you. We miss you, Brian.
Right on. Well, let's go ahead and kick it off. I'm going to do the first thing here. And have you guys
heard of this thing called Dropbox? Yeah, a little bit. They have something to do with Python. Anyway,
obviously, Guido works at Dropbox. It's a huge Python center of the universe there. And what's
really interesting is they're finally migrating to Python 3 and using some of the tools that Guido
has personally worked on with like mypy and static typing and all of that. So that's our first item.
And if you were to guess how many lines of code is the Dropbox code that you're working with,
you know, that little box in your menu bar, your task bar, that's also client-side Python,
which is interesting already. But it's over a million lines of code. So they started way back
in 2015, a little hack week side project to prove whether or not maybe they could do it. It turned
out it's going to be hard. That's what they basically they said. And officially they started the first
half of 2017. And the real thing that helped them do this, which I think is interesting is mypy.
Have you guys heard of mypy?
Yep.
Oh, yeah.
So mypy is, it takes the type annotations or type hints and verifies that, you know,
this function says it takes one of these and you're giving it one of the same things like that,
that sort of thing.
Did Guido actually, like, I don't think he started mypy.
I don't think he started it, but he definitely works on it.
One of the original contributors, I think.
Okay. Did he start it or like, was it started for Dropbox specifically or for the Dropbox codebase?
Just curious.
Yeah, I don't know either, but I know that it was an important thing he's working on.
I'm not sure, but I just want to, it seems like Dropbox been migrating away from like the public
clouds for a while and they've been focusing on just getting things right. So this is probably one
of those things where they think for the long-term growth, it's going to be better than rely on
somebody else's infrastructure.
Right. Absolutely. It's very interesting. They're stepping away from some of the cloud hosting.
Everyone else is running to the cloud. They're like, ah, well, we can make cloud.
That's pretty interesting. So let me throw this out for you all, co-guests and audience members
and listeners. One of the very first things they say in this article is, well, once we were armed
with mypy, the first few steps we took was to port our custom fork of Python to 3.5.
What?
That's big.
I'm like, wait, what? They don't run normal Python? They drop Python? What do they call it? It's pretty
cool.
It's pretty cool. It cross compiles to Perl.
Yeah.
Everybody loves it.
Yeah. So I'll just kind of wrap this up here. But basically this article that we're covering
goes to all the steps of Dropbox moving over. And I feel like if people are going to take
the Python 3 as modern Python and other Python as legacy Python as a legitimate thing, the guy
who created Python had better work at a place that uses Python 3, not Python 2.
For sure.
So I'm super happy to see that's moving along. And also that Guido was a pretty big part of it.
All right. So let's see what's up next here. Eric?
Basically, I want to talk about what I feel was like underserved community in Python. I've come from a
network engineering background and been focusing on network automation using Python. And I think we've
gotten to a point where we're big enough to be noticeable. Like it's actually material for the
amount of community. I mean, we have new terms such as NetDevOps or NRE, you know, not to be subtle
differences from the site reliability engineering for network reliability engineering. We have some
popular libraries from NetMiko, Napalm, who's been on your show before. And I can't even pronounce that
new library, Noner, I think. And N-I-R will have the link in the show notes. Yeah, you know, there's a lot
of free resources out there for people to practice on for either network engineer wants to learn more
about Python or developers who wants to learn more about network engineering. I think coming of age,
I mean, hopefully one day, you know, we're going to have a subculture of Python, just like the data
analysis community that for network engineers. So that's, I want to bring it to everybody's
attention. You could do it for fun, do it for profit. And, you know, it's a welcoming community.
Yeah. And you link to a bunch of resources in the show notes that people who are into that can check
out. And yeah, Python's a mosaic and there's so many people doing different things. And here's just
another part of it, right? Yeah, absolutely. I mean, I'm super excited about this because I think,
as you mentioned multiple times on your show, it's like you get started early or started easily,
but you know, you don't hit that ceiling. I mean, I've been doing this for five years and I haven't
found that ceiling yet. It's a dot to me. So yeah. Is that a sign of growth that the Python community
has seen where now, you know, it makes sense to have a niche for network automation specifically?
I think people are still trying to figure out like how this thing's going to go, which is
with lots of changes presents more opportunities for people. And Python kind of sort of just emerged in this
de facto and speaks to the versatility and the power of the language. I think we're in that phase,
we're trying to figure it out. And we just kind of have this trending versus like nobody has the
right answer. But that means at the same time, that's where the opportunity lies. You know,
you could figure it out and could drive that direction. And I think the developer actually
has a huge advantage that everything is virtualized, everything is abstracted away from the physical.
So that's my thought at the moment. You know, you could see like, I'm not very clear either.
I think it's super interesting that you pointed out how everything's abstracted and sort of cloud
programmable. That means like Python has a better chance in the network space if it's not all hardware
and boxes and stuff, right?
Yeah, for sure. I think one of the challenges for network engineers such as myself going into the cloud
is that the fact that, you know, there's no longer broadcast domain, your net, your nick is actually
physically attached to you. So things that we took for granted that were fixed is no longer true.
So you get to have like a network NAT gateway that's just arbitrarily attached to your virtual subnet,
which, you know, you used to, I think if you work in the traditional enterprise, like the first thing
you do when you get a new team is like, you subnet it out, you give it an IP address, you subnet.
But those are all virtualized nowadays. So you still need to understand the basics. But that basic used
to take years to master it. Now it's just a matter of reading a doc. So yeah, hopefully, you know,
you guys, you know, come say hi, if you see me at Ansible Fest, at Cisco DevNet Create at,
you know, some of the Juniper events, you know, come say hi, let's talk. And I think we could make
this potentially make a great community out of it.
Yeah, put Python on the wire.
Yeah, yeah, for sure. Buy you a Python beer.
Yeah, but it's funny, Python really is a mosaic. I mean, that's, I didn't understand. Well, I understood
a lot of the terms you were using, but what they actually mean, I don't know, because I don't need to know
what they mean. And in the space of Python that I kind of am part of, this next thing I've got is
kind of related to the fact that Python is a mosaic. It's kind of part of the web side of the mosaic of
Python, which gets maybe more reputation than it deserves in the sense that there's a lot of folks
using Python for the web, but it's not all you can use Python for at all. I mean, data science is huge.
But if you have to process data, and it's not in a database, and you are someone who's familiar with
Django, there's a thing called Alkali that Kurt made. I can't remember Kurt's last name. Remember,
Kurt's in the room, and we actually, it's Kurt Neufeld. So it's funny being at conferences,
you sometimes just meet the people who end up, you know, making the things that you're using. So
Alkali, I'm not using, but it looks kind of fun, because I'm familiar with the Django ORM.
And Alkali, it's meant to take structured data, maybe an RSS feed, maybe a CSV file,
maybe JSON data, maybe some random homegrown thing that you've got on your team or in your company,
and allow you to use a Django ORM like syntax to query it and also to save it,
maybe in some other format, even. So it's as if you're working with a database,
but you don't actually have a database behind the scenes, you've got some structured file. So it's
kind of does that all in memory, which is fun,
right. So maybe you're working with XML, and you don't want to learn XPath,
or you don't want to write regular expressions against CSV files.
Who wants to learn XPath, man?
Nobody.
Hey,
rhetorical question.
Hey, man, the 90s are calling, they want their API back.
Here's my style sheet says nobody ever.
Yes, exactly. So I think this is a cool project, Kurt. I definitely like that you can point it at even
like something, an endpoint on ATP service and like turn that into effectively a Django database.
And I've heard that there's a branch working on indexes, which will like sort of complete the
performance side of things.
Ooh, that would be really fun.
Yeah, no, no pressure. No pressure. It's going to be released tomorrow, I heard.
I'm just kidding. It's not going to be released tomorrow.
It's a long night for Eric.
You're shaking his head.
Long flight home. I don't know where you're from.
All right, before we move on to the next one, let me just tell you about our sponsor,
which makes all of this happen. So this episode is brought to you by Datadog and Datadog. They're
really awesome. They let you track the performance and errors and requests, not just within your
Python app, but across all of your infrastructure. Like, so if you're doing like a Kubernetes thing
and you've got a Flask app and it's talking to Nginx and it's talking to PostgreSQL, you can like
tie all the performance of that entire system together, not just profiling your Python code,
which is pretty awesome. So check them out at pythonbytes.fm/Datadog. Get a cool free
t-shirt. You get to try it out. It's awesome. Okay. So the next item, that's Dan.
Oh, sweet. Yeah. So a quick update here. The CMU Carnegie Mellon University launched a undergrad
degree in artificial intelligence. And apparently that is the first AI degree offered by a US
university. And when Mike told me about it, I was really surprised because I thought, well,
AI has kind of been like a big buzzword for a while now. And why didn't anybody else come up
with a degree before that? But I guess it always takes a little while to do that. And I don't really
know what goes into that degree or kind of what, you know, how the curriculum really differs from,
let's say like your average computer science degree or like a data science curriculum. But I just felt it
was an interesting development. Yeah. I'm sure they use a lot of Python.
Computer science forever. Well, first it was like electrical engineering, but I work on computers
on the software side. And like eventually that got a real degree, like computer science.
And then we have like software engineering. But now I think this is a big landmark, like the first
artificial intelligence, like a bachelor of artificial intelligence. Like think of that. That's crazy.
And one of the things the dean said is, you know, of course we'll do CS stuff, but we're also
going to focus on things like computer vision, language processing, huge databases, and how to help
like humans make better decisions automatically. It's pretty cool.
So I'm waiting for the day where we have an AI, get a bachelor's degree in AI, just so we can call
it a day and we're done. Or an AI teaching the bachelor's degree in AI.
Yeah. Even better. That'd be so sweet.
My professor's a jerk.
It's written in Fortran.
Yeah. So do you use Python at all?
I'm guessing you're learning Python.
It must be, right?
It's all Java. No, I don't know. It's got to be Python, right?
All right. So you all might know that maybe I've been kind of on a rant about async and await
and async is programming lately. And the next one, have you also heard that I've talked about
GUIs? Like I've mentioned this twice, I think, like that Python should have better GUIs.
Well, this next one is kind of like these things come together, which is awesome.
So Florian sent this over to me and it's PySide 2 and Qt for Python, the Qt framework. That has an event
loop that, you know, a button gets clicked or a timer runs or something like that. Well, somebody
built some layer that you can plug that into async and await. So you can have like async def button
click handler that integrates with your other async operations happening on your GUI there. It's pretty
awesome. There's some examples on how you do it. It's super simple. I linked to one about downloading
some stuff and whatnot. So yeah, if you're doing anything with Qt and you do anything with async,
then check this out. That's really, really a nice one.
So that one, usually like I know, I haven't done Qt in a while, but GTK uses kind of an object oriented
event loop there, right? Where it's classes. So it's taking a class-based syntax and allowing you to use
the new asyncio syntax, right? I think it's mixing the GUI event loop and the asyncio event
loop together because otherwise I think they would run independently. I think you basically can't have
those run on the same thread or something to that effect, right? Like the async event loop would block
the GUI loop or something to that effect. Cool. All right. So the next item we've got on the list here,
you know, guys, we're at Python 3.7 now. 3.8 is coming out pretty soon. So we're kind of running out of
like minor number space. I guess we could always create more, but whatever. That's a good intro.
People have started thinking about, you know, what's going to happen with Python 4.0? Like what
would be some cool features that we would really want to see? And so our good buddy, Anthony Shaw,
wrote a really interesting blog post about four things he wants to see in Python 4.0. And it's pretty
short read, but there's some interesting ideas in here. So we're just going to go over those points
here. And so number one is he would love to see just in time compilation as a first class feature.
So right now, you know, you've got some alternative Python interpreters like the Piston project,
or PyPI, I guess is like the most well known that actually feature just in time compilation. And it
could bring a huge speed up compared to like the plain like bytecode interpreter setup that CPython uses.
And so I guess the idea would be, is there some way to bring this into core Python? And apparently,
there is and we already have this in some way, or at least we have the infrastructure to be able to
plug in something like that.
That one would be really big because I know there are some companies that the reason they're able to
use Python for what they do is PyPI. The fact that it really speeds up with that just in time
compilation.
Yeah, yeah. I think it's a big one, right? Like performance. I think the more people use Python,
the more relevant the whole performance story becomes for people because then it's like,
yeah, you know, it has a huge impact if you have a small improvement.
Yeah, absolutely. There's tons of attempts to solve this problem. Like there's Rust Python and
there's Grumpy and there's all these different attempts on solving. And PyPI, like Trey said,
is really awesome. But it has this limitation where like when it, it kind of, when it gets to the C
interrupt stuff, it can like slow down or it doesn't necessarily work with all of them. So it kind of
falls back then. And with Pigeon and the work that Brett Cannon and those guys did,
it's really awesome because that's a plugin to the normal CPython. So it wouldn't be like an
alternative thing. So yeah, I would love to see this as well. It'd be great.
Yeah. Great idea. All right. Item number two is on the wishlist is a stable 0.0, like a stable 4.0
release.
Is that a lot to ask?
I don't know, man. You tell me.
I feel like this one, this was because of 3.0 history, right? That, you know,
there were lots of breaking changes. The initial was a kind of a rewrite of the language from my
understanding, although I'm not a core developer. I don't know.
The central point of that in the blog post here is that, well, you only have one chance to make a
first impression really. And so maybe Python 3 kind of bumbled its way into life or whatever. I think
now we're super happy that we have it, but I don't actually really remember the 0 release or the 0.1
release.
I don't know if anyone does.
Yeah. It's like, let's not talk about that. Let's just move on.
No, I'm sure it was great. All right. Static type hinting. I think that's a really good idea too.
You know, we've got my Pi, but it's optional right now. And it would be kind of
interesting to see that integrated into CPython or the core language if this is really the path
forward. And I'm not actually sure what the roadmap says there.
Yeah. I don't know either. It's pretty interesting. I think static typing is super valuable.
I think having it mean something in the language, that would change the Zen of Python, wouldn't it?
I mean, because it's so much about the duck typing and I don't have to worry about it. It's like,
whoa, compilation error. We expected a I runnable of whatever, right? Multiple templated thing. And
yeah, I don't know. I don't know about that.
Really changed the face of the language, I think.
Yeah. I like what he's recommending here. I'm not so sure about the required static type
hinting. Maybe like a mode to run it where you can check it. I mean, we have data classes,
which do some validation in a sense.
You're wrong, Anthony. No, like we're just some really interesting thoughts about this because,
you know, what should go into it? Because obviously it's a big release, right? If you're talking about
Python 4.0, it better be a really, really noticeable improvement. Otherwise, people are going to go,
like, oh, which would be nice too. I mean, if it's just a 4.0 release and everybody's kind of,
there's no upgrade hump like we had from 2 to 3, that's kind of nice too.
Right. Well, and he does mention the idea of static duck typing, putting an iterator in there as
opposed to a generator specific type of thing. But I don't know how you would really make that
a truly generic thing.
Yeah. Well, as long as we don't end up with a Python 3 death clock,
we'll be in a pretty good place.
Nice. Okay. So the next item we have here is a GPU story for multiprocessing. So I guess the idea is
that a lot of workloads that people use Python for these days are actually running on GPUs. You know,
a lot of the, I guess, like the deep learning stuff's all running on GPUs these days. And so
wouldn't it be cool if Python 4.0 actually had some facilities to run stuff on the GPU
for like parallel computations and had it built into the language? Wouldn't that be sweet? It's an
interesting idea for sure.
Maybe like another decorator, like an at GPU.
And we're done. Add some tie pins. Yeah. And the last item here on this really interesting list is
number five is more community contributions. And I think Anthony is saying that he's already
seen, you know, like a lot more involvement from the larger community. And now that CPython is
hosted on GitHub and there's less barriers for people to contribute, I guess, to the code. And
just seeing more growth in that and seeing more people involved in the actual development of
CPython would be pretty sweet. And I totally agree. What do you think, Eric?
Well, a lot of these features, I haven't been coding long enough to have a strong opinion about
one way or the other. But I think to me, obviously, you know, optimizing for hardware and who would say
no to that. But to me, the 4.0 story would be big in terms of this would be the first major release without
having a BDFL. And how we I guess it will be we'll figure it out by then how, you know, 3.8 came about and all the
peps. But this will be a major release where it's determined, I guess, by the committee. So it would be kind of
interesting and just see how that transition going and hopefully for the long term and 5.0, 6.0.
I feel like even outside of the core developing team, Python naturally has had more community involvement
over the years. And it'd be nice to see that with a 4.0 because I mean, even this podcast, like, you know, you
mentioned under PyPackages recently. And that's something that that's not a PEP that's actually ready.
That's something it may or may not make it into Python. That's a discussion that normally happens
not behind closed doors, but in an open space that no one looks in, which is the core developer
mailing list, whereas it's on a podcast now.
Some random people in Portland dug it up and talked about it on the internet and all the dirt on your
Python.
Yeah. So that's it for all of our main items. Just a couple of quick extra ones for me. One,
I did an async webcast, which is available. So if you want like one hour review of what async and
await means and why I think now is the time for async and Python and you don't have to switch to
go. It's already awesome. Like just use it. And so you can check that out. I'll link to that in
show notes. And then if you happen to be somewhere near Tel Aviv or Israel, at least the first week of
June, they're having PyCon Israel, which is pretty awesome. And call for proposals is open just a
couple of days ago. So yeah, that's, those are my extra items. And you guys got anything else?
Yeah. Quick announcement. We're working on a new book for real Python and we're going to release
through real Python. It's called the Python basics book. So it's like a beginner's book for people who
want to get into Python in the first place. And Mike actually wrote the foreword for it. And it's great,
but it also kind of duplicates what we had said in the intro. So that means we've got to rip out a
bunch of stuff and then use his foreword as a new intro because it's so much better than what we had.
Thank you, Mike.
You're welcome.
Shameless block for the book.
Thanks for making more work. So the only thing I have to share is that, you know, some things in
my world, I'm, I'm, I have a goal for myself to write more because writing blog posts takes me so
much time. And so that's, that's something that I'm, I'm just announcing publicly here only so that I
will commit to it over the next quarter or so. And there's some kind of big things that folks in my
mailing list know with Python more. So it's going to be coming up soon.
Yeah. Sounds great. So I guess we got to close this out with a joke. So we got a whole list of
jokes here and I'll just grab two for you guys and, you know, let you all see what you think here.
So why did the angry function exceed its call stack size? It got into an argument with itself.
Oh no, oh no. There's more.
But wait, why did the developer ground their child? As in you can't go out, you're in trouble,
you stay home for the week. They weren't telling the truth. And with that, I think we're going to
close it out because that's what are we going to do with that? All right. So Trey, Dan, Eric,
thank you all for being here and everybody. Thank you so much for coming.
Podcasts was great. Brian, we miss you and see y'all later.
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.