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:09 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 So the links are in the show notes.

00:18 We've 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 11 a.m. 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.

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

01:05 And like I said, the opening, people who are in the live audience put out your questions.

01:09 And we'll see if we can intersperse them as well, because we really do appreciate having people here.

01:14 With that said, you know, 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.

01:25 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

01:32 audience and to the format of an AMA.

01:35 Or is it an AUA?

01:37 Ask us anything.

01:38 Whatever.

01:39 A little bit.

01:40 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 Wick.

01:47 Question is, Python Bytes is more focused on new events than either of your personal podcasts,

01:54 such as Talk Python, Python Friends, Test to Code, those things.

01:58 Does this affect your listeners' behavior?

02:00 For example, do most people download Python Bytes within a day or two versus longer?

02:04 And for that matter, I'm just really assuming your personal podcasts don't have the bulk of

02:08 the downloads on the day of release, which is an assumption we can test.

02:12 Ryan, 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.

02:20 And I also, I'm not sure about the right away versus later.

02:24 I'm guessing it's right away.

02:26 So I do have, I pulled up a graphic from the stats for testing code.

02:33 And testing code is, yeah, a lot of listens later on.

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

02:46 So when I, if like, if I release at 11 o'clock at night, that'll count as the day one, you know,

02:53 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,

03:07 so in total three to 5,000 downloads for the first couple of days, testing code normally gets six to 10,000.

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

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

03:30 Statistics for podcasts are so interesting.

03:32 Like they're, they can get compared to things like YouTube views and stuff.

03:37 But I feel maybe, maybe I'm wrong, but I feel like people have a deeper connection,

03:41 a deeper investment in podcasts.

03:44 You know, there's not like screaming thumbnails that'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,

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

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

04:13 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

04:25 happen upon it and listen to it.

04:27 Right.

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

04:34 The CDN goes to, you know, gigabit levels, high gigabit levels of bandwidth in the first hour.

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

04:48 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 Right.

04:53 So it's, 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.

05:02 And they probably cherry pick our other shows.

05:04 Like that topic's interesting.

05:05 Eh, interesting for some people, but not for me.

05:09 So I'm skipping that.

05:09 Right.

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

05:12 I encourage everyone to listen right away.

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

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

05:21 But I also understand, you know, 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:33 Yeah.

05:34 Yeah.

05:34 Okay.

05:35 Well, so the next question comes from us from BL.

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

05:53 Despite the popularity of Go and capabilities of Rust and C, Python fits my brain and I love it.

05:58 I love the community.

06:00 We do.

06:00 We do too.

06:01 Crazy.

06:02 Am I crazy to remove non-Python languages from my resume and LinkedIn?

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

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

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

06:21 Yes.

06:23 And I have a fork in the road type of situation.

06:26 Look, if you are, 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.

06:37 I think more routes in different directions might lead to something, right?

06:43 And that's, 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.

07:06 Like, no, I don't want it.

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

07:13 Maybe, maybe divide that by two.

07:15 But there's like a good number.

07:16 You're going to have an unreasonably high amount.

07:19 You 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 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.

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

07:38 Oh, he also does some Python.

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

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

07:55 Probably most of the time.

07:57 Right.

07:57 And so you're probably not doing yourself a favor advertising like all these options.

08:02 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 want to be than trying to play in all of the areas.

08:13 That's that's my personal thought.

08:15 Yeah.

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

08:23 I was in I do a lot of hiring.

08:25 I was talking with this over with another manager, higher up manager.

08:30 And he said that his preference is highlight the ones you want to work on.

08:34 That's great.

08:36 But list list list the other technologies you've been in that you just not 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 because that's what we 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.

08:57 Yeah, sure.

08:57 Like I have no idea what a pointer is.

08:59 And yeah, 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:08 You can leave it on LinkedIn if you want to like help catch, you know, catch bites with LinkedIn.

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

09:17 So that that three months that I worked on C# system, I'm not going to put it on my resume because that's 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.

09:30 And that would be weird to list that as a skill set if I only did it for a little while.

09:37 But that's my opinion.

09:39 Highlight what you want to work on, but don't take everything off.

09:42 But then the extreme is I've seen people with like 16 languages on their resume and that's like ridiculous.

09:48 You're not an expert at 16 languages.

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

09:57 Right.

09:57 I think I think those are different.

