Python Bytes - #344 AMA: Ask Us Anything

Episode Date: July 18, 2023

See the full show notes for this episode on the website at pythonbytes.fm/344

Hello and welcome to Python Bites, where we deliver Python news and headlines directly to your earbuds. This is episode 344, recorded July 18th, 2023. I'm Michael Kennedy. And I'm Brian Ocken. And this episode is brought to you by us. Check out our courses, books, things like that. The links are in the show notes. We've got many of them. And if you want to be part of the live show, we live stream about the same time, usually 11 a.m. Pacific time. Not always, you know, especially around vacation time. But that's typically what we do on YouTube.

So if you hear people, we refer to them as being in the audience. That's because they were here for the live stream recording. You can find that at pythonbytes.fm slash live. Brian, what a special episode. Yeah, this is going to be fun, I think. It's almost like we're being interviewed, but by people who are not actually here. Yeah, so if people weren't aware, we sent out a form for people to fill out, like a Google form a few weeks ago.

And many people submitted questions. So we're going to go through some of those questions today. We are. And like I said, the opening people who are in the live audience, put out your questions and we'll see if we can intersperse them as well, because we really do appreciate having people here. With that said, you know, let's let's go through the list. We had a bunch of people fill out a Google form and give us one or more questions.

We'll have to deal with the second question logistics as we go, we'll figure that out. But I'll just kick it off. I kind of ordered these a little bit, like I think a little more relevant to the general audience and to the format of an AMA or is it an AUA, ask us anything, whatever. A little bit, I tailored them a little bit in that order, but not super.

So the first one comes from a frequent participant and friend of the show, Kim Van Wick. Question is, Python Bytes is more focused on new events than either of your personal podcasts, such as TalkPython, Python Friends, Test2Code, those things. Does this affect your listeners' behavior? For example, do most people download Python Bytes within a day or two versus longer? And for that matter, I'm just really assuming your personal podcasts don't have the bulk of the downloads on the day of release, which is an assumption we can test. Brian, kick us off with the answer to this one. Well, so I actually am not I don't look at the Python bytes statistics too often.

And I also I'm not sure about the the right away versus later. I'm guessing it's right away so i do have um i pulled up a graphic from uh from the stats for testing code and testing code is uh yeah a lot of a lot of listens later on um but the first couple days so these are i also this is also the first couple days is hard to tell because of when time zones hit so um when i if like if i release at 11 o'clock at night that'll count as the day one you know and but most of the downloads are the next day anyway things like that so the first couple days it's most but if you see i'm just just showing the last 15 episodes. Only like, you know, so in total, 3,000 to 5,000 downloads for the first couple days.

Testing code normally gets 6,000 to 10,000. So yeah, the bulk is in the first couple of days, but a lot of stuff tapers off too. I think that's probably true for Python bytes and testing code. the bulk is in the first couple of days but it a lot of a lot of stuff tapers off too i think that's probably true for python bytes and testing code um or and uh talk python statistics for podcasts are so interesting like they're they can get compared to things like youtube views and stuff but i feel maybe maybe i'm wrong but i feel like people have a deeper connection a deeper investment in podcasts you know there's not like screaming thumbnails that'll get them to watch for 10 seconds and then skip to the next thing. There's not a lot of force always trying to go like, I know you're watching this, but could

you stop watching that and go watch five other things? Like, you know, like the YouTube algorithm seems to do often. And so I do think those numbers are more impactful. That said, there's a little bit of a challenge just technically to know these things. So I agree. I would say with Python Bytes, we get probably, oh boy, I gotta go to the bottom here of my list. We get about two thirds of the downloads on average in the first week. But that just means people have their podcast players subscribed to our show rather than they happen upon it and listen to it right because yeah as soon as it publishes they they just the i mean they literally swarm the site the cdn goes to you know gigabit levels high gigabit levels of bandwidth in the

first hour and then it just drops because they get put onto your player. But as it should be, those players don't send tons of information and analytics back to us, right? They don't say, well, we downloaded it, but they didn't watch it for three weeks or listen to it for three weeks. So it's hard to read into those. That said, I would assume that people treat this show with a little bit more newsworthy, better stay on top of it, and they probably cherry pick our other shows.

Like, that topic's interesting. It's interesting for some people, but not for me. So I'm skipping that, right? Like I feel like there's probably that behavior. I encourage everyone to listen right away. I love that people listen to the show and that they, they make it part of their lives. It's super meaningful and it's an honor, but I also understand, you know, we're not the only thing in people's lives. And so I suspect that Kim's intuition is true, but there's a bit of a shield of like, it gets on their device and then they get to it eventually. Yeah. Yeah. Okay. Well, so the next question comes from us from BL. And this is an interesting one. So the question really is, I'll try not to summarize too much. I might do a little bit.

