Transcript #344: AMA: Ask Us Anything

00:00 Hello and welcome to Python Bytes where we deliver Python news and headlines directly to your earbuds.

00:05 This is episode 344, recorded July 18th, 2023.

00:10 I'm Michael Kennedy.

00:11 And I'm Brian Okken.

00:12 And this episode is brought to you by us.

00:14 Check out our courses, books, things like that.

00:17 Links are in the show notes. We got many of them.

00:19 And if you want to be part of the live show, we live stream about the same time, usually 11am Pacific time.

00:28 Not always, you know, especially around vacation time.

00:31 But that's typically what we do on YouTube.

00:33 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.

00:39 You can find that at pythonbytes.fm/live.

00:42 Brian, what a special episode.

00:44 Yeah, this is going to be fun, I think.

00:46 It's almost like we're being interviewed, but by people who are not actually here.

00:50 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.

00:58 And many people submitted questions.

01:01 So we're going to go through some of those questions today.

01:04 >> 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.

01:14 But that said, let's go through the list.

01:16 We had a bunch of people fill out a Google form and give us one or more questions.

01:21 We'll have to deal with the second question, logistics as we go, we'll figure that out.

01:26 But I'll just kick it off.

01:27 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?

01:37 Ask us anything, whatever.

01:40 A little bit, I tailored them a little bit in that order, but not super.

01:43 So the first one comes from a frequent participant and friend of the show, Kim Van Wyk.

01:47 Question is, Python Bytes is more focused on new events than either of your personal podcasts, such as Talk Python, Python Friends, Test to Code, 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 answering this one.

02:14 Well, so I actually am not, I don't look at the Python bytes statistics too often. And I also I don't, I'm not sure about the, the right away versus later. I'm guessing it's right away. So I do have I pulled up a graphic from from the stats for testing code and testing code is yeah, a lot of a lot of listens later on. 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 when I if like if I release on 11 o'clock at night, that'll count as the day one, you know, and but most of the downloads are the next day.

02:56 Anyway, things like that.

02:57 So the first couple of days, it's most.

02:59 But if you see, I'm just like showing the the last like the top 15 last 15 episodes only like, you know, so in total 3 to 5000 downloads for the first couple of days.

03:15 Testing code normally gets 6 to 10,000.

03:18 So yeah, the bulk is in the first couple of days, but it is a lot of a lot of stuff tapers off to.

03:24 I think that's probably true for Python bytes and testing code and talk Python.

03:30 Statistics for podcasts are so interesting. Like there, 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 it'll get them to watch for 10 seconds and then skip to the next thing.

03:49 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?

03:54 Like, you know, like the YouTube algorithm seems to do often.

03:57 And so I do think those numbers are more impactful.

04:00 That said, there's a little bit of a challenge just technically to know these things.

04:05 So I agree, I would say with Python bytes, we get probably, oh boy, I gotta go to the bottom here of my list.

04:14 we get about two-thirds of the downloads on average in the first week.

04:19 But that just means people have their podcast players subscribed to our show rather than they happen upon it and listen to it.

04:27 Because as soon as it publishes, they literally swarm the site.

04:34 The CDN goes to gigabit levels, high gigabit levels of bandwidth in the first hour, and then it just drops because they get put onto your player.

04:43 But as it should be, those players don't send tons of information and analytics back to us, right?

04:49 They don't say, "Well, we downloaded it," but they didn't watch it for three weeks or listen to it for three weeks.

04:53 So it's hard to read into those.

04:55 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.

05:04 Like, "That topic's interesting.

05:06 Eh, interesting for some people, but not for me, so I'm skipping that," right?

05:10 Like, I feel like there's probably that behavior.

05:13 I encourage everyone to listen right away.

05:14 I love that people listen to the show and that they make it part of their lives.

05:19 It's super meaningful and it's an honor.

05:22 But I also understand, we're not the only thing in people's lives.

05:25 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.

05:34 - Yeah. - Yeah.

05:35 - Okay, well, so the next question comes from us from BL.

05:39 And this is an interesting one.

05:42 So the question really is, I'll try not to summarize too much.

05:47 I might do a little bit.

05:48 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 for Rust and C, Python fits my brain and I love it.

05:59 I love the community.

06:00 We do too.

06:01 Crazy, am I crazy to remove non-Python languages from my resume and LinkedIn?

06:08 Is it possible I'll maintain systems, you know, 20 years in the future, like COBOL and such.

06:13 So basically, if I only really wanna work on Python, should I remove other languages from LinkedIn and your resume?

06:20 Do you have thoughts on that, Michael?

06:22 - Yes, and I have a fork in the road type of situation.

06:26 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 gotta keep grinding this out till I get something, I think more routes in different directions might lead to something, right?

06:43 And that's probably fair.

06:45 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.

06:58 Because, you know, I've at one point for a very brief time did VB6.

07:03 If somebody approaches me and said, "Michael, we got a VB6 job for you." Like, no, I don't want it.

07:09 You're going to have to come with seven figures of numbers to get me to go do BB6.

07:13 And maybe divide that by two.

07:15 But there's like a good number you're going to--

07:17 an unreasonably high amount you're going to 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.

07:24 And so if I was in that situation where I wasn't urgent, I would highlight as much as possible what I really, really want to do.

07:32 And if you really want to work in Python, 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.

07:43 They have a role and they want it filled.

07:45 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.

07:53 They're not looking for a person that does both, probably, most of the time, right?

07:57 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.

08:04 So I would advertise and really make it look more like I have a better skill set in the one area I really wanna be than trying to play in all of the areas.

08:13 That's my personal thought.

08:15 - Yeah, I used to be of the opinion of take everything off your resume that you don't want to work on.

08:22 But I was talking this over, I do a lot of hiring.

08:26 I was talking this over with another manager, higher up manager, and he said that his preference is highlight the ones you want to work on.

08:35 That's great. But list the other technologies you've been in that you don't do a huge list, but a large enough list to just show that you have learned new technologies over time.

08:49 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.

08:56 It will help you to know.

08:57 >> I have no idea what a pointer is, and please don't show me a void star star.

09:02 The one catch though is if you're not willing to talk about it during an interview, take it off your resume.

09:09 You can leave it on LinkedIn if you want to help catch bites with LinkedIn.

09:14 But on your resume, if it's on your resume, it's a fair game to ask about.

09:18 So that three months that I worked on C# system, I'm not going to put it on my resume because that would be my answer.

09:26 If somebody said, "Tell me about your experience with C#," 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.

10:05 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.

10:15 >> Yeah.

10:16 >> Here's why I should be doing that.

10:18 >> I did Pascal in college, but I've never put it on a resume.

10:21 >> I did Fortran, same.

10:23 I did it against my will.

10:25 I don't want to talk about it anymore.

10:27 Let's talk about the next question.

10:28 >> Okay.

10:29 >> This one comes from Doug Farrell.

10:31 He just had his book come out, a well-grounded Python developer, I believe.

10:35 Excellent stuff. Congrats on that, Doug.

10:38 He's wondered about the GIL and how many other languages resolve or handle things the GIL handles for Python.

10:46 Let me read into this, will we have a GIL-less Python soon?

10:51 I don't know actually. Sam Gross' work and all the stuff happening around Cinder and Facebook.

10:57 It's very, very exciting. That's one side.

11:00 Side two is there was a near mutiny in the community because we changed the way that bytes are interpreted.

11:07 >> That was the two to three?

11:08 >> Yes. There was hardly anything else.

11:11 I can tell you that the change from removing the GIL 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.

11:27 So I'm stuck because of the ecosystem, I have this golden handcuff to the past in a sense.

11:33 We have the same problem.

11:35 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.

11:47 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, 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.

12:22 For example, in C#, they have locks like we have, but they also have things like a context manager that is a lock block.

12:30 So you say for this code, we're going to put it into a context manager like a with block, but you say, I think it's just lock is the keyword.

12:36 And then in there, that is thread safe and it's not, but you have to think about it almost all the time.

12:41 And if you're writing libraries, you have to always think about it.

12:44 In C#, we have critical sections and semaphores and events.

12:47 and it's tricky business, but the burden is put upon other people to deal with it.

12:51 >> Yeah.

12:52 >> That's how I solve it.

12:53 >> That sounds horrible when you talk about it, but it's usually not horrible.

12:57 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.

13:07 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.

13:16 I don't usually have to deal with that.

13:19 How I deal with talking with other threads or other processes, well, we have message cues and stuff like that.

13:25 There's different models that you deal with for dealing with an environment that can allow that.

13:31 But yeah, there's lots of foot guns laying around that you can shoot yourself in the foot if you want to.

13:37 You don't always have to think about it.

13:39 Then the times where I have, we've got semaphores and locks and message cues and things like that that help out.

13:45 But it's not hard.

13:47 Then there's also functional programming.

13:49 There's functional programming languages that just don't have any state laying around.

13:54 There's nothing like an action is atomic because there's nothing that can step on each other.

14:01 >> Yeah. If you have no shared state, then you have no cross threads.

14:04 >> No problem.

14:05 >> It's no problem. It's about managing the shared state.

14:08 >> All right. My next.

14:11 >> Well, yes. Just Liz out there says, I think it makes sense to have a Gillis Python become Python 4, which is an interesting thought.

14:18 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 verboten.

14:30 We won't speak it. All right, on to the next one.

14:32 >> Well, I'm going to jump then.

14:34 Oops, I maximized the window on my screen.

14:37 I can't see anything. Okay, here we go.

14:40 Somebody down the list asked about Python 4.

14:44 I can't remember who.

14:45 But anyway, so we just had brought up Python 4.

14:49 Do you think Python 4 will ever happen?

14:51 My answer is no, I don't think it's going to happen.

14:54 >> There's a lot of numbers in that three dot, that second part can get real big.

14:59 >> Yeah.

14:59 >> It's going to get big.

15:01 >> 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-3 was so painful that I don't think we'll do a 4.

15:13 At least not for a while.

15:16 So anyway, I think that we're more likely to go to date-based versions than go to 4.

15:23 >>Yeah, exactly, just avoid it altogether.

15:25 It's 2023.

15:26 >>But do you wanna, should we do the, let's see.

15:29 Oh, I wanna do the next one.

15:30 Nick Cantor says, "What would you recommend "for hosting a brand new podcast?

15:36 do it yourself or a SaaS platform or what would you use?

15:41 He said, "I'm particularly interested in being able to migrate someday without having to lose URLs and such." I'm guessing that Michael would write his own system, do it yourself.

15:54 >> Well, you know what? Maybe.

15:56 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.

16:05 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.

16:13 And I just push a button on my stream deck, which calls an API I wrote, which then reconfigures the website to this mode.

16:20 This does not happen if you go with some SaaS platform or whatever, right?

16:24 You're lucky to get like a creamy looking WordPress thing.

16:27 The reason I created my own though was eight years ago, those sites were gnarly looking.

16:32 They were bad.

16:34 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.

16:43 At worst, you could be, "Eh, it's not too bad," right?

16:46 And I was learning Python, and I wanted a cool project to work on that I could just be completely freeform with.

16:53 And it took me, I think it probably took a week to get it all done, and it was super fun.

16:59 So I'm glad I did it.

17:00 The maintenance lifecycle of it, there's something you gotta keep in mind.

17:03 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.

17:11 The reason is, you get to focus on the actual thing that people want to hear, building your podcasting craft and working that.

17:18 - Well, I guess I wanna put it in a couple highlights.

17:23 There's the platform for your podcast, and then there's your website.

17:28 Both, so I've used Fireside, and now I've switched to transistor.

17:33 And I switched testing code from Fireside to transistor and I'm starting Python people out at, so we'll just go look.

17:41 And I'm just using their website that they do for free.

17:45 It's part of the system.

17:46 There's the new testing code website.

17:48 It's not great.

17:49 I've got the people I have to go in and fill in.

17:52 I mean, it's not terrible, but it's not bad.

17:54 I gotta go in and I'm hiring one of my kids to go in and fill out the people 'cause it's only listing like two guests so far.

18:01 I need more.

18:02 - It took, I revamped my people page and it took like two days of data entry, all day.

18:07 - Yeah, well. - It's no joke.

18:08 - It's just data entry, I got 200, like 300 people or something to fill in.

18:12 Python people, same.

18:13 And it looks the same thing, right?

18:15 So, but, okay, so that's the website part of it, but there's a lot more to that.

18:19 You don't have to have the website.

18:21 You can let them do all of the backend stuff, distribute your episodes, time 'em and everything, and have your website be somewhere else and write your own.

18:30 So that's always a possibility.

18:32 And there's like, for instance, Transistor has APIs to get that.

18:38 So if you wanna have a data, like a Django app site or something that reads the Transistor data and fills it out when you get a new episode, you can do that.

18:51 So that being said, of the two of Fireside, My experience is Fireside Transistor and Michaels.

19:01 I chose Transistor because it's got lots of shiny new features and I don't want to maintain it.

19:07 Those are the things.

19:08 Michaels is willing to maintain it.

19:10 >> Yeah. Like I said, it's something that I get to do as a playground.

19:14 Also, we get to experiment with podcasting, with trying to blend in live streams and other things.

19:20 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.

19:31 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.

19:36 So I guess my advice would be don't stress too much about it.

19:39 You could always change, but just have your own domain.

19:42 And you could even if you really want to have full control, the most important thing is the RSS feed.

19:46 So you could create your own RSS feed, have those go to your site and then figure out where do those things really live?

19:52 where do I need to redirect to to actually send that, to actually get the content transferred?

19:57 >> Yeah.

19:58 >> I would just say control your domain basically.

20:01 Make sure you don't just use like nick@whatever.com.

20:06 >> I also wouldn't worry too much about broken links.

20:09 It's not like a Wikipedia or something like that where broken links are going to be a problem.

20:14 Most of the content people are getting get from the feed, the RSS feed that's feeding your podcast players.

20:24 And you can redirect and move those.

20:27 Everybody's got a system to change that.

20:29 So I wouldn't stress about it too much.

20:31 Pick one.

20:32 >> Yeah. Just use your own domain.

20:34 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.

20:41 However, this thought process, this applies to many, many areas of like, am I creating a blog?

20:49 Am I creating a website that's kind of like a Shopify thing?

20:52 Or do I do it my own?

20:53 There's a lot of different angles in which these kind of thought processes could apply, I think.

20:57 - 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, if you like it or not.

21:06 - Indeed.

21:07 All right, am I up next?

21:08 - Yeah. - Or are you?

21:09 - I think I read the last one.

21:10 - Yeah, all right.

21:11 So this next one comes from us, from Eric Mesa, friend of the show.

21:15 Michael has mentioned starting out with C#, And I think Brian sometimes still uses C for work.

21:20 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?

21:28 Could be an older one like Perl or a new one like Rust and Go?

21:31 Go ahead, Brian.

21:31 Well, I still use C++ every day.

21:34 So I would use that for a lot of stuff.

21:36 But I also use PHP, Perl, Bash.

21:41 I write a lot of-- I still write Bash scripts.

21:43 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.

21:54 >> That's cool. I would start by thinking about, do I need a systems language?

21:59 Do I need a UI language?

22:01 What is it I'm really trying to do?

22:03 If I was doing a system level programming, talking to hardware and it wasn't Python, I might choose something like Rust.

22:09 I did a lot of C and C++.

22:11 I probably wouldn't go back to that.

22:13 I feel like Rust and some of the other more modern languages have a lot to offer, but I could be wrong.

22:18 I haven't done that for a while.

22:19 I think for me personally, there's two and neither of them are JavaScript by the way, so that's good.

22:24 One is, I still think C# is a pretty decent language.

22:28 I would consider using that for some things, but it turns out most things that Python is good at, or C# is good at that I might need, Python is also really good at it.

22:38 APIs, web stuff, a lot of those, all the data science things.

22:42 Maybe not desktop apps, that's something else.

22:44 But for a UI framework, I did have to choose recently, and I chose Flutter and Dart.

22:49 Flutter the framework, Dart the language, right?

22:51 We rewrote all of our mobile apps and spent like three months doing that.

22:56 Lauren, the main developer, and a little bit of hooking around for me, but I think that's also a really nice framework.

23:02 It's a little, I don't mind statically typed languages, it's a little over the top, like constants.

23:07 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 'cause you need to modify it, then the place that 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.

23:27 For me, C# and Flutter, or Dart rather, 'cause that's the language.

23:31 - Yeah.

23:31 - 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.

23:39 I think a lot of times Python is on par with the best language.

23:43 It is a best choice.

23:44 And it's hard to say it's always the best choice in this situation because context and whatnot.

23:50 But for my web apps, there's no other language that I think is better.

23:53 I might be able to squeaks minor performance improvements out of one other language in some way, or, but it's, it goes well beyond easily handling with extreme reliability.

24:04 Like it'll run for months at a time.

24:06 If I don't need to touch it.

24:07 High performance.

24:09 It's, it's a fantastic language and it's only getting better getting better because of the faster CPython team, and it's getting better because the language features, like async and await make more things possible.

24:20 I don't necessarily subscribe to the, well, we all use Python because it's the second best choice but it's flexible.

24:26 I think it's actually one of the best choices much of the time.

24:30 There are times where it completely sucks.

24:33 You're going to need some help if you want to build a desktop app with it or a mobile app with it.

24:38 It's not desktop, mobile app.

24:40 You're going to have a hard time.

24:41 Are you going to need some weird niche thing?

24:44 But for the places where it generally works, it works really well.

24:47 >> The other thing is, it's not really one language.

24:51 Even if you program just in Python, your modules that you're pulling in are possibly written in Rust or C or Fortran.

25:01 There's a lot of other languages that are compiled down, and we pull in as wheels and don't think about it.

25:09 But I use a lot of Rust now, even though I've never written a line of Rust because of modules written in it.

25:17 >> You use a lot of C because of CPython, right?

25:21 >> But anyway.

25:22 >> All right. Good questions, to be honest, I don't like to see them, but we got to keep moving. We got questions.

25:27 >> Yeah, we got more to get through, lots.

25:29 Okay. I think we're on Astro Boy.

25:34 >> Yes, we are.

25:35 >> Hi, Michael and Brian.

25:37 How did you two meet each other?

25:39 and how did you become friends?

25:42 Please tell us the story.

25:43 So we'll try to do the quick version.

25:46 - Let's see if our recollections match from like so many years ago.

25:49 - So when Michael started Talk Python, I was thinking about starting Test and Code, which at the time was Python, the Python testing podcast, until I was tired of saying that.

26:02 But so he started Talk Python.

26:05 I was a little miffed at first, but then I thought, it's cool that he's doing that.

26:08 So I started and I already had a fairly large Twitter following and a decent size people checking out my blog because I was blogging.

26:18 And so I decided to support him and help promote Michael because I liked what he was doing.

26:23 And then when I started, finally started Python, the Python testing podcast, Michael helped promote my stuff.

26:31 So we were promoting each other.

26:33 And then I don't remember how long after that Michael contacted me and said, hey, I'd like like to do this Python bytes thing, that's a thing together, maybe we could do it together.

26:43 - Probably be a flash in the pan, maybe it'll be around for a couple months.

26:46 - And I think we like went out and hashed out the details, which weren't much at lunch.

26:53 We ate some German food, I think, talked about it.

26:56 Think that's about how it started.

26:57 - Yeah, exactly, you said, hey, you 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 we live five miles apart, and just meet for some lunch and yeah, started there, it was great.

27:09 - Yeah.

27:10 - 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 wanna do this Python Bytes thing, so I'm like, why don't we just do this together, this'll be fun.

27:24 - And then often we will, after we wrap up this episode or a episode, if one of us has time and we wanna stick around and BS or ask a question or something, we do that.

27:35 But some people might not realize that I think I see you more at PyCon than I have outside of PyCon in person.

27:42 - I know, it's nuts.

27:44 Even though we're not close to each other.

27:45 - We live like half an hour away from each other or less.

27:48 - I know.

27:49 Should get together more.

27:50 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.

27:58 - Yeah, but I definitely do think of Michael as a friend even though we don't chill in meet space that much.

28:04 - Yeah, absolutely, same here.

28:05 We've done stuff together, but not as much as people might guess.

28:08 So, next one comes from Will Angel.

28:12 Hey, Will.

28:13 What are your favorite and your least favorite parts about making a podcast?

28:16 - Oh, you go first.

28:17 - All right, my favorite part is the actual doing of the podcast.

28:21 Like, this conversation is super fun.

28:23 Reading Will's comment is fun.

28:24 Seeing the people in the live stream or hearing about feedback when I ship a show, ship our show, it's awesome.

28:31 It's so gratifying.

28:32 People are really friendly, and they always have extra information.

28:35 We often say it, right, Brian?

28:37 Like, somebody in the audience will clarify this for us.

28:41 And when there's a thing we're not sure of, yeah, how does that work?

28:43 Or what happens to the data if you send it that API?

28:45 Is it public or no?

28:47 That kind of stuff.

28:48 So the actual doing the podcast favorite, maybe the editing is one of the things that's pretty tough.

28:57 I mean, for Talk Python, I do have an editor.

28:58 For Python Bytes, I don't.

29:00 We don't do editing.

29:01 We did.

29:02 And because it's a timely show, we just try to ship it a few hours after recording.

29:06 So I run a bunch of audio cleanup across it, hit it with a few tools and then just send it out, right?

29:12 And it's a decent amount of work.

29:14 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.

29:23 Those are all not super common, but they're also really not nice when they happen.

29:28 The editing, put that in the middle.

29:30 It's not great, but it's not so terrible.

29:33 And yeah, shipping the podcast.

29:35 But there's just a bunch of like administration stuff around that I would really prefer not to do.

29:40 Like trying to schedule a guest.

29:42 Oh, this guest would like to come then.

29:44 Oh, they can't come then.

29:45 Oh, but now their company requires them to get approval.

29:48 You're about to ship it.

29:49 Now the company wants to like listen to the audio in case you spoke about their SEC filing.

29:53 No, we didn't speak about your SEC filing.

29:56 But we still need, you know, like that, that like, here's your whole contract negotiation.

30:01 Like, you know what, maybe this is not worth it in terms of that particular guest, right?

30:04 So 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?

30:11 - Yeah, just hanging out, talking, that's definitely my, doing it, my favorite part.

30:17 The other, also, I guess this is general kind of a meta around it, 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.

30:33 It doesn't happen in the rest of my life.

30:35 I walk around Portland all day and nobody will say a thing to me.

30:39 So it's kind of neat.

30:41 I also really like learning new stuff and Python Bytes gives me excuse.

30:45 But to be honest, we designed Python Bytes to be not stressful to the two of us.

30:51 Test and code is more stressful than Python Bytes.

30:54 - Yeah, talk Python is like five times more stressful in terms of effort.

30:57 - Yeah, so least favorite about Python bytes, there's not much to not like.

31:01 We've designed it to be how we want it.

31:03 - Yeah, absolutely.

31:05 Frederick out in the audience points out that maybe someone will make a pod GPT to edit your audio automatically soon.

31:12 There is some interesting AI stuff out there, but careful, that's one step away from just replacing us.

31:17 - Well, you don't know that we're not AIs right now.

31:20 - That is true.

31:21 (laughing)

31:23 - Yeah, okay.

31:24 >> What's next?

31:25 >> Let's see, Thomas Zumsteg, how would you address Python's long-term limitations?

31:32 I've got a great one for this.

31:34 Train the next generation.

31:36 Make sure that you're teaching the people around you so that the next generation could solve the long-term limitations.

31:42 I think that's the best way.

31:44 >> Well, also, those are being solved slowly but surely.

31:49 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.

31:56 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.

32:04 >> You know what I mean?

32:05 >> Yeah.

32:05 >> That said, I do agree that you want to build a mobile app.

32:08 There's no amount of training in Python that's going to help you build a mobile app, unfortunately.

32:12 I know there's Kivy, I know there's Toga.

32:15 I think those are really, really specialized or not 100 percent really ready to ship production apps.

32:20 So I'm thinking like, what would BMW use if they had an option, right?

32:24 - Yeah.

32:25 - Yeah, so some of them I think is a community thing.

32:28 Like Carol Willing had a great keynote where she spoke about, as did Russell Keith-Magee, different keynotes, spoke about some of the places where Python is not taking advantage of what it could be, right?

32:42 The Black Swan events like that Russell Keith-Magee spoke about, and then Carol called out specifically focusing on mobile, I believe desktop as well, is like we're really leaving a lot on the table by not having an option here.

32:55 So community, yeah.

32:57 All right, next from me, I got the next one right?

32:59 - I think so.

33:00 - All righty.

33:01 How much time does it take to prepare each episode?

33:03 We can go quick on this one, 'cause we kinda talked about that.

33:08 This is from Joe Readley.

33:09 And also, what is your second favorite programming language?

33:12 We kinda talked about that as well.

33:13 But how much time does it take to prepare for each episode?

33:16 - And also, is it faster now than it was before?

33:20 Yes, definitely faster now than it was before.

33:23 For Python bytes, one to three hours probably, more closer to the one hour to prepare.

33:31 And then for test and code, it can vary.

33:34 It's all over the map from like a few hours to a week to get ready for an episode.

33:39 - Right, and I would say for Python bytes, probably an hour as well for me, and then to get it fully polished and release another two hours after that.

33:46 That said, it's not, getting ready is not necessarily all in one block, right?

33:52 Especially for this show.

33:53 Because like last night I was flipping through Flipboard and I saw, oh, there's a big Cython, giant Cython re-release for Cython 3 that's supposed to change a bunch of stuff.

34:01 Oh, that's interesting.

34:02 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?

34:07 So we kind of like are always, always have these nets trawling through the, the announcements and stuff.

34:13 - Yeah, and probably spending 20 to 30 minutes a day, every day, paying attention to what's going on.

34:19 - Yeah, but you would do that as a developer that cares about your career for a large part anyway, right?

34:24 You just wouldn't have a specific date to tie it to.

34:27 Like, I need this for Tuesday.

34:29 Nobody was like, I should know this.

34:31 I could know I need it for Tuesday at 11.

34:32 That's what I need it for.

34:33 - Yeah, so, okay, next.

34:37 Okay, he says how to pronounce his name, but I still don't understand.

34:41 So Colin Valence, maybe Colin Valence, you think?

34:45 Anyway, asks, let's see, how would you suggest a non-traditional trained developer with the intermediate abilities learn proper skills for Python?

34:56 For instance, I struggle with tests because I haven't written code in a testable way.

35:02 CS concepts my mentor throws at me aren't very clear.

35:05 Okay, I got two options there that I think are a good place to start.

35:10 One is read Python Testing with pytest.

35:13 (laughs)

35:14 No, seriously, I think it's a good book.

35:16 I think introducing you to unlearn some of the weird lessons people have learned about testing.

35:22 That's one of the things that the book does is tries to help you think about testing better.

35:27 The other thing is Michael's got, there's a course called like Python the Pythonic Way or something like that, what was it?

35:36 - Write Pythonic Code?

35:38 - Yeah.

35:38 like 55 topics separate all with code examples and stuff.

35:43 Yeah.

35:43 >> It's totally fun.

35:44 Then also read other people's code.

35:46 Go read some of the top Python packages and read how their code works.

35:50 Those are my suggestions.

35:52 >> Yeah, those are good suggestions.

35:54 I would also follow up with just, I guess two things real quick.

35:57 One, nobody learns this stuff all at once.

35:59 You learn it one thing at a time.

36:01 >> Yeah.

36:01 >> So for example, he was talking about properties.

36:03 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.

36:10 Learning properties on its own is not a huge challenge, right?

36:14 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.

36:21 It's like a mountain, right?

36:22 But you don't climb a mountain in a leap, you climb it in steps.

36:26 Each one of those little steps is how you do it.

36:28 So don't let it overwhelm you because you solve it slowly, you build that up over slowly, over time.

36:34 And how do you know which to pick? Pick a project.

36:37 >> Yeah.

36:37 >> I gave my example, the Talk Python podcast.

36:40 I could have gone with some, I can't remember the names, I'm pod something or other, there's no fun.

36:44 But I created that project and I didn't go and try to learn all of the web framework I was using.

36:50 I just learned enough to like, okay, I need this page to show up.

36:53 Now I need to serve XML. How do I do that?

36:55 That's what I learned.

36:56 I didn't just learn an abstract.

36:58 I'm like, there's three more things I have to do until I'm done.

37:01 Start with thing one, let's get going.

37:03 How do I do that? It really narrows you down to the manageable bite-sized bits, I think.

37:08 >> I also think it's good to pick a small project, even if it's a toy project, and rewrite it several times.

37:16 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.

37:27 The other thing is, when I came from C background to Python, the data structures and how to iterate through data structures is way different.

37:36 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.

37:46 >> Yeah. Frederick also has a really good one that I didn't think of.

37:50 Modern lenters like Ruff and Flake 8 can help you writing Pythonic code in general because they will point out, you should be using a list comprehension for this or you should be using for each for in loop type thing.

38:03 Instead of this weird janky for loop you created out of range or something.

38:08 >> Turning on linters within VS Code or PyCharm or whatever you're using helps you.

38:15 If you see a little something going on, maybe there's something wrong and check it out.

38:21 >> Yeah. Pay attention to that. Absolutely. All right.

38:23 >> Next.

38:25 >> Jerry says, I think of me, could I inquire Michael about how you came to the decision to create the Talk Python platform further, what do you envision for its future?

38:34 >> Absolutely, you may.

38:36 I think we addressed a lot of that of the why.

38:39 Why did I create it?

38:40 There's a podcast I did with Dan Bader from RealPython over here.

38:47 It's really fun. We did this live at PyCon, well, sort of live, but all the software powering Talk Python courses and podcasts.

38:55 We talked for an hour and seven minutes about why did I choose this web framework?

39:01 Why did I choose this database?

39:02 Like, how do we deploy it?

39:03 What are the trade-offs?

39:04 And sort of compared that to real Python as well.

39:07 And that was super fun and people can check that out.

39:10 That's episode 215 on Talk Python.

39:12 A little bit old.

39:13 It's the last PyCon in the before days.

39:17 So-- - I remember walking by and watching you guys do that interview.

39:21 - Yeah, that was fun.

39:23 That was a lot of fun.

39:24 So that's the what and the how.

39:28 And what do I envision for its future?

39:31 Well, I think it's pretty stable, right?

39:33 We've got the podcast stuff is really working well.

39:36 I talked about some of the cool like additions we've added to sort of, you know, multiply it out, right?

39:41 Like from YouTube to the podcast page, to the social share, et cetera.

39:46 Those kinds of things are pretty dialed.

39:48 The courses platform-wise is I think really good.

39:51 You know, it's super stable.

39:53 There's things I could do to make it better, but they're playing right around the edges.

39:56 you know, like, oh, we could add a volume control with the memory of the volume is set in the web player.

40:02 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.

40:08 We got the brand new mobile apps, I just redid those.

40:10 So I honestly, I think the important part, and I kind of touch, it's like a little bit, like I said around, maybe don't build your own platform.

40:18 Important part for us is more content.

40:20 Like I'm really looking to build, work with more people and build some awesome courses.

40:24 We have a bunch underway that I don't want to commit to until they're really almost ready to release.

40:29 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, to that stuff.

40:40 So content more than platform, I guess, is what I see.

40:43 Okay.

40:43 Hey, we're, we're kind of running low on time.

40:46 but I'd like to get through some more.

40:48 Do you, are you okay with just jumping around?

40:51 whatever you want to answer.

40:52 Okay.

40:54 So this one comes from Aries.

40:56 Wait, no, from Adam.

40:59 And the question is, what does Brian actually do for work?

41:04 Is it top secret?

41:06 So I just want to like mention quickly, I did, I brought this up in my PyCascades talk, so that's on a video.

41:15 But I make these things.

41:16 So it's on the video.

41:18 I make work for a company called Rogen Sports, and I'm a team lead, team lead, but also do embedded work and test them.

41:25 But there are RF test equipment for wifi devices, wifi and cellular devices, and they get run in production product lines to test, make sure all the RF stuff works in your, in all of the goodies that you play, buy and play with.

41:40 But yeah, so that, that's the, that interface of just a whole bunch of ports out the front.

41:47 That's kind of why I don't really test user interfaces that much because the main, there's not a really user interface.

41:53 There is, there's a web interface to these, they're really pretty cool, but still.

41:57 - Yeah, it's always fun when software and hardware get together.

42:01 - Anyway, okay, what's the next question, Michael?

42:04 You wanna answer or?

42:05 - Let's see, and while I'm looking, I'll just point out, I know most people know, but podcasts, courses, that's my job.

42:11 No consulting, no other stuff at the moment.

42:13 Let's see, there's a couple here that we've already answered, so I don't wanna come back to them.

42:19 Let's go with one from Felix the cat, who Felix, we still got to have time for a super quick extra and a joke, Brian.

42:27 >> Okay.

42:28 >> Felix will make another appearance.

42:30 But why do you think people put so much effort and put so much rust into Python?

42:36 >> To make it fast. We used to use C, now we use Rust.

42:41 >> Yeah. I think that's more of a statement on Rust versus C than it is.

42:45 Anything to do with Python.

42:46 There are places in Python where because the way it works, it's just not that fast.

42:51 I said it's plenty faster 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.

43:01 That's milliseconds.

43:03 But if your job is to simulate certain physics algorithms, doing the math in Python is a bad idea or apply machine learning.

43:13 Just because in C or other languages, you have four bytes or you have eight bytes and they just jump on registers.

43:20 In Python, you have pointers, the things that point over to numbers that are high object derived longs and like floats.

43:27 And it's, it's just not even close to the same type of thing.

43:31 Right.

43:32 And so there's, we do got to make Python faster, right?

43:34 Yeah.

43:35 For certain scenarios.

43:36 And you see that a lot of times being applied, like the core of the new Pydantic is done in Rust.

43:42 I imagine it could also have been done exactly as well in C and they both, you know, the, the performance numbers are like 22 times faster.

43:50 So I think the motivation to go from Python to build the hotspots of the core pieces and something faster makes total sense and that's also why Python is fast enough.

44:00 Yeah.

44:00 Right.

44:00 It's Python all the way down.

44:03 It might not actually be fast enough, but it's not.

44:05 Yeah.

44:05 Yeah.

44:06 So I think it's, you probably have more insight this, so this than I do, But I think people are looking for something more modern than C, especially something memory safe, and Rust is a pretty good option.

44:16 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.

44:26 So, also, yeah, as David points out...

44:30 Shiny, it is shiny.

44:31 It is, it's shiny and new, even though it's called Rust.

44:34 But, anyway.

44:36 Yeah, yeah, we do love shiny new things.

44:39 - Well, should we-- - See JavaScript.

44:41 - Do some extras? - Let's do some extras.

44:43 You got any extras for us?

44:45 - Oh, just quickly, I want to remind people that Python People is live, and there will be--

44:51 there's another episode coming out today with Paul Everett from PyCharm.

44:56 And then also, testing code's still going.

45:00 So, anyway. But it did change, so if you see any problems, let me know. That's my extras.

45:05 - Nice. Yeah, Paul Everett is a great Python People, people. So I'm looking forward to listening to that. I have some as well.

45:12 There is a at the time of recording, this is still up. You never know what the time of listening we already described that latency there. So we don'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 and residents that Lukas Langa has been manning for a couple of years, doing an awesome job, making a big difference.

45:41 So much so that the PSF was like, what if we had more Lukas?

45:45 That'd be cool.

45:46 And so you could be a deputy, Lukas' deputy, as a CPython developer and residents.

45:53 Apply for that if that sounds cool for you.

45:55 I'll link to that in show notes.

45:56 - Cool, nice.

45:57 - Yes, and the Python web conference, Python web conf 2023 talks are online.

46:03 I think there are 80, yes, there are at least 80 videos of them.

46:07 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.

46:14 That's kind of the cliff notes for the full CDN course over at Talk Python Training that I did as well.

46:20 So people can check that out. I'll link to that as well.

46:23 >> Cool.

46:23 >> And that's it. So, ready for a joke?

46:26 >> I am ready.

46:26 >> This is not even so much a joke.

46:28 This was sent over by Felix the cat.

46:30 And it is the ode to Python.

46:34 There's a lot of pop-ups at Medium.

46:36 So this is an ode put together by Pete Fiston five days ago.

46:41 And I will do my best to do it justice.

46:43 Are you ready, Brian?

46:44 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.

46:50 My love is a language so fine, created by Guido Devine.

46:53 Duck typing in whitespace, she runs with sublime grace.

46:57 Now coding flows freer than wine.

46:59 With one simple import you see, I mastered anti-gravity.

47:02 Just one line of code and off we both rode, flying higher and further for free.

47:07 List comprehensions, oh my.

47:09 Make coding as easy as dot pi.

47:12 With one simple line, my code can now shine.

47:14 Make other languages sigh.

47:16 Thank you dear Guido, I say, for siring this language so bae.

47:20 Now understand, she's the best in the land, and I earnestly hoped she will stay.

47:25 >> Oh, I love it.

47:26 >> Here we are. It's not bad, is it?

47:27 >> It's good. I like it.

47:29 >> It is.

47:30 >> It is.

47:30 >> It's too big for a T-shirt, but maybe not.

47:34 >> I'll use a small font, just don't wash it.

47:37 >> It'll get fuzzy.

47:39 >> Well, thanks a ton for this wonderful fun episodes and thanks to everybody for sending in questions. We appreciate it.

47:46 >> Yeah, absolutely. Thank you everyone for sending in the questions and thoughts.

47:50 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.

47:58 >> Yeah.

47:59 >> Thanks.

47:59 >> Thanks, Brian.

48:00 >> Thank you.

48:00 >> Yeah. Bye, everyone.