Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 224, recorded March 10th, 2021. I'm Michael Kennedy. And I'm Brian Okken. And I'm Calvin Hendryx-Parker. Hey, we have a special guest, Calvin. Welcome to the show. Hey, thanks for having me. Yeah, it's fantastic to have you here. Always great to have a fresh face. I believe it's been about a year since you were on the show previously. Is that right?
I think almost exactly a year, yes. Yeah, YouTube reminded me that it was one of the first videos of this whole Python Bytes that we put up there. Before we were live streaming, we'd record it and then put it up. That was so last year. I know. I mean, Python Bytes, you guys have really upped your game. I'm super proud of y'all. Yeah, it's so 2020. Yeah, yeah, yeah. We got our broadcast studio working right here in Portland, Oregon. Super, super nice. Speaking of nice, I want to do a follow-up.
You know, what's nice, Brian, is so often our guests, they send us all these items. And, you know, we'll mention something and we'll think this is like the first time I've heard of this. And they're like, and here's the 10 other amazing things that you've never heard of. Yes. And so this is a little bit of a follow-up along that. Before actually, I realized before I get into that though, Calvin, maybe you want to just do a quick, who are you? It has been a year. It has been a year.
Everyone's going to remember who you are. Sure, sure. I'm Calvin Hundix Parker. I'm co-founder and CTO of Six Feet Up. And I'm also the co-founder of the IndiePy group here in Indianapolis, the Python user group. And we are also the organizers of the Python web conference, which I'll talk about later. So that's kind of a quick rundown of me. You're that company that hands out Python jersey shirts. Oh, yeah. We do some killer swag. Yeah, yeah, for sure. That's a cool conference.
Be fun to talk about that in a little bit. So the first thing, though, that I do want to talk about over here is AWS Simple. We talked about Boto-type definitions, I think it was. And then someone mentioned that Boto-type definitions has kind of been deprecated, ignored, and so on. And so they pointed us at this mypy live generated version that we talked about last week. And also, we got a message from James Abel, who said, hey, I built this cool library called AWS Simple.
And I got it all flowed together to get all the S's to fit in there, AWS Simple. And the idea is that it's a typed wrapper around the AWS API. And if you recall, I kind of was harsh on the Boto 3 API. And I can buy that because there's just zero discoverability on how it works. There's like inconsistencies on how you pass parameters. Sometimes you pass them by name. Sometimes you pass them as dictionaries with names in the dictionary. Just a lot of stuff going on there.
And it's really not discoverable. And so this one also is one of those libraries that's meant to help with that. So it's a simple API for basic services like S3, DynamoDB, their hosted NoSQL database, simple notification service, simple queuing service. I don't know if you guys have been to AWS lately, but you go to your console and it says, here's the two things you've recently visited. See the rest. And it like, it scrolls. There's a lot.
So this is clearly not everything, but it is some common ones, especially around S3, I think. And it's also maybe the kernel of other things, right? People often ask me, hey, what project could I contribute to? Well, if you're like, I would really love to have simple email service integrated with this. Like, well, you know, it probably is easy to add like one more service.
So some of the features include a nice object oriented API on top of Boto 3 with proper type definitions and classes and static things that all the static type checkers and the editors all know about and love. You can write a really simple, like one liners to do S3, read, write, deletes. It has automatic retry for S3. It has caching. So for example, it will, when you get a file or upload a file, it will hash that result.
And basically if you try to get it again, it'll say, let me check the E tag. That's the way web browsers and servers exchange. Like here's the sort of history or the version of the file. And it'll check, has this thing changed or not? And so it'll not download the S3 file if it hasn't changed. And you ask, it'll just use like the last version that got since it touched it. Things like that. Some DynamoDB full table scans, secondary indexes and pagination.
So there's some simple examples like my S3 access. And then maybe if you could do DynamoDB, create a DynamoDB access and just put an item or get an item. And off it goes. Really, really simple. You know, as you would imagine something with a name like AWS Simple has. But, you know, it's just one more thing around AWS APIs that I think is pretty interesting. What do you guys think?
I kind of expected a bullet to bury in there saying AWS Simple is not simple because this is a massive undertaking to try and make something like this simple. Yeah, absolutely. I totally agree with that. I mean, it's pretty neat. Over in their documentation, they've got a little more examples and a quick start guide and how to use it and so on. But yeah, it's pretty easy. You just do like S3, create bucket, S3, write string to this key. Go on. It's quite easy.
So if you're struggling with the AWS APIs, this is the cool project. And again, I think it's pretty limited to just a couple of the services. So it's somewhere that if you've got your favorite service and you want something like this for it, you know, reach out, James, and add it. Yeah, and all of the services could be added. And then AWS Simple could be as complex as everything else. Exactly. Like I can barely install this thing anymore. It's really legit.
Yeah, they're trying to become the AWS APIs for humans, kind of like requests for HTTP, URLib. Yeah, maybe. I mean, Boto3 was kind of like that too, right? Well, again, the S3 APIs, they've changed names. They're inconsistent. It's really hard to like parse. Sometimes as a human, like the uploading process of like multi-part uploads. If you're not into the web, this could be really daunting. Sounds like this is a great way to enter this space and not have to learn all that stuff.
I can't just do this thing. I got to create a waiter and I got to wait on the thing and so on. Yeah, absolutely. Dean Langsom up there in the live stream said, it's amazing to me how many of the most accessed APIs in the world need third-party packages to make them useful. Yeah. I mean, if it weren't such a small little rinky-dink company, if they could hire a bunch of developers to work on this, like, oh, wait, no, it's Amazon. No, I totally agree with you, Dean. That's funny. All right.
Yeah. So AWS Simple, check it out if that appeals to you. Brian, what you got for us? Well, I was going to, how do we do this? Oh, yep. We both clicked. Sorry about that. It was a race car. So I learned something new the other day. And I learned something new about something old. So I've used coverage.py a lot over the past several years. And I've even covered it a lot on the Test and Code podcast a couple times. Covered it on the podcast. Yep. That's a meta joke.
Anyway, there's something I missed the whole time. So there's a source thing. So you can tell coverage where the source code is, where the source is for your, whatever you're covering. And hidden in here is the source can be, the source is either directories or packages. It's the or packages I never saw before. Oh, that's cool. So why this is significant, and apparently this has been here the whole time, and I just missed it, is there was a workaround.
So if I, if I'm testing, if I've got, if I'm developing a package and I want to test it as an installed package, I install it. And then I run the tests against the installed package. But how do I run coverage against that? And there was an old trick to, and it, I guess it still is works, is to use the paths option within coverage to say these two paths are identical.
So you could say the actual source code directory is identical to the site packages directory so that it, it, it kind of lines everything up and then it reports, even though it's measuring the coverage on the installed package, it reports it as if it was sitting in the source directory. And so I've been doing that in the past. And that still is a good idea so that the, the output is readable, but it isn't required.
You can just pass in the name of your package without the dot PI or anything, or if it's just a file, but just the name of the package and it just reports it. And yeah, anyway, I just figured that maybe some people out there have missed that also. It's very handy. Well, you might wonder like, why are you testing packages? I don't need the coverage of requests when I use it. I just know that I use it and we're all good. Well, if you're developing requests, you might want to come. Yes, exactly.
Or, you know, it may well be that you're building your application out of several packages that you control and you kind of want to keep them separate for reuse, but you might also want to know like how much am I interacting with that one, right? Oh, that's a cool use to say really what, how, how much am I interacting with the package? You could run coverage on that. Yeah. If it's zero, take it out of your requirements. That would be super nice. Yeah. This is really cool.
Yeah. Also, I guess when one of the reasons why that might be handy is if, if they change, drastically change an API, like go to a new dot, you know, like a three dot something to four dot something. What is the API change? And you could check to see if you're even using that API or that entry point. That might be good. Oh, that's interesting. Yeah. Yeah. That part was like a breaking change, but I don't care.
Yeah. Okay. Like I can really see the, there's a huge use case here though, for old code bases where the developers aren't there anymore and there's been dependencies brought in and you don't know exactly what's being used. So this is like super nice to be able to do that. Yeah. And of course, as a reminder, you can have as many of these as you want to. So if you, if you're wanting to measure several packages, you can add multiple source flags. And if you're using pytest-cov, it's the cov flag.
So you, which is identical. I'm not sure why they used cov and dash cov instead of dash source, but there you go. Interesting. Okay. Yeah. Yeah. Super cool. Super cool. So Calvin, I didn't know that you were an artist. I wish maybe more of a machine learning artist, but machine learning artists. This really interesting article came up on my like newsfeed last week, which was finding Mona Lisa in the game of life with Jax.
And so there's kind of three interesting things there, like Mona Lisa, game of life, and then Jax. The author was attempting to find if he could start with a starting set of points on a game of life. If you're not familiar with game of life, there's whole Wikipedia articles about that. But if you could basically seed an initial game of life and after so many generations have it show you a picture.
So he actually started with the Mona Lisa and kind of went through what it would take to go from, you know, a game of life running all the kinds of constraints that happen in that. But this seems like a really interesting machine learning problem. And that's cool. So it like our it randomly runs the game of life. But then the ML says, oh, that's starting to look like Mona Lisa. More of that. Well, it's more of that. I'm going to run a generation of game of life and then reset.
I'm going to invert some pixels again and go again until I can generate what is my target picture. And it took a lot of CPU cycles. He basically wrote a simple single threaded version of this in Python. And there's a there's Python notebooks included with the GitHub links in here. But it took days of CPU time for him to run the initial four generations to see if he could even make this be possible. And then kind of went with any machine learning project.
It's really important to understand like the preparation of your data before you kind of go dive in.
So what I also thought was interesting in here is he talks about the preparation of the data kind of down here, pre-processing, you know, using pill to understand how to generate that target first, give the game of life algorithms a chance of getting it correct, came into like, you know, really half tones would work better because there's some constraints around game of life that the whites can't be contiguous to contiguous because they'll they'll kill each other and ends up being all black.
And but at the end, the kind of goal of this was how fast can we now do it? Take the single threaded Python example, which took hours or days of CPU. Can we actually do it on a GPU? And so there's a JAX library, which is a machine learning library in Python that allows you to actually like super parallelize the problem. So if you can actually slice the problem up shows kind of example here in pictures, which is kind of nice for a person who doesn't do a lot of machine learning.
Yeah, they actually kind of show you what the process looks like and hyper parallelize this basically in 40. He went from days of CPU time down to 40 seconds to get through the first camera. What was the final time? 40 seconds. It was that. Yeah. Yeah, it was ridiculous. It's like so a thousand iterations. So the first one was for four generations took days. The next one where he did it with JAX was a thousand iterations took 40 seconds on a Google Colab GPU.
So JAX is basically a Python library. I've got a quick little quick start over here. Neat library that actually you kind of have to alter your brain to a little bit to how you code so that you can code in a way that can be hyper parallelized across all the GPUs. I mean, for people who aren't familiar with GPUs, which you may not be because good luck getting a GPU right now. They're unobtainium at this point.
But if you did have a GPU, you can take advantage of those, you know, how many cores are in some of these modern GPUs, like thousands in the new, like in video. Every time that I try to think about and try to conceptualize, like how fast and how much these things can do, I'm like, whatever that is, it's probably off by 10 or many, many more. Yeah. Factor of 10, just like ramp that up to beyond what you can think is reasonable. It's right.
You think of we've got a, you know, half a million polygons on the screen and we're going to draw that. Oh, we're actually going to do that 200 times a second. Right. So what's interesting is if you are doing some machine learning experimentations, learning a tool like JAX may actually help you speed up your iteration so you actually can get some useful results out of it. Because a lot of machine learning is kind of picking out what your algorithm based algorithm is going to be.
But you have to run it enough to know whether your algorithm is getting you the results you expect. So being able to run through those algorithms quicker with a tool like JAX, I think would be super beneficial. Yeah, absolutely. That's super neat. And I think the biggest takeaway here is JAX, actually. Yeah. That was. Yeah. The end goal was like, yeah, can we talk about JAX? Because that's a really cool library. Well, and a cool logo, by the way. Yeah. Yeah. Yeah. I love it.
The logo is super cool, actually. I like it. Yeah. But definitely. And I think they have support for Tensor processing units as well. So not only GPUs, but if you're doing like TensorFlow stuff, Tensor GPUs or Tensor processing units, so you can take advantage of those as well. Yeah. Okay. Super neat. Super neat. Super neat. I want to talk about something that's not as neat. Maybe it'll get you excited, but in the wrong way.
This one was sent over by my friend, Mark Little, fellow Portlander, and a follow-up related one sent over by Tony. So link into a couple of articles here. And recall, we talked about Google coming on as the visionary sponsor. One of their primary goals that they wanted was to improve the package security. You think about some of the things that have happened recently that are super scary. One, the Outlook catastrophe that 60,000 companies have been taken over.
And then the SolarWinds one as well. And I think they're somewhat related, even though they're not the same origin or the same type of hack. The SolarWinds one is one of these supply chain vulnerabilities and these breaches, right? It's one thing to say, I'm going to protect against somebody breaking into my website. I'm going to run the proper firewalls, low privileges, everything's patched, et cetera, et cetera. That might still not be enough, but that's like a good start.
But do you think about, well, next time you install the new version of package, whatever, what if it was influenced with some kind of negative package that had some vulnerability that then got into your servers and then went on? Like the supply chain story around all of these package management places is scary. I think that's not what happened to SolarWinds. They just had the password, SolarWinds123. That's a different type of problem. But it highlights- Those aren't interns. Exactly. Exactly.
But the problem that it might be untrustworthy to install all of our beautiful open source things. I don't know. It's very scary. Like, what do you guys think about this? It seemed like this went even a level deeper. There wasn't even scary to install the open source things. It was dangerous to install your own private package names if someone knew about them and had put them into a public repository with a newer version. Yeah. So let me read the titles here for people who are listening.
The Python package index nukes 3,653 malicious libraries uploaded soon after a security shortcoming is highlighted. And the other one is poison packages, supply chain risks, users hit Python community with 4,000 fake modules. And these are basically the same. I don't know if like one's rounding up or whatever, but- or one's counting multiple incidents. But the idea is there's this form of type squatting that's pretty sketchy.
So we've covered this before where if you have- maybe I want to use the audio library asteroid singular, but then somebody puts asteroids plural, that is a virus. And it could just as well have exactly the same code plus the virus. So it looks like it works. You wouldn't even know that it's not working, right? Yeah. And that's quite the problem. But here the highlight is what's it called? Like I think one thing was calling it evil twin. Another, this is a research by Alex Beerson.
And basically there's a lot of people who are using private package repositories, right? Like DevPy and things like that, Artifactory, where you have a local one. But if you ask for something public, you can just ask your local one and the local one will go out and ask the public one. So as you were hinting at Calvin, the problem is what if I just have like data layer or e-commerce or like some random thing that might be an internal package name?
Maybe if it's what I think the real problem was they were saying, if you don't secure your server right, you just post a higher version on the public one than on, on the local one. And it'll go, oh, well, there's a newer one over there. I better get that. And we'll just go grab the virus. I'm also surprised that folks aren't pinning the versions of their internal packages as well.
Because I would, this would satisfy solving that problem is if you had like we use pip-tools, pip compile to make sure we got hashes and versions for every dependent package. But yeah, if you didn't do that, you were absolutely susceptible to this. Yeah. So just people check this out. It's, it looks a little scary. I, you guys, you too tell me if you think I'm crazy. I'm getting to the point where I'm really freaked out about like these kinds of things.
And especially, you know, people send us stuff. They're like, oh, check this out. Here you go. Like I'm not pip installing those things locally and trying them. No way. Right. I'm going to install them in some isolated environment. One thing I've been thinking about doing is setting up my own DevPy server, which is exactly the problem sort of that we're talking about. So that doesn't necessarily solve it.
But what you can get with your DevPy server is you can get DevPy constrained, which will let you not blacklist stuff or exclude stuff, but you have to whitelist things. So you're like, all right, I'm going to try to install, set up this project. And when it tells me I need these things and they're failing, I'll make sure they're good. Make sure they're used a lot. I'll put them in the whitelist and then I'll be happy to just pip install versions, no versions, whatever. Right.
But, but sort of being more protective about this. I don't know. Maybe I'm just paranoid, but this stuff is, it's creeping me out. What do you guys think? I'm still just having it. Let me, I'm still sinking in. I don't, I'm not sure how I react to it. Yeah. My reaction is, I think there's still more infrastructure security wise that has to happen in the community. And there's, there's efforts to do signed packages or support in the latest version of pip for signed packages.
And there's also some good hygiene behaviors, but it's true. If you want to just try out a package and you just did pip install from a command line, you're typically not going to specify a specific version and you're going to get whatever just comes off of a pipe with it. Yeah. We've gone around and around about it internally as well. Talking about this because we want to make sure we're not susceptible to this kind of an attack.
And I think good practices like the pip-tools, you know, using that and having pin versions has pretty much given us a comfort level with we're pretty safe. I mean, no one's a hundred percent safe. That doesn't exist. But we're feeling pretty good because of the practices. Yeah. Yeah. I know that sounds good. I mean, there's only so much you can do, but layers, layers are good, right? Layers are good. Anyway, this, if you are running, I want to highlight this.
The ultimate problem highlighted here is that if you have a private PyPI server, that there were ways to typosquat on your internal names, not on the public name. And there's no way for the public stuff to go, well, you can't have that because it looks too close to this, right? It might not exist publicly. So just be really careful about the versions. Be really careful about like whitelisting things if you're doing your own private PyPI.
And it's important to also note, this is not a Python specific problem. So I think some folks may have blown out of proportion, but like other packaging distribution tooling all have some similar problems. Yeah. And I just saw a message on, he was on Twitter or somewhere. Yeah. This, I mean, obviously NPM has this problem, Ruby gems, all these places, NuGet, whatnot.
Somebody who was involved in like diagnosing and solving these problems was like, please don't go post another 4,000 packages to prove your point. Just, we are already aware. Just send us a message. You're causing a lot of work that is like distracting us from addressing this problem. So, you know, we don't need more examples. We need just maybe a notification. Yeah. I guess one of the other things is, is that it is typo squatting.
So we, in our organization, we try to minimize individuals having to type install anything really. They, we have, all of our projects have requirements files with pinned versions. So they're not going to type the name of anything. It's going to have to be in a requirements file first. Yeah. All right. Well, check out the articles. There's more details in, in both of them. Brian, what you got for us? Oh, my turn again. Okay. It is. It is. I wanted to talk about something new.
Adventure, text-based adventure games. Have you heard of these? I love, I used to play, I used to play Muds when I was quite younger. Oh, those were so fun. They were so magical, even though they were just text. So I actually never got into this. Um, but I, I, my, I had entered adventure games. What was it called? The dungeons of Daggerath, was a game that I had on the, TRS 80. And it was, it wasn't, text-based, but the, the graphics were just lines.
So it was, we'll go through a cave and, and stuff like that. But anyway, a little bit before that. So we're talking, in early seventies, so 75 to 77 was a game called adventure. Um, and then our colossal cave adventure. So you can play colossal cave adventure because Brandon Rhodes has Python adventure. And this is just awesome. I played this the other day. It's so well, I don't know if so fun, maybe like overselling it. Um, but it's kind of neat.
Um, it's a faithful port of the adventure game to Python three from the original 1977 Fortran code. Wow. And that was awesome. So if I get distracted, it's because I've actually pip installed this and I'm playing it right now. It's a, lets you explore colossal cave where others have found fortunes and treasure and gold, though. It is rumored that some who enter never seen from again, like maybe Calvin. Um, but one of the things that I loved is I played in both modes.
So you can, there's two modes you can play. You can, in a Python console, you can just kind of run it. Um, but you can also, you can also, you can, um, gonna show for the people watching kind of what it looks like. Um, you import adventure and then you say adventure.play and, it has, gives you instructions and you have to type things like East, West, get lamp, things like that. Oh, it's even like function call style. Well, it's function call style. If you do the import on the, the repl.
Um, if you, if you go through the, there's traditional mode. Okay. Got it. The traditional mode is you do Python dash M adventure. And then it's traditional mode. You say get lamp with a space between the get and the lamp. And that's how I played it. But the fun part about this, the traditional mode, it's a 1200 bod. So you have to wait for this to type its message to you. Um, you may have to explain that to some of our listeners. I don't know if I can. It's slow.
So it's sort of ticker tapes out the message to you and you're waiting for it. Wow. That's impressive. I used to be able to identify by sound, the speed of the connection I would get. I could tell you is at 9,600 is like 32, whatever, or is it 56 and whether the, and whether the error correcting kicked in or not. Yes, exactly. You hear it. But I don't think I even remember what that sounded like. That was some slow business. One of the things. Um, so, okay.
So a little bit tie into the, my own personal nerdiness. Um, I was curious how this related to Zork. So, Zork, I never played either. It was a little bit after adventure, but, there was a, TV show called Chuck, that I really liked. And one of the premises is this Chuck and his buddy used to play this game. And he met this other guy by both of them being Zork nerds. And they, they did their own port of Zork. And I'm like, is that a made up thing or real? And apparently it is real.
Zork was a follow on to adventure, from 77 to 79. Uh, so anyway, so I'm, I'm going to ask Brandon. So Brandon, can we get a port of Zork also for Python? That'd be great. Then we'll get our little IOT devices that we can play these adventure games on like a little Nintendo switch, but super old school, like low baud rate. That'd be great. Oh, I want this totally for my Oculus quest so I can do a Texas venture in full VR.
Well, the, the, the 1200 baud, the baud slow down thing is, is entertaining for about 10 seconds. And then I'm like, can I get faster now? So yeah, you had the true retro though. That was cool. Very nice. That's cool. Awesome. All right. Uh, so for those of you who are Django nuts in the audience, there is a new long-term support release coming up for Django three tattoo. That's a big deal because long-term support ones are the ones you want. Oh my gosh.
And Django's community is really good about that long-term support. I mean, and they have a very good security policy and release revision policy. It's very clear, very, very well documented. So the next one coming up, which is going to be released here in April is going to be 3.2. Uh, this post specifically that I linked to is actually an overview of some highlights of interesting features that you may not have noticed.
You can go read the main Django three, two release page and see kind of the overall new features are going to be coming in. But this post specifically covered some things that I thought were also interesting. Uh, a lot of them are performance and kind of, protections against, you know, hurting yourself when you're programming. So things like covering indexes for Postgres. So you can actually, avoid full table scans and do index scans and Postgres, for kind of indexes are magic.
Yeah. And then, and so this is enabling even more of the nice magic of those indexes inside of Django. Yeah. I think it's really cool that it's the LTS release, three, two is coming out. I think there's also some async and await stuff in here coming along, which is pretty exciting. Uh, I know that one of the areas that's still pending to get really the async and await stuff properly, like full stack is the ORM stuff. ORM. Yeah. So three, two was supposed to be.
If you wait on the database, that's the thing you need async for more than anything else. Yeah. And that's kind of one of the notable missing items for me in 3.2. I mean, the team is doing an amazing job of implementing all the async features for Django. I mean, 3.0, 3.1, you started off with the routing. Then you got the views.
3.2 was supposed to be, I think the ORM included, but maybe just due to the fact that we are talking about a long-term support release that that was maybe too risky of a feature to get included here. But look for that coming soon, like in 3.3 or 3.4 for the ORM, which will be a big, big deal. Uh, the other things that are included in this 3.2 release, again, kind of focusing on security and safety and performance, time zones.
You know, it's probably one of the two hardest things in programming is the time zones and character encoding and off by one, errors. Uh, so there are going to be some trunk date stuff in here that actually, you know, helps you, assign a default time zone in case you didn't put one. Uh, there's going to be some cool stuff for people who like unstructured data, the JSON object DB functions.
So you'll actually be able to assign some DB functions that can produce, you know, JSON mapping type objects or key value pairs where you pass in database functions to operate on it. Uh, there's going to be some cool stuff around signals. Uh, there's a sin robust, which didn't, log exceptions, but now will. So you don't have to, log themes for the admin section. Is that coming to this one? I know that's something they're working on.
I don't know on the themes, but I know for the admin section, and this is a common thing I've done in the admin is sometimes you want to put computed fields into the admin pages for like your, your objects. Uh, there's going to be a new, what is it? There's a new value, not a value expression of the display decorator. So you can actually make creating admin feels a lot cleaner. The, the kind of syntax for it previously was just a little convoluted if you were not used to it.
And so as a new person, you may not have figured out how to do it very easily. So there's a new decorator that actually makes that super, super easy to do. Uh, there's some other performance things around the database with query sets, with aliases. So you can actually create like reusable aliases for things that you're selecting against. So you can use them as like filters or like kind of combined statements.
So it doesn't do two sub queries instead of, it'll do just one, a lot, a lot of cool performance. And again, these were kind of the less notable, but really kind of important features that are coming into a Django three, two. Oh, yeah. And like, so you can, you can see all the other stuff. There's, there's a zillion things coming up in three, two. These are just some of the small ones, but there's some of the important ones. That's cool. Yeah. When, when is this coming out? Uh, April.
So we should see it next month. Uh, very soon. Yeah. Awesome. That's great. Uh, if you're into Django, that sounds really like a big deal. It is. It is. It is. All right. Um, Brian, anything else that you'd like to throw out? Those are all of our items. Anything extra? No, I don't have anything extra this week. How about you? Oh, I've got a couple of things I would like to touch on. I heard some amazing stuff. I heard that Python open source stuff is on Mars.
Yeah. But what I want to say is Python is on Mars question mark, because what I found is if you go look at, there's this thing called F prime that NASA open sourced. Awesome. And if you go over here and you look at it, this is the flight control thing that is for embedded them flying, including that little helicopter. Awesome. Uh, it has 16% Python and 44% C++. But if you look at the Python bits, so much of it seems to be around the, like the training pipeline.
So my theory is I didn't see any stuff in like the real, like running regular bits. I'm thinking maybe it's trained with Python locally. And then the models are put on the helicopter and flown with C++. If, if somebody knows for sure that Python is on Mars, you know, but details, let me know. That'd be awesome. I still think it's cool that Python's involved here. Yeah. All right. So that's one quick one. Number two, just released a new course. And this one is a little different.
So it's a full web apps with FastAPI. And FastAPI is awesome for building APIs, but there's like three or four features of FastAPI. When put together in the right combination, make it sort of a equivalent framework to what you would get with flask. So if you're thinking, I would love to use this beautiful API with really nice decorators, with really nice async support with Pydantic and all those awesome things that it has. But I want to build a web app with it.
Well, we launched a course on that. People can check that out. That's really awesome. Like basically, I've built some APIs with FastAPI and I need like four or five more pages to round out the app. Do I have to have a Django plus FastAPI multi deploy thing? Like, no, actually. And this is all about how do you do that? So people can check that out. That's fun. Super excited about that. That's cool.
Yeah. Yeah. Thanks. Over on Talk Python, I'm giving away five tickets to PyCon, one a week for five weeks. So if people want to win a free ticket to PyCon, this year it's virtual. So you can attend from anywhere. There's not the challenge of, well, I got the ticket, but I need the thousand dollars for the hotel, right? Like that's not a problem this year. So I think it's really cool. I decided to run a contest on that. The link is in the show notes.
We got a couple of questions saying, hey, we heard about this live stream because we're listening to the podcast. How do we get to this live stream? This is awesome. I think it's fun, Brian. I'm enjoying doing the live stream. What do you think? Yeah. It makes it a lot more fun. Yeah. We get, we get our, our listeners who come in and give us comments and all this stuff is great. So if you just go to pythonbytes.fm/YouTube right at the top, there'll be upcoming live streams.
And you can say, click the button to remind me of it and so on. So that's how you do that. Last thing I was on, I got a chance to talk to the medical community and the medical research community around Python over on this podcast called the Finding Genius Podcast. And it was just a lot of fun to speak about the advantages of Python for like medical researchers and folks like that. So I'll link to that podcast as well. All right. Yeah. Calvin, anything else you want to throw out? I know you.
I do. I wore your, I wore my shirt. I know you were fully outfitted. So I've actually got two things. One, before I get to Python web conference, the DjangoCon Europe 2021 call for papers is open until April 1st. So if you're interested in talking at DjangoCon Europe, it'll be a pretty worldwide conference. It was last year. It was a lot of fun. We actually did it on the same platform as we did the Python web conference, which is the other thing I wanted to mention in the extras.
So Python web conf 2021 is coming up in about, well, it'll be a week or so after you probably hear this. March 22nd through the 26th. We've got an awesome lineup this year again, even better than last year. Michael's obviously back and be speaking at the conference. We've got about 60 speakers, almost 20% women. There's 43 new speakers this year. It's like five. Yeah, it's like four or five days or something. It's a big conference. Yeah, it's five days, but we're doing half days.
So you don't have to consume your whole day with being in a virtual conference because we understand that that is just hard. And I think we're all adjusting to what virtual conferences really kind of should be. So this is a new experiment, which got four tracks. There's app dev, pi data. It's an official pi data track. There's a cloud track and a culture track. So if there's nothing you're interested in, I would be hard pressed to believe that.
There are tickets for $1.99 for professional, $1.99 for student. And we do have our grant program back again this year. So we are offering up grants for those who, you know, we want anybody who wants to truly attend to be able to, no matter what the financial piece may be. So check out the grant program for everyone who buys tickets. We offer up grants for those who can't afford tickets. And I'm really excited about that. You can check that out at pythonwebconf.com.
Yeah, it's gonna be a ton of fun. It was a lot of fun last year. We've got a bunch of social events planned and some really awesome sponsors. And I'm just super excited about being able to produce something like this for the Python community. I feel like the web is an area that doesn't always get the attention it should in some other conferences. And we're hopefully fulfilling that. Yeah, super cool. It was a good conference last year. So I'm looking forward to being part of this year.
Yeah. Yeah. Brian and I were just on a virtual conference at PyCascades, which was a lot of cool, cool fun. We were on that panel about podcasting. Yeah, it was great. You all might know a thing or two about that. We've done it once or twice. I'm not sure I would laugh at it, but maybe a joke. We could laugh at a joke. What do you guys think? Yeah. Yeah. All right. So I know we got like two rounds of jokes, but let's do another round of these comments. I'm already laughing. I know.
They're so good. So I'll do the first one. Brian can do the next one. Calvin can do the next one. We'll just kind of, we got five or six, something like that. So it's important to comment your code. There's this code. I believe it's Java and it is part of a class. It says private logger, capital L class logger, variable name logger equals logger class factory method dot get logger. So private logger logger equals logger dot get logger. What does the comment say? Logger. Quote. Yeah. Just logger.
This is a logger. Fantastic. You passed your code review. Yes. I guess you have comments. Yeah. All right. Brian, what's the next one? Next one looks like C++ comments, but I'm at this block that says this is black magic from some stack overflow link. Don't play with magic. It can bite. All right. All right. Calvin. What do we got next? Well, this one obviously is a Python comment in the code. It says for the sins I am about to commit. May Guido Von Razum forgive me. Yes. I love it.
Which I would be hard pressed to know what they're getting ready to commit. if they read the Zen of Python, they really should know the guidance already. Yeah. Yeah. Yeah. Maybe they put a semicolon in there. I don't know. All right. The next one is remove this if you want to be fired. Remove the comment or the code below it. We don't know. Yeah. We don't know. We don't know. Next is a try accept block or catching exception with just a comment. And it says, Houston, we have a problem.
There's no code there, though. So you're just, yes, we do have a problem. You're just catching a raw exception. Don't do that. Exactly. Exactly. All right. What's the last one? All right. The last one here is a definition of int get random number. And the body of the function is return four. And the comment says chosen by fair dice roll guaranteed to be random. If he wants. Was this a real code someplace? I mean, come on. Yeah. Oh, there's all sorts of good ones here. Yeah. They're beautiful.
One of them that's not on the list is the comment is just, I need to find a better job. All right. One more. Who put this one in here? I threw that in there. Tell us about this one. I'm kind of a card card nut. So if you if you kind of exactly like hover over just the first half of the picture, you see a guy in a Ferrari like waving and says, yeah, maybe rolling in the Ferrari. There's using Linux and then dot, dot, dot in Windows with WSL.
And if you scroll down, you see that the Ferrari is actually on a tow truck flatbed being driven someplace. And the guy's in it. Yeah. Like he's driving the train. He's cool. Very cool. Very cool. That's funny. I'm glad ZDax that you guys like the jokes out there and Dean as well. Yeah. And just I mean, I commented in the in the chat that you can increase your odds at winning the pike on tickets by laughing at the jokes. Yeah, absolutely. We'll put you in there twice if you laugh.
Yeah. For sure. That's how it works. Like the dad jokes of programming here. Oh, yeah. Of course. Yeah. We're all dead. That's like half our show. That's how we all qualify. For sure. For sure. All right. Well, Brian, thanks for being here as always. And Calvin, thanks for joining us. My pleasure. I really enjoyed it. Yeah. Good luck on your conference and catch you next time.