09:59 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 And I do agree with that, but I think it's highlighting experience, but really point out, like you say, that's a good, good way to put it, Brian's focus on like I want to work on X.

10:15 Yeah.

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

10:18 Yeah.

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

10:21 But yeah, I did Fortran.

10:22 Same.

10:23 I did it against my will.

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

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

10:28 Okay.

10:28 So 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.

10:36 So congrats on that, Doug.

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

10:45 So let me read into this.

10:47 Like, will we have a GIL less Python soon?

10:50 I don't know, actually.

10:51 You know, Sam Gross's work and all the stuff happening around Cinder and Facebook.

10:56 It's very, very exciting.

10:59 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 Yep.

11:09 Yes.

11:09 And there was hardly anything else.

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

11:19 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 kind of because of the ecosystem.

11:30 I have this kind of golden handcuff to the past, in a sense.

11:33 And we have the same problem.

11:34 And 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.

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

11:58 So I vote 57.5% likely versus, you know, what is that, 42.3% unlikely.

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

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 blocks.

12:30 You say for this code, we're going to put into a context manager, like a width 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 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 they solve it.

12:53 That sounds horrible when you, 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 an event, event driven systems in real time systems and stuff.

13:07 And the architecture is such that when we're in the code that we know our code is, it's an event that's happening.

13:14 We know there's only one thread running.

13:16 So I don't usually have to deal with that and how I deal with talking with other threads or other processes.

13:22 Well, we have like message cues and stuff like that.

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

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

13:36 If you want to, you don't always have to think about it.

13:39 And 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 you know, it's not hard.

13:46 And then there's also functional programming.

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

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

14:01 Yeah.

14:01 If it's, if you have no shared state, then you have no cross threads.

14:04 It's no problems.

14:06 It's about managing the shared state.

14:07 Yeah.

14:08 All right.

14:10 My, my next.

14:11 Well, yes, but just Liz out there says, I think it makes sense to have a GIL as Python become Python four, 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 four is a word that's just like verboten.

14:29 Like we won't speak it, you know?

14:31 All right.

14:31 Onto the next one.

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

14:34 Oops.

14:35 Like maximize the window on my screen.

14:37 I can't see anything.

14:38 Okay.

14:39 Here we go.

14:39 Somebody down the list asked about Python four.

14:44 I can't remember who, but anyway, so we just got, had brought up Python four.

14:48 Do you think Python four will ever happen?

14:50 And my answer is no, I don't think it's going to happen.

14:53 And it was a lot of numbers in that three dot that that second part can get real big.

14:59 Yeah.

14:59 And I'm just taking it from listening to a recent interview with Brett Cannon on changelog.

15:05 He was asked that when's Python four coming around?

15:07 And he said, Python two to three was so painful that I don't think we'll do a four, at least not for a while.

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

15:22 Yeah, exactly.

15:23 Just avoid it altogether.

15:24 It's the 2023.

15:25 But do you want to, should we do the, let's see.

15:28 Oh, I want to do the next one.

15:30 Do it.

15:31 So Nick Cantor says, what would you recommend for hosting a brand new podcast?

15:36 Do it yourself or a SaaS platform?

15:38 Or what would you use?

15:40 And he said, I'm particularly interested in being able to migrate someday without having to lose URLs and such.

15:49 So I'm guessing that Michael would write his own system.

15:52 Do it yourself.

15:54 Well, you know what?

15:55 Maybe.

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

16:12 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:19 This does not happen.

16:21 If you go with some SaaS platform or whatever, right?

16:24 You're lucky to get like a crummy 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, oh, it's not too bad.

16:45 Right?

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

16:57 And it was super fun.

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

17:00 The maintenance life cycle of it.

17:02 There's something you got to keep in mind.

17:03 But it was fun.

17:04 But I very much might choose something like Fireside or I know, Brian, you're a fan of Transistor FM these days.

17:10 The reason is you get to focus on the actual thing that people want to hear.

17:15 Building your podcasting craft and working that.

17:18 Well, I guess I want to put it in a couple highlights.

17:23 There's hosting your platform for your podcast.

17:26 And then there's your website.

17:28 So I've used Fireside and now I've switched to Transistor.

17:33 And I switched testing code from Fireside to Transistor.

17:36 And I'm starting Python people out at...

17:40 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:51 I mean, it's not terrible, but it's not bad.

17:53 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 listed in like two guests so far.