Being a jack of all trades, I've decided to narrow in my programming and focus my work on Python. Despite the popularity of Go and capabilities of Rust and C, Python fits my brain and I love it. I love the community. We do too.

Crazy. Am I crazy to remove non- remove non Python languages from my resume and LinkedIn? Um, is it possible I'll maintain systems, you know, 20 years in the future, like COBOL and such. So basically if I only really want to work on Python, should I remove other languages from LinkedIn and your resume? Um, do you have thoughts on that, Michael? Yes. And I have a fork in the road type of situation. Look, if you're trying to get a job in tech and programming and you don't currently have one or you're incredibly unhappy with the one you have and you're just like, I got to keep grinding this out until I get something, I think more routes in different directions might lead to something, right? And that's probably fair.

That said, if you have a stable job and you're not urgently trying to replace your work, I personally would only, excuse me, I would only put out, I would only feature things that I want to work in because I've at one point for a very brief time did VB6. If somebody approaches me and said, Michael, we got a VB6 job for you.

Like, no, I don't want it. You're going to have to come with seven figures of numbers to get me to go do VB6. Maybe, maybe divide that by two, but there's like a good number. You're going to have an unreasonably high amount. You're gonna have to pay me to do something that I don't want to do when I'm already happily doing something I do want to do. Right. And so if I was in that situation where I wasn't urgent, I would, I would highlight as much as possible what I really, really want to do. And if you really want to work in Python, you know,

instead of letting it get lost in a list of 10 things, oh, he knows Go. Oh, he also does some Python. Maybe people are not looking for a jack of all trades. They have a role and they want it filled. They're looking for a Python developer that knows Django and possibly some HTMX, or they're looking for a Go developer that's great at concurrency. They're not looking for a person that does both probably most of the time, right? And so you're probably not doing yourself a favor advertising like all these options if really what you're trying to get is just the one. So I would advertise and really make it look more like I have a better skill set in the one area I really

want to be than trying to play in all of the areas. That's my personal thought. Yeah. I used to be of the opinion of take everything off your resume that you don't want to work on. But I was talking this over, I do a lot of hiring. I was talking this over with another manager, a higher up manager, and he said that his preference is highlight the ones you want to work on. That's great.

But list the other technologies you've been in that you just don't do a huge list, but a large enough list to just show that you have learned new technologies over time. Because that's one of the things we want to know, that you aren't like, I know Python, but I don't know anything else. It will help you.

Like, I have no idea what a pointer is. And please don't show me a void star star. The one catch, though, is if you're not willing to talk about it during an interview, take it off your resume. You can leave it on LinkedIn if you want to like help catch, you know, catch bites with LinkedIn, but on your resume,

if it's on your resume, it's fair game to ask about. So that, that three months that I worked on C sharp system, I'm not going to put it on my resume because that's that would be my answer. If somebody said, tell me about your experience with C sharp, I'd say I've used it for three months. And that would be weird to list that as a skill set if I only did it for a little while. But that's that's my opinion. Highlight what you want to work on. But don't

take everything off. But then the extreme is I've seen people with like 16 languages on their resume and that's like ridiculous. You're not an expert at 16 languages. So, well, there's a difference between I spent a year and a half doing this versus I took an online course on it, but I didn't actually do anything with it. Right. I think, I think those are different. And Nick does point out that on the audience, it seems like the ability to learn and work in more than one language is itself a plus. And I do agree with that. But I think it's highlighting experience, but really point out, like you say, that's a good way to put it, Brian, is focus on like I want to work on X.

Yeah. Here's why I should be doing that. Yeah. I did Pascal in college, but I've never put it on a resume. Yeah. I did Fortran. Same. I did it against my will.

I don't want to talk about it anymore. Let's talk about the next question. Okay. So this one comes from Doug Farrell. He just had his book come out. A well-grounded Python developer, I believe. Excellent stuff. So congrats on that, Doug.

And he's wondered about the GIL and how many other languages resolve or handle things the GIL handles for python so i let me read into this like will we have a gil less python soon i don't know actually i you know sam gross's work and all the stuff happening around cinder and facebook it's very very exciting that's one side side two is there was a near mutiny in the community because we changed the way that bytes are interpreted. That was the two to three. Yep. Yes. And there was hardly anything else. And I can tell you that the change from removing the gill and the effects, and a lot of those

reasons were the effects it had on dependent libraries. And people are like, well, this is cool, but I can't use the new one because I work on library XYZ that hasn't bothered to upgrade yet. So I'm stuck kind of because of the ecosystem. I have this kind of golden handcuff to the past in a sense. And we have the same problem. On the other side, again, piling up the little rocks on the different sides of the weights here to measure. We have meta offering. If the PEP is accepted, 703, I believe it is.

If it's accepted, they will fund three man years of experienced CPython developers to not just solve the problem in CPython, but to fix the problem in important packages. So I vote 57.5% likely versus, you know, what is that? 42.3% unlikely. So yes, but, and real quickly before we get your thoughts on this, Brian, other languages solve this in quotes by putting in structures for people to deal with it and then forcing it upon the developers to think about it. For example, in C Sharp, they have locks like we have, but they also have things like a context manager that is a lock blocks. You say for this code, we're going to put it into a context manager, like a width block, but you say, I think it's just lock is the keyword. And then in there that is thread safe and it's not, but you have to think about it

almost all the time. And if you're writing libraries, you have to always think about it. In C sharp, we have critical sections and semaphores and events and it's tricky business, but the burden is put upon other people to deal with it. That's how they solve it. That sounds horrible when you talk about it, but it's usually not horrible. I'm just saying, I spend most of my big chunk of my time in C++, but I work on event-driven systems in real-time systems and stuff. And our architecture is such that when we're in the code that we know our code is, it's an event that's happening, we know there's only one thread running. So I don't usually have to deal with that. And how I deal with talking with other threads or other processes, well, we have message queues and

stuff like that. There's different models that deal with for for dealing with an environment that can allow that but uh yeah there's there's lots of foot guns laying around that you can shoot yourself in the foot if you want to you don't always have to think about it and in the times where i have we've got semaphores and locks and message queues and things like that that help out. But you know, it's not hard. And then there's also functional programming. There's functional programming languages that just don't have any state laying around. So there's nothing like an action is atomic because there's nothing that can step on each other. Yeah. If you have no shared state, then you have no cross threads.

It's no problems. It's about managing the shared state. Yeah. All right. My next. Well, yes, but just Liz out there says, I think it makes sense to have a gill as Python become Python 4, which is an interesting thought. I do feel like it's on the same scale,

but I just think there's so much fatigue from a major incompatible change that maybe python 4 is a word that's just like verboten like we won't speak it you know all right on to the next one well i'm gonna jump then um oops like maximized the window on my screen i can't see anything okay here we go um somebody down the list uh asked about asked about Python four. I can't remember who, uh, but anyway, so we just got it had brought up Python four. Do you think Python four will ever happen? And my answer is no, I don't think it's going to happen. Um, and it was a lot of numbers in that three dot that, that second part can get real big.

Yeah. And I'm just taking it from, uh, listening to a recent interview with Brett Cannon on changelog. He was asked that when's Python four coming around and he said it from listening to a recent interview with Brett Cannon on Changelog. He was asked that, when's Python 4 coming around? And he said, Python 2 to 3 was so painful that I don't think we'll do a 4. At least not for a while. So anyway, I think that we're more likely to go to date-based versions than go to 4. Yeah, exactly.

Just avoid it altogether. It's 2023. But do you want to, should we do the, the let's see. Oh, I want to do the next one. Um, so Nick Cantor says,

uh, what would you recommend for hosting a brand new podcast? Uh, do it yourself or a SAS platform or what would you use? Um, and he said, I'm particularly interested, particularly interested in being able to migrate someday without having to

lose URLs and such. So I'm guessing that Michael would write his own system. Do it yourself. Well, you know what? Maybe. Having our own platform has been super valuable if we want to do things like, hey, let's incorporate a live stream type of component. So, for example, right now, if you go to Python Bytes, there's a big banner that says we're live streaming right now. Come join us and be part of the show. And I just push a button on my stream deck, which calls an API I wrote, which then reconfigures the website to this mode. Yeah. This does not happen if you go with some SaaS platform or whatever, right? You're lucky to get like a creamy looking WordPress thing.

The reason I created my own though was eight years ago, those sites were gnarly looking. They were bad. And if you wanted to create something that you were proud of, there was almost no way in which you could go to your podcast website and be proud of it. At worst, you could be, oh, it's not too bad, right? And I was learning Python and I wanted a cool project to work on that I could just be completely freeform with.

And it took me, I think it probably took a week to get it all done. And it was super fun. So I'm glad I did it. The maintenance life cycle of it, there's something you gotta keep in mind, but it was fun. But I very much might choose something like Fireside.

Or I know, Brian, you're a fan of Transistor FM these days. The reason is you get to focus on the actual thing that people want to hear, building your podcasting craft and working that. Well, I guess I want to put it in a couple highlights. There's the platform for your podcast and then there's your website um both so i've used fireside and now i've switched to transistor uh and i switched testing code from fireside to transistor and i'm starting python people um out at um so we'll just go look and i'm just using their their their their website that they do for free.

It's part of the system. There's the new test and code website. It's not great. I've got the people I have to go in and fill in. I mean, it's not terrible, but it's not bad. I got to go in and I'm hiring one of my kids to go in and fill out the people because it's only listing like two guests so far. I need more. I revamped my people page and it took like two days

of data entry all day yeah it's no joke it's just data entry i got 200 like 300 people or something to fill in python people same and it looks the same thing right so but okay so that's the website part of it but there's a lot more to that you don't have to have the website you can let them do all of the back-end stuff distribute your uh uh your episodes time them and everything and have your website be somewhere else and write your own so that's that's always a possibility um uh so and there's like for instance transistor has uh apis to get that so if you if you want to have a a dated like a django app site or something that reads a, the transistor data and fills it out. When you get a new episode,

you can do that. So I, that being said of the two of fireside, my only my experience is fireside transistor and Michael's. I chose transistor cause it's got lots of shiny new features and I don't want to maintain it. Those are the things. So Michael's willing to maintain it. Yeah, and like I said,

it's something that I get to do as a playground. And also we get to experiment with podcasting, right? With like trying to blend in live streams and other things. For example, if you go to an episode page anywhere, it actually goes and it automatically pulls in the YouTube thumbnail and it uses that YouTube thumbnail for social shares. So like on Twitter and Mastodon, like there's just there's a bunch of cool stuff you can do that I enjoy playing with. So I guess my advice would be don't stress too much about it.

You can always change, but just have your own domain. And you could even if you really want to have full control, the most important thing is the RSS feed. So you could create your own RSS feed, have those go to your site and then figure out what, where do those things really live? Where do I need to redirect to, to actually send that, to actually get the content transferred.

So I would just say control your domain, basically. Make sure you don't just use like, you know, I also wouldn't nick at whatever.com. I also also wouldn't wouldn't worry too much about broken links um it's not like a like a wikipedia or something like that where broken links are going to be a problem most of the most of the content people are getting get from your the the feed the rss feed that's feeding the your podcast players and you can redirect and move those, those there. Everybody's got a system to change that.

So I wouldn't stress about it too much. Pick one. Yep. Just use your own domain. I would say also, this may sound very niche. Like I know not many of our audience members are creating a podcast right now and considering this.

However, like this sort of thought process, this applies to many, many areas of like, am I creating a blog? Am I creating a website that's kind of like a Shopify thing? Or do I do it my own? There's a lot of different angles

in which these kinds of thought processes could apply, I think. And if you're thinking about maybe you might enjoy podcasting, you could just try to be a guest on one of our podcasts and see what you think, what if you like it or not. Indeed.

All right. Am I up next? Yeah. Or are you? I think I read the last one. Yeah. All right. So this next one comes from us, from Eric Mesa, a friend of the show.

Michael has mentioned starting out with C Sharp, and I think Brian sometimes still uses C for work. If you had to use another language other than Python, say Python wasn't just the right language for the job, maybe you need true concurrency. What language do you use instead? Could be an older one like Perl or a new one like Rust and Go. Well, I still use C++ every day. So I would use that for a lot of stuff. But I also use PHP, Perl, Bash. I still write Bash scripts. I would like to try Rust

at some point because it looks like it might be more fun than because it's shiny and new and it looks fun. Yeah, that's cool. I would start by thinking about do I need a systems language? Do I need a UI language? What is it I'm

really trying to do? So if I was doing a system level programming, talking to hardware and it wasn't Python, I might choose something like Rust. I did a lot of C and C++. I probably wouldn't go back to that. I feel like Rust and some of the other more modern languages have a lot to offer, but I could be wrong.

I haven't done that for a while. I think for me personally, there's two and neither of them are JavaScript by the way. So that's good. One is, I still think Carp is a pretty decent language i would i would consider using that for some things but it turns out most things that python is good at or c-sharp is good at that i might need python is also really good at it um apis web stuff a lot of those you know all the data science things maybe not desktop apps that's something else. But for a UI framework,

I did have to choose recently and I chose Flutter and Dart. Flutter the framework, Dart the language, right? That's, we rewrote all of our mobile apps and spent like three months doing that.

Lauren, the main developer and a little bit of poking around for me. But I think that's also a really nice framework. It's a little, I don't mind statically type languages. It's a little over I don't mind statically type languages.

It's a little over the top, like constant. You have to have, if you have a variable or a parameter that's a constant, you have to like start further up in your program that that's a constant. And if like you change the function because you need to modify it, then the place that it started from has,

is there like a weird bunch of like cascading effects that go on and that drive me nuts. But every language will drive you nuts in its own way um for me c sharp and flutter or dart rather because that's the language yeah but that said i think a lot of people say i've heard python is the second best language for so many things and that's why it's so popular and that may or may not be true i think a lot of times python is on par with the best language it is a best choice and it's hard to say it's always the best choice in this situation because context and and whatnot but for my web apps there's no other language that i think is is better i might be able to squeak minor performance

improvements out of one other language in some way or but it's it goes well beyond easily handling with extreme reliability like it'll just run for months at a time if i don't need to touch it high performance it's it's a fantastic language and it's only getting better getting better because of the the c faster c python team and it's getting better because the language features like async and await make more things possible so i i don't necessarily subscribe to the well we all use python because it's the second best choice, but it's flexible, right? I think it's actually one of the best choices

much of the time. There are times where it completely sucks. You know, you're going to need some help if you want to build a desktop app with it or a mobile app with it. It's not desktop, mobile app. You're going to have a hard time, right? You're going to need some weird niche thing.

But for the places where it generally works, it works really well. The other thing is it's not really one language. Even if you program just in Python, your modules that you're pulling in are possibly written in Rust or C or Fortran. There's a lot of other languages that are compiled down and we pull in as

wheels and don't think about it. But I use a lot of I use a lot of a lot of rust now, even though I've never written our line of rust because of modules written in it. So same with a lot of C. Yeah, because of C Python, right? But anyway, yeah. All right. That's good questions. The honest I see them, but we got to keep good questions the honest i see them but we got to keep moving we got questions yeah we got more to get through lots okay um so uh i think we're on astro boy uh yes we are uh hi michael and brian how did you two meet each other and how did you become friends um please tell us the story so we'll try to do the quick version. We'll see if our recollections match from like so many years ago.

So when Michael started TalkPython, I was thinking about starting Test and Code, which at the time was the Python testing podcast until I was tired of saying that. But so he started TalkPython. I was a little miffed at first, but then I thought, it's cool that he's doing that. So I started and I already had a fairly large Twitter following and a decent sized people checking out my blog because I was blogging. And so I decided to support him and help promote Michael, because I liked what what he was doing.

And then when I started, finally started Python, the Python testing podcast, Michael helped promote my stuff. So we were promoting each other. And then I don't remember how long after that Michael contacted me and said, Hey, I'd like to do this Python bytes thing. That's a thing together. Maybe we could do it. It'd be a flash in the pan. Maybe it'll be around for a couple of months. And i think we like went out and hashed out the details which aren't weren't much um at lunch we ate some german food i think i talked about it um i think that's yeah exactly you said hey uh i think you said hey i have some questions about starting my podcast you know and i said hey how about instead of just emailing like like we live five miles apart, let's meet for some lunch.

And yeah, started there. It was great. Yeah. Yeah. So we met over the podcast and then we really got to know each other because we were both excited about doing new podcasts. We're both in the same space and we want to do the Spython Bites thing. So I'm like, why don't we just do this together? This will be fun and then often we will after the after we wrap up this episode or a episode if if one of us

has time um and we want to stick around and bs or ask a question or something we do that um but some people might not realize that i think i see you more at pycon than i have outside of pycon in person i know it's nuts even though we nuts. Even though we live like half an hour away from each other or less. So I know, but should get together more. I think COVID really put a whacking onto the, you know, like get together every now and then for lunch and stuff. And then, yeah. Yeah.

But I definitely do think that Michael's a, as a friend, even though we don't chill and in meet space that much. So yeah, absolutely. Same here. We've done stuff together, but not as much as people might guess. So next one comes from Will Angel. Hey, Will, what are your favorite and your least favorite parts about making a podcast? Oh, you go first.

All right. My favorite part is the actual doing of the podcast. Like this conversation is super fun. Reading Will's comment is fun. Seeing the people in the live stream or hearing about feedback when I ship a show, ship our show. It's awesome. It's so gratifying. People are really friendly and they always have extra information. We often say it, right, Brian? Like somebody in the audience will clarify this for us. And when there's a thing we're not sure of, yeah, how does that work? Or what happens to the data if you send it that API?

Is it public or no? That kind of stuff. So the actual doing the podcast favorite, maybe the editing is one of the things that's pretty tough. I mean, for TalkPython, I do have an editor. For Python Bytes, I don't. We don't do editing. We did.

And because it's a timely show, we just try to ship it a few hours after recording. So I run a bunch of audio cleanup across it, hit it with a few tools and then just send it out. Right. And it's a decent amount of work. So I would say very least favorite dealing with bugs like this won't play. You ship the wrong format or people send you messages, negative feedback. Those are all not super common, but they're also really not nice when they happen. The editing, put that in the middle. It's not great, but it's not so terrible. And yeah, shipping the podcast. But there's just a bunch of like administration

stuff around that I would really prefer not to do, like trying to schedule a guest. Oh, this guest would like to come then. Oh, they can't come then. Oh, but now their company requires them to get approval. You're about to ship it. Now the company wants to like, listen to the audio in case you spoke about their SEC filing. No, we didn't speak about your SEC filing. Yes, but we still need, you know, like that, that like, here's your, here's your whole contract negotiation. Like, you know what, maybe this is not worth it in terms of that particular guest. Right.'s there's stuff that nobody sees that's like a drag but the stuff that people see that's a fun part for me right yeah uh the just hanging out talking that's definitely my doing it my favorite part um the other uh also i guess this is general kind of a meta around it uh going to

pycon or pyCascades or something and having somebody recognize me or hear my voice and say, hey, are you Brian? I love that. It's so cool. It doesn't happen in the rest of my life. I walk around Portland all day

and nobody will say anything to me. So it's kind of neat. I also really like learning new stuff and Python Bytes gives me an excuse. But to be honest, we designed Python Bytes to be not stressful to the two of us. Test and code is more stressful than Python Bytes. Talk Python is like five times more stressful in terms of effort. Yeah. Yeah. So least favorite about Python Bytes, there's not much to not like. We've designed it to be how we want it. So Yeah, absolutely.

Frederick out in the audience points out that maybe someone will make a pod GPT to edit your audio automatically soon. There is some interesting AI stuff out there, but careful, that's one step away from just replacing us. Well, you don't know that we're not AIs right now. That is true. Yeah. Okay. All right, what's next?

Let's see. Thomas Zumsteg. How would you address Python's long-term limitations? I've got a great one for this. Train the next generation. Make sure that you're teaching the people around you so that the next generation could solve the long-term limitations. I think that's the best way.

Well, also, those are being solved slowly, but surely, you know, as things like async and await are added and other aspects of the language, they allow you to solve problems that used to be hard easily. But if you don't stay on top of education, stay on top of just keeping your skills sharp, those problems might be solved, but they might not be solved for you. You know what I mean? Yeah. That know what I mean? Yeah. That said, I do agree that, you know, you want to build a mobile app.

There's no amount of training in Python that's going to help you build a mobile app, unfortunately, right? I know there's Kivi. I know there's Toga. I think those are really, really specialized or not 100% really ready to ship production apps. So I'm thinking like, what would BMW use if they had an option, right?

Yeah. Yeah. So some of them I think is a community thing like carol willing had a great keynote where she spoke about as uh did russell keith mcgee different keynotes spoke about some of the um places where python is not taking advantage of what it could be right the black swan events like that russell keith mcgee spoke about. And then, you know, Carol called out specifically focusing on mobile, I believe, desktop as well as like,

we're really leaving a lot on the table by not having an option here. So community. Yeah. All right. Next for me. I got the next one, right? I think so. All righty.

How much time does it take to prepare each episode? We can go quick on this one because we kind of talked about that. This is from Joe Readley. And also, what is your second favorite programming language? We kind of talked about that as well. But how much time does it take to prepare for each episode? And also, is it faster now than it was before? Yes, definitely faster now than it was before. For Python Bytes, one to three hours probably,

more closer to the one hour to prepare. And then for test and code, it can vary. It's all over the map from like a few hours to a week to get ready for an episode. Right. And I would say for Python Bytes, probably an hour as well for me and then to get it fully polished and released another two hours after that that said it's not the getting ready is not necessarily all in one block right especially for this show because like last night i was flipping through flipboard and i

saw oh there's a big scython giant scython re-release for scython 3 that's supposed to change a bunch of stuff like oh that's interesting save that not for this week but for next week and read a little bit about it, you know, 10 minutes here and then I'll come back, right? So we kind of like are always, always have these nets trawling through the announcements and stuff.

Yeah, I'm probably spending 20 to 30 minutes a day, every day, paying attention to what's going on. Yeah, but you would do that as a developer that cares about your career for a large part anyway, right? You just wouldn't have a specific date to tie it to. Like, I need this for Tuesday. He was like, I should know this.

I can know I need it for Tuesday at 11. That's what I need it for. Yeah. So, okay. Next. Okay. He says how to pronounce his name, but I still don't understand. So Colin Valence, maybe?

Colin Valence, do you think? Anyway, asks, let's see. How would you suggest a non-traditional trained developer with the intermediate abilities learn proper skills for Python? For instance, I struggle with tests because I haven't written code in a testable way. CS concepts my mentor throws at me aren't very clear. Okay, I got two options there that I think are a good place to start. One is read Python testing with PyTest.

Not seriously, I think it's a good book on introducing you to unlearn some of the weird lessons people have learned about testing. That's one of the things that the book does is uh tries to help you think about testing better um the other thing is michael's got my my there's a uh there's a course called like python the pythonic way or something like that what was it right pythonic code yeah which covers like 55 topics separate all with code examples and stuff yeah it's totally fun and then also read other people's code. Go read some of the top Python packages and read how their code works. Those are my suggestions.

Yeah, those are good suggestions. I would also follow up with just, I guess, two things real quick. One, nobody learns this stuff all at once. You learn it one thing at a time. So, for example, he was talking about properties. Like, if properties are important to you or you see them showing up in a place

where you really need to know them to use them, you know, take some time, learn that one thing. Learning properties on its own is not a huge challenge, right? Trying to say that's one of a hundred things in CS that are abstractions I should know, like that's a pretty, you know, daunting thing. It's like a mountain, right?

But you don't climb a mountain in a leap, you climb it in steps. Each one of those little steps is how you do it. So don't let it overwhelm you because you solve it slowly. You build that up over slowly over time. And how do you know which to pick? Pick a project.

Like I gave my example, the Talk Python podcast. I could have gone with some, I can't remember the names of them, Pod something or other. There's no fun. But I created that project and I didn't go and like try to learn all of the web framework I was using. I just learned enough to like, okay, I need, I need this page to show up now.

I need to serve XFL. How do I do that? Like, that's what I learned. And I didn't just learn an abstract. I'm like, there's three more things I have to do until I'm done. I start with thing one, let's get going. Like, how do I do that? Right.

And so it really narrows you down to the manageable bite sized bits, I think. I also think it'd be it's good to pick a small project, even if it's a toy project, and write it, rewrite it several times. Try to try to get as much just whatever you can hack together to make it work, then learn some more stuff about Python, and then go back and edit it. And you'll realize that you've learned some different things. The other thing is when I came from like C background to Python, the data structures and how to iterate through data structures is way different. So embrace that we do things different in Python than you do in other languages and try to think in Python instead of thinking in C and translating to python or something like that too yeah um frederick also has a really good one that i

didn't think of modern lenters like rough and flake 8 can help you writing pythonic code in general because they will point out oh you should be using a list comprehension for this or you should be using a for each uh for in loop type thing um instead of this weird janky for loop you created out of range or something and turning on turning on linters within uh within vs code or or pycharm or whatever you're using helps you so if you see a little a little something going on maybe there's something wrong and check it out yeah pay attention to that to that, right? Absolutely. All right. Next. Jerry says, yeah, think of me. Could I inquire, Michael,

about how you came to the decision to create the TalkPython platform? Further, what do you envision for its future? Absolutely, you may. So I think we addressed a lot of that, of the why, right? Like, why did I create it, right? There's a podcast I did with Dan Bader from RealPy real python over here it's really fun

we did this live at pycon well it's sort of live but i'm called the software powering talk python courses and podcasts and we talked for how long is that talk for an hour and seven minutes about why did i choose this web framework why did i choose this database like how do we deploy it what are the trade-offs and sort of compared that to real Python as well. And that was super fun. And people can check that out. That's episode 215 on TalkPython. It's a little bit old.

It's the last PyCon in the before days. So... I remember walking by and watching you guys do that interview. Yeah, that was fun. That was a lot of fun. So that's the what and the how. And what do I envision for its future?

Well, I think it's pretty stable, right? We've got the podcast stuff is really working well. I talked about some of the cool additions we've added to sort of multiply it out, right? From YouTube to the podcast page, to the social share etc those those kind of things are pretty dialed the courses platform wise is i think really good you know it's it's super stable there's things i could do to make it better but they're playing right around

the edges you know like oh we could add a a volume control with the memory of the volume is set in the web player like for a very small percentage of people, that matters a lot. For most, you're like, well, my computer has a volume, so I'll use that. We got the brand new mobile apps. I just redid those. So honestly, I think the important part, and I kind of, it's like a little bit, like I said around maybe don't build your own platform.

The important part for us is more content. Like I'm really looking to build, work with more people and build some awesome courses. We have a bunch underway that I don't want to commit to until they're really almost ready to release. But I think it's about producing, continue to try to produce as good a podcast as I can, as well as like courses and maybe working with more people to bring more perspectives to that stuff.

So content more than platform, I guess, is what I see. Okay. Hey, we're kind of running low on time um but i'd like to get through some more do i'm are you okay with just jumping around uh whatever let's go answer lightning around okay so this one comes from aries um wait no uh from adam uh and the question is uh what does b actually do for work? Is it top secret? So I just want to mention quickly, I brought this up in my PyCascades talk. So that's on a video.

But I make these things. So it's on the video. I work for a company called Rodent Sports. And I'm a team lead, but also do embedded work and test them but they're uh rf test equipment for um wi-fi devices wi-fi and cellular devices and they get run in production product lines to test make sure all the rf stuff works and you're in all of the goodies that you play buy and play with but um yeah so that uh that's the that interface of uh just a whole bunch of uh ports

out the front that's kind of why i don't really test user interfaces that much because the main there's not a really user interface so anyway there is there's a web interface to these they're really pretty cool but still yeah it's always fun when uh software and hardware get together anyway okay what's the next question michael you want to answer or let's see and while i'm looking i'll just point out like i know most people know but podcasts courses that's my job no consulting no other stuff at the moment let's see there's a couple here that we've already answered so i don't want to come back to them uh let's go with one from felix the cat who felix we still got to have have time for a super quick

extra and a joke, Brian. So Felix will make another appearance, but what do you think, why do you think people put so much effort and put so much rust into Python? To make it fast. We used to use C, now we use Rust. Yeah, I think that's more of a statement on Rust versus C than it is anything to do with Python, right?

There are places in Python where, because the way it works, it's just not that fast. I said it's plenty fast for a lot of things earlier. And that's true in my world where I'm talking to a database, crunching a bunch of stuff with Pydantic, and then shipping off some dictionaries, right? That's milliseconds. But if your job is to, you know, simulate certain physics algorithms, right? Doing the math in Python is a bad idea, right? Or, or apply machine learning just because in C or other languages, you have four bytes or you have eight bytes and they just jump on registers. In Python, you have pointers, the things that point over to numbers that are high object derived longs and like floats. And it's, it's just not even close to the same type of thing. Right. And

so there's, we do got to make Python faster, right. For certain scenarios. And you see that a lot of times being applied, like the core of the new Pydantic is done in Rust. I imagine it could also have been done exactly as well in C. And they both, you know, the performance numbers are like 22 times faster. So I think the motivation to go from Python to build the hotspots of the core pieces in something faster makes total sense.

And that's also why Python is fast enough, right? It's, if it was Python all the way down, it might not actually be fast enough, but it's not. Yeah. Yeah, so I think it's, you probably have more insight to this than I do, Brian, but I think people are looking for something more modern than C, especially something memory safe,

and Rust is a pretty good option. And the tools around integrating Python and Rust have grown up really quickly and are pretty solid. So there's examples, modern examples for how to do it. So also, yeah, as David points out. Shiny, it is shiny. It's shiny and new, even though it's called Rust. But anyway. Yeah, yeah, we do love shiny new things.

Well, should we do some extras? Let's do some extras. You got any extras for us? Oh, just quickly, I want to remind people that Python People is live and there's another episode coming out today with Paul Everett from PyCharm. And then also, testing code's still going.

So anyway, but it did change. So if you see any problems, let me know. That's my extra nice uh yeah paul everett is a great python people so i'm looking forward to listening to that how about you i have some as well there is a at the time of recording this is still up you never know with the time of listening we already described that latency there so we don't can't control that but right now the psf i don't know for how long this will be up. Maybe it says somewhere that the deputy CPython developer in residence position is a position that can be now applied for.

So we've got the CPython developer in residence that Lukas Lange has been manning for a couple of years, doing an awesome job, making a big difference. So much so that the PSF is like, what if we had more Lukash's? That'd be cool. And so you could be a deputy, Lukash's deputy, as I see Python developing residents. Apply for that if that sounds cool for you.

I'll link to that in show notes. Cool. Nice. Yes. And the Python Web Conference, Python Web Conf 2023 talks are online. I think there are 80. Yes, there are at least 80 videos of them. And included in that is my Make Your Python Web Apps Fly Around the World with CDNs,

which is a really fun 42-minute talk that I gave that's kind of the cliff notes for the full CDN course over at TalkPython Training that I did as well. So people can check that out. I'll link to that as well. Cool. And that's it. So ready for a joke? I am ready. This is not even, this is not even so much a joke. This was sent over by Felix the cat and it is the ode to Python. There's a lot of pop-ups at medium. So this is an ode put together by Pete Fiston five days ago, and I will do my best to do it justice. Are you ready, Brian? i think this is a fitting one to do here at the end of the show on this sort of look back type of episode my love is a language so fine created by guido divine duck typing in white space she runs with sublime grace

now coding flows freer than wine with one simple import you see i mastered anti-gravity just one line of code and off we both rode flying higher and further for free bliss comprehensions oh my make coding as easy as dot pi with one simple line my code can now shine make other languages sigh thank you dear guido i say for siring this language so bay now understand she's the best in the land and i earnestly hoped she will stay oh i love it it's not bad is it it's good i like it it is it is it's too big for a t-shirt but yeah maybe not i'll use a small font just don't wash it it'll get fuzzy so well thanks a ton for this wonderful fun episodes and thanks to everybody for sending in questions.

We appreciate it. Yeah, absolutely. Thank you, everyone, for sending in the questions and thoughts. And I know there are many more out there who did not send in a question, but who appreciate this show. And we really appreciate you all listening and letting us keep doing this, basically. Yeah. Thanks. Thanks, Brian.

Thank you. Yeah. Bye, everyone.