18:01 I need more.

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

18:07 Yeah.

18:07 It's no joke.

18:08 It's just data entry.

18:09 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.

18:16 So that's the website part of it.

18:17 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 them and everything,

18:28 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 want to 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 Michael's.

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

19:06 Those are the things.

19:08 So Michael's willing to maintain it.

19:10 Yeah.

19:10 And like I said, it's something that I get to do as a playground.

19:14 And also we get to experiment with podcasting, right?

19:17 With like 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.

19:28 And it uses that YouTube thumbnail for social shares.

19:31 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 can 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:58 So I would just say control your domain, basically.

20:01 Make sure you don't just use like, you know, nick at 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 going to get from the feed, the RSS feed that's feeding your podcast players.

20:24 And you can redirect and move those.

20:28 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 Yep.

20:32 Just use your own domain.

20:33 I would say also, this may sound very niche.

20:37 Like I know not many of our audience members are creating a podcast right now and considering this.

20:41 However, like this sort of 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.

21:05 What if you like it or not?

21:06 Indeed.

21:07 All right.

21:07 Am I up next?

21:08 Yeah.

21:08 Are you?

21:08 I think I read the last one.

21:10 Yeah.

21:10 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#.

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

21:25 Maybe you need true concurrency.

21:26 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 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:40 I still write Bash scripts.

21:44 I would like to try Rust at some point because it looks like it might be more fun than it's because it's shiny and new and it looks fun.

21:53 But I don't know.

21:54 Yeah, that's cool.

21:55 I would start by thinking about do I need a systems language?

21:58 Do I need a UI language?

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

22:03 So 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.

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

22:21 Neither of them are JavaScript, by the way.

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

22:30 But it turns out most things that Python is good at or C# is good at that I might need.

22:36 Python is also really good at it.

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

22:42 Maybe not desktop apps.

22:43 That's something else.

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

22:47 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:55 Lauren, the main developer, and a little bit of poking around for me.

23:00 But I think that's also a really nice framework.

23:02 It's a little, I don't mind statically type languages.

23:05 It's a little over the top, like constant.

23:07 You have to have, if you have a variable or a parameter that's a constant, you have to like

23:11 start further up in your program that that's a constant.

23:15 And if like you change the function because you need to modify it, then the place that

23:19 started from has, is there like a weird bunch of like cascading effects that go on and that

23:23 drive me nuts.

23:24 But every language will drive you nuts in its own way.

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

23:30 Yeah.

23:31 But that said, I think a lot of people say, I've heard Python is the second best language

23:35 for so many things.

23:37 And that's why it's so popular.

23:38 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:42 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:49 But for my web apps, there's no other language that I think is better.

23:53 I might be able to squeak minor performance improvements out of one other language in some

23:58 way or, but it's, it goes well beyond easily handling with extreme reliability.

24:04 Like it always run for months at a time if I don't need to touch it.

24:07 High performance.

24:08 It's, it's a fantastic language and it's only getting better.

24:12 Getting better because of the, the C faster CPython team.

24:15 And it's getting better because the language features like async and await make more things

24:19 possible.

24:19 So I, I don't necessarily subscribe to the, well, we all use Python because it's the second

24:25 best choice, but it's flexible, right?

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:32 You help, you know, you're going to need some help if you want to build a desktop app with

24:36 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, right?

24:41 You're going to need some weird niche thing.

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

24:48 The other thing is it's not really one language.

24:50 we, even if you program just in Python, your modules that you're pulling in are possibly

24:57 written in rust or C or Fortran.

25:01 there's a lot of other languages that are really, that are, compiled down and we

25:07 pull in as wheels and don't think about it.

25:09 But, I use a lot of, I use a lot of, a lot of rust now, even though I've never written

25:14 our line of rust because of modules written in it.

25:17 So same with C.

25:18 I use a lot of C.

25:19 Yeah.

25:19 Cause of CPython.

25:20 Right.

25:20 But anyway.

25:22 All right.

25:23 That's good questions.

25:24 The honest, I see them, but we got to keep moving.

25:26 We got questions.

25:27 Yeah.

25:28 We got more to get through.

25:29 Lots.

25:29 Okay.

25:30 so, I think we're on astro boy.

25:34 hi, Michael and Brian.

25:37 How did you two meet each other and how did you become friends?

25:41 please tell us the story.

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

25:44 we'll see if our recollections match from like so many years ago.

25:49 So, when, when Michael started talk Python, I was thinking about starting testing code,

25:56 which at the time was Python, the Python testing podcast until I was tired of saying that.

26:02 but he, so he, he started talk Python.

26:04 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 cause I was blogging.

26:17 and so I decided to support him and help promote Michael, cause I liked what, what

26:22 he was doing.

26:23 and then when I started, finally started Python, the Python testing podcast, Michael

26:29 helped promote my stuff.

26:30 so we were promoting each other.

26:32 And then I don't remember how long after that Michael contacted me and said, Hey, I'd like

26:38 to do this Python bites thing.

26:40 That's a thing together.

26:42 Maybe we could do it.

26:43 Probably a flash in the pan.

26:43 Maybe it'll be around for a couple months.

26:45 and I think we like went out and hashed out the details, which aren't, weren't much.

26:51 at lunch, we, we ate some German food, I think, talked about it.

26:56 I think that's, yeah, exactly.

26:57 You said, Hey, I think you said, Hey, I have some questions about starting my podcast,

27:03 you know, and I said, Hey, well, how about instead of just emailing, like we live five miles

27:07 apart, let's meet for some lunch.

27:08 And yeah, started there.

27:09 It was great.

27:09 Yeah.

27:10 Yeah.

27:10 So we, we met over the podcast and then we really got to know each other because we were

27:15 both excited about doing new podcasts.

27:17 We're both in the same space and I, we want to do this Python bites thing.

27:21 So I'm like, why don't we just do this together?

27:23 This would be fun.

27:23 And then often we will, after the, after we wrap up this episode or a episode, if, if one

27:29 of us has time, and we want to 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

27:39 have outside of PyCon in person.

27:42 I know it's nuts.

27:43 Even though we have close to life, we live like half an hour away from each other or less.

27:47 So I know, but to get together more, I think COVID really put a whacking onto the, you

27:54 know, like get together every now and then for lunch and stuff.

27:56 And then, yeah.

27:57 Yeah.

27:58 But I, I definitely do think of Michael's a, as a friend, even though we don't chill and

28:01 in meat space that much.

28:03 So yeah, absolutely.

28:04 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:11 Hey, Will, what are your favorite and your least favorite parts about making a podcast?

28:16 Oh, you go first.

28:17 All right.

28:18 My favorite part is the actual doing of the podcast.

28:20 Like this conversation is super fun.

28:22 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.

28:29 It's awesome.

28:30 It's so gratifying.

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

28:35 We often say it right, Brian, like somebody in the audience will clarify this for us.

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

28:43 Or what, 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 of the podcast favorite, maybe the editing is, is one of the things

28:55 that's pretty tough.

28:56 I mean, for talk Python, I do have an editor for Python bytes.

28:59 I don't, 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

29:11 it out.

29:11 Right.

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

29:13 So I would say very least favorite dealing with bugs like this won't play.

29:17 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, it's not so terrible and yeah, shipping the podcast, but there's

29:35 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:55 Yes, but we still need, you know, like that, that, like here's your, here's your whole

29:59 contract negotiation.

30:01 Like, you know what?

30:01 Maybe this is not worth it in terms of that particular guest.

30:04 Right.

30:04 So there's, there's stuff that nobody sees.

30:07 That's like a drag, but the stuff that people see, that's a fun part for me.

30:11 Right.

30:11 Yeah.

30:12 the, just hanging out, talking, that's definitely my doing it.

30:16 My favorite part.

30:16 the other, also, I guess this is general kind of a meta around it, going to PyCon

30:23 or PyCascades or something and having somebody, recognize me or hear my voice and say,

30:29 Hey, are you Brian?

30:31 I love that.

30:32 It's so cool.

30:32 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 that's kind of neat.

30:40 I, I also really like learning new stuff and Python bytes gives me an excuse.

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

30:50 test and code is more stressful, than Python bytes.

30:54 Talk Python is like five times more stressful in terms of effort.

30:57 Yeah.

30:57 Yeah.

30:57 So least favorite about Python bytes.

30:59 There's not much to not like, we've designed it to be how we want it.

31:03 So.

31:03 Yeah, absolutely.

31:04 Frederick out in the audience points out that maybe someone will make a pod GPT to edit

31:10 your audio automatically soon.

31:11 There is some interesting AI stuff out there, but careful.

31:14 That's one step away from just replacing us.

31:16 So.

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

31:19 That is true.

31:20 Yeah.

31:23 Okay.

31:24 All right.

31:24 What's next?

31:24 let's see, Thomas, Zumsteg.

31:29 How would you address Python's long-term limitations?

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

31:33 All right.

31:34 Let's have it.

31:34 Train the next generation.

31:35 make sure that you're teaching the people around you so that, the next generation

31:40 could solve the long-term limitations.

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

31:44 Well, also those are being solved slowly, but surely, you know, as things like async and

31:50 await are added and other aspects of the language, they allow you to solve it.

31:53 They're going 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,

32:01 those problems might be solved, but they might not be solved for you.

32:04 You know what I mean?

32:04 Yeah.

32:05 That said, I do agree that, you know, 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 Right.

32:12 I know there's Kivy.

32:13 I know there's Toga.

32:14 there, I think those are really, really specialized.

32:17 They're not a hundred percent really ready to ship production apps.

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

32:23 Right.

32:23 Yeah.

32:24 Yeah.

32:25 So, some of them I think is a community thing.

32:28 Like Carol Willian had a great keynote where she spoke about, as, did Russell Keith McGee,

32:33 different keynotes spoke about some of the, the places where Python is not taking advantage

32:40 of what it could be.

32:41 Right.

32:42 The black swan events like, that Russell Keith McGee spoke about.

32:45 And then, you know, Carol called out specifically focusing on a mobile, I believe desktop as well

32:50 as like, we're really leaving a lot on the table by not having an option here.

32:54 So community.

32:55 Yeah.

32:56 all right.

32:57 Next for me.

32:58 I got the next one, right?

32:58 I think so.

32:59 All righty.

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

33:03 We can go quick on this one.

33:04 Cause we kinda, 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 kind of talked about that as well, but how much time does it take to prepare for each

33:15 episode for?

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

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

33:22 for, for Python bytes, one to three hours, probably more closer to the one hour

33:29 to prepare.

33:30 and then for testing 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.

33:39 And I would say for Python bytes, probably an hour as well for me.

33:42 And then to get it fully polished and release another two hours after that.

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

33:51 Right.

33:52 Especially for this show, because like last night I was flipping through Flipboard and I

33:55 saw, oh, there's a big Cython giant Cython re-release for Cython three.

33:59 That's supposed to change a bunch of stuff.

34:01 Like, 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,

34:06 10 minutes here and then, then I'll come back.

34:07 Right.

34:09 So we kind of like are always, always have these nets trolling through the, the announcements

34:12 and stuff.

34:13 Yeah.

34:13 And probably, probably spending 20 to 30 minutes a day, every day, paying attention

34:18 to what's going on.

34:19 Yeah.

34:20 But you would do that as a developer that cares about your career for a large part anyway.

34:24 Right.

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

34:27 Like I need this for Tuesday.

34:29 Yeah.

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

34:30 I could know.

34:31 I need it for Tuesday at 11.

34:32 That's what I needed for.

34:33 Yeah.

34:34 So, okay.

34:35 next.

34:36 okay.

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

34:40 so Colin the lens, maybe Colin the lens.

34:44 Do you think?

34:45 Anyway, asks, let's see.

34:48 How would you suggest a non-traditional trained developer with the intermediate abilities

34:53 learn proper skills for Python?

34:55 for instance, I struggle with tests because I haven't written code in a testable

35:01 way.

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

35:05 Okay.

35:06 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 No, seriously.

35:15 I think it's a good book on introducing you, to unlearn some of the weird lessons people

35:20 have learned about testing.

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

35:26 better.

35:27 the other thing is Michael's got my, my, there's a, there's a course called like

35:33 Python, the Pythonic way or something like that.

35:35 What was it?

35:36 Right.

35:37 Pythonic code.

35:37 Yeah.

35:38 Which covers like 55 topics, several, all with code examples and stuff.

35:43 Yeah.

35:43 It's totally fun.

35:44 And then also read other people's code.

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

35:50 yeah, those are my suggestions.

35:51 Yeah.

35:52 Yeah.

35:53 Those are good suggestions.

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

35:56 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, like if properties are important to you or you

36:05 see them showing up in a place where you really need to know them to use them, you know,

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

36:18 I should know.

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

36:24 You climb it in steps.

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

36:31 You build that up over slowly over, over time.

36:34 And how do you know which to pick?

36:36 Pick a project.

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

36:40 I could have gone with some, I can't remember the names of them, pod something or other.

36:43 There's no fun.

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

36:49 I was using.

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

36:53 Now I need to serve XFL.

36:54 How do I do that?

36:55 Like that's what I learned.

36:56 And I didn't just learn it abstract.

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

37:00 I start with thing one.

37:02 Let's get going.

37:02 Like, how do I do that?

37:03 Right.

37:03 And so it really narrows you down to like manageable bite-sized bits.

37:08 I think.

37:08 I also think it'd be, it's good to pick a, a small project, even if it's a toy project

37:13 and write it, rewrite it several times.

37:16 try to, try to get as much, just whatever you can hack together to make it work.

37:21 Then learn some more stuff about Python and then go back and edit it.

37:24 And you'll realize that you've learned some different things.

37:27 The other thing is when I came from like C background to, Python, the data structures

37:32 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

37:41 try to think in Python instead of thinking and see and translating to Python or something

37:46 like that.

37:46 So yeah.

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

37:50 Modern lectures like rough and flake eight can help you writing Pythonic code in general,

37:54 because they will point out, Oh, you should be using a less comprehension for this, or you

37:59 should be using a 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 And turning on, turning on linters within, within VS Code or, or PyCharm or whatever

38:14 you're using helps you.

38:15 So if you see a little, little something going on, maybe there's something wrong and

38:20 check it out.

38:21 Yeah.

38:21 Pay attention to that.

38:22 Right.

38:22 Absolutely.

38:22 All right.

38:23 Next.

38:24 is that, you, Jerry says, yeah, I think of me.

38:27 Could, could I inquire Michael about how you came to the decision to create the talk by them

38:31 platform further?

38:32 What do you envision for its future?

38:34 absolutely.

38:35 You may.

38:36 So I think we addressed a lot of that of the why, right?

38:39 Like why did I create it?

38:40 Right.

38:40 there's an art, a podcast I did with Dan Bader from real Python over here.

38:47 It's really fun.

38:48 We did this live at PyCon.

38:49 Well, it's sort of live, but, all the software powering talk Python courses and podcasts.

38:54 And we talked for, how long is that?

38:57 Talk 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, and sort of compared that to real Python as well.

39:07 And that was super fun.

39:07 And people can check that out.

39:09 that's episode 215 on talk Python.

39:12 It's a little bit old.

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

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

39:21 yeah, that was fun.

39:22 That was a lot of fun.

39:23 So that's, that's the, the what and the how.

39:27 And, what do I envision for its future?

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

39:33 We've got the, the podcast stuff is, 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, those kinds of things are pretty dialed.

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

39:51 You know, it's, 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, 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 of you.

40:05 Like, well, my computer is a volume, so I'll use that.

40:07 we've got the brand new mobile apps.

40:09 I just redid those.

40:10 So I don't, 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:17 The importance part for us is more, 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:49 Do I'm, are you, you, you, you're just jumping around.

40:51 whatever you want to answer.

40:52 Lightning around.

40:53 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:05 so I just want to like mention, quickly I did, I brought this up in my, my pie cascades talk.

41:14 So that's on a video, but I make these things.

41:16 So, it's on the video.

41:18 I, I make, work for a company called Roden sports and I'm a team lead, but also do embedded

41:24 work and test them.

41:25 but their, RF test equipment for, wifi devices, wifi and cellular devices.

41:31 And they get run in production product lines to test, make sure all the RF stuff works in

41:37 your, in all of the goodies that you play by and play with.

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

41:45 ports out the front.

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

41:52 user interface.

41:53 So anyway, there is, there's a web interface to these.

41:55 They're really pretty cool, but still.

41:57 Yeah.

41:57 It's always fun when, software and hardware get together.

42:01 Anyway.

42:01 Okay.

42:02 What's the next question, Michael, you want to answer or let's see.

42:06 And while I'm looking, I'll just point out, like, I know most people know, but podcasts

42:09 courses, that's my job.

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

42:13 Let's see.

42:14 There's a couple here that we've already answered.

42:16 So I don't want to come back to them.

42:18 let's go with one from Felix, the cat who Felix, we still got to have time for a super

42:25 quick extra and a joke, Brian.

42:27 So Felix will make a, another appearance, but what do you think?

42:31 Why do you think people put so much effort and put so much rust into Python?

42:36 To make it fast.

42:37 we, we used to, 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 anything to do with

42:46 Python, right?

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.

42:54 And that's true in my world where I'm talking to a database, crunching a bunch of stuff with

42:58 Pydantic and then shipping off some dictionaries, right?

43:01 That's milliseconds.

43:03 But if your job is to, you know, simulate certain physics algorithms, right?

43:09 Doing the math in Python is a bad idea.

43:11 Right.

43:11 Or, or apply machine learning just because in C or other languages, you have four bytes

43:17 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

43:26 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:35 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

43:42 rust.

43:42 I imagine it could also have been done exactly as well in C.

43:46 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

43:56 something faster makes total sense.

43:57 And that's also why Python is fast enough.

44:00 Yeah.

44:00 Right.

44:01 It was 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 to this than I do, Brian, but I think people

44:11 are looking for something more modern than C, especially something memory safe.

44:14 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

44:22 solid.

44:22 So there's examples, modern examples for how to do it.

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

44:30 Shiny.

44:30 It is shiny.

44:31 It is.

44:32 It's a shiny and new, even though it's called Rust.

44:34 But anyway.

44:36 Yeah.

44:37 Yeah.

44:37 We do love shiny new things.

44:39 Well, should we do some extras?

44:42 Let's do some extras.

44:43 You got any extras for us?

44:44 Oh, just quickly.

44:46 I want to remind people that Python people is live and there will be, there's another episode

44:52 coming out today with Paul Everett from PyCharm.

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

45:00 So anyway, but there, it did change.

45:03 So if you see any problems, let me know.

45:04 That's my extras.

45:05 Nice.

45:06 Yeah.

45:06 Paul Everett is a great Python people.

45:08 So I'm looking forward to listening to that.

45:10 How about you?

45:10 I have some as well.

45:11 There is a, at the time of recording, this is still up.

45:15 You never know.

45:16 With the time of listening, we already described that latency there.

45:19 So we don't control that.

45:21 But right now, the PSF, I don't know for how long this will be up.

45:24 Maybe it says somewhere that the deputy CPython developer in residence position is a position

45:30 that can be now applied for.

45:32 So we've got the CPython developer in residence that Lucas Lange has been manning for a couple

45:38 years, doing an awesome job, making a big difference.

45:41 So much so that the PSF is like, what if we had more Lucas's?

45:45 That'd be cool.

45:46 And so you could be a deputy, Lucas's deputy, as a CPython developer in residence.

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

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

45:56 Cool.

45:56 Nice.

45:57 Yes.

45:57 And the Python Web Conference, Python Web Conf 2023 talks are online.

46:03 I think there are 80.

46:04 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

46:11 is a really fun 42-minute talk that I gave that's kind of the cliff notes for the full

46:18 CDN course over at Talk Python training that I did as well.

46:20 So people can check that out.

46:21 I'll link to that as well.

46:22 Cool.

46:23 And that's it.

46:24 So ready for a joke?

46:25 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:35 So this is an ode put together by Pete Fiston five days ago.

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

46:43 Are you ready, Brian?

46:44 I am.

46:45 I think this is a fitting one to do here at the end of the show on this sort of look back

46:49 type of episode.

46:49 My love is a language so fine.

46:51 Created by Guido, divine.

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

46:56 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 Bliss comprehensions.

47:08 Oh my.

47:09 Make coding as easy as .py.

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

47:20 Now understand, she's the best in the land.

47:23 And I earnestly hoped she will stay.

47:25 Oh, I love it.

47:26 It's not bad, is it?

47:27 It's good.

47:28 I like it.

47:28 It is.

47:29 It is.

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

47:34 I'll use a small font.

47:35 Just don't wash it.

47:36 It'll get fuzzy.

47:38 So, well, thanks a ton for this wonderful, fun episodes.

47:42 And thanks to everybody for sending in questions.

47:45 We appreciate it.

47:46 Yeah, absolutely.

47:47 Thank you, everyone, for sending in the questions and thoughts.

47:49 And I know there are many more out there who did not send in a question, but who appreciate this show.

47:54 And we really appreciate you all listening.

47:56 And let us keep doing this, basically.

47:58 Yeah.

47:59 Thanks.

47:59 Thanks, Brian.

48:00 Thank you.

48:00 Yeah.