#310: AMA (Ask Me Anything) with Michael Transcript

00:00 The tables have turned in this time, I'm the guest, and you all are the hosts. I get tons of questions over email and Twitter asking me about my thoughts on various trends, tools, and behind the scenes questions around talk Python. So I've enlisted two listeners who are up for hosting a conversation and taking questions from you all. Thank you to Patrick Louisville and Kim van wyck, who guest hosted this episode, where I answer a bunch of audience questions in this Ask me anything. This is talk Python to me, Episode 310, recorded March 31 2021.

00:44 Welcome to talk Python, a weekly podcast on Python, the language, the libraries, the ecosystem and the personalities. This is your host, Michael Kennedy, follow me on Twitter, where I'm @mkennedy and keep up with the show and listen to past episodes at talk python.fm and follow the show on Twitter via @talk python. This episode is sponsored by OutSystems and us over at Talk Python Training. OutSystems is a new sponsor with a really cool product. So please check it out with the link in the podcast player show notes. We'll be giving away five tickets to attend PyCon US 2021. This conference is one of the primary sources of funding for the PSF. And it's going to be held may 14 the 15th. Online and because it's online this year, it's open to anyone around the world. So we decided to run a contest to help people especially those who have never been part of Python before attended this year. Just visit talkpython.fm/pyCon 2021. And enter your email address and you'll be in the running for an individual PyCon ticket complements of talk Python. These normally sell for about $100 each. And if you're certainly want to go I encourage you to visit the PyCon website, get a ticket and that money will go to support the PSF and the Python community. Congratulations to Janine van nine Kirk,Janine won the fourth of the five tickets that were given away for Python, and there's still more chances to win. If you want to be in this drawing, just visit talkpython.fm/pyCon2021. Enter your email address. You'll be in the running to win a ticket. Now let's get on to that interview. Patrick are welcome to talk Python me.

02:17 Thanks. Thanks for having us.

02:18 Thanks for the invitation.

02:19 Yeah, it's a should I say thank you for having me. It's different, right? This is a unique one. So thank you both for being here. I've selected you to represent the audience in this Ask me anything episode, which should be a lot of fun. So yeah. Cool. It's great to have you both here and helping out with that. Yeah, looking forward to should be good fun. Yeah,

02:37 definitely.

02:38 I agree to you. You're sort of guests on the show till you turn the tables, I suppose. So let's do a quick introduction. Just a little bit of background about yourself. Kim, I'll let you go first. How did you get into programming? And how did you get over here onto this show?

02:52 The interview me shouldn't tend to programming I been Oh, I'm a electronic engineer by training. And I did Electronic Engineering type work for 13,14 years or so. Mainly producing television satellite decoders that a facility based in Durban in South Africa. So we made satellite decoders and I did all sorts of areas on that with C and low level embedded programming and so forth, but slowly moved my way into PC programming. And for the last couple of years, I've actually been full time software development using Python mainly for DevOps work. Although DevOps means different things to different people. In my case, it's process automation. And industrial is not the word I'm looking for with process automation and infrastructures code as the word I'm looking for. That's the right thing to do. So I've been probably writing Python since University days, which is not terribly far off 20 years ago. So I've been using it for quite a while.

03:39 Yeah, those are pretty early days of Python. You know, that's at least two thirds of its life there. Right?

03:43 Yeah. It was 2.3 2.4. Something I get.

03:46 Yeah, absolutely. Well, that sounds really fun. And were you happy to be moving away from more low level stuff? Or do you miss it?

03:52 I don't miss it a great deal. I don't miss writing. See, but I enjoyed it when I did it. But I don't. I don't know if I'd go back to it now. But yeah, I thoroughly enjoyed the kind of thing I do. Now.

04:01 I feel the same way. I did a bunch of C Programming at the beginning. And I'm really glad I had that experience. I'm also really glad I don't have to continue having that

04:07 experience.

04:09 Awesome. All right, Patrick, how about yourself,

04:11 I don't have the experience that you guys have. But I think my first course in programming was during my physics studies where I had a C++ course just basic introduction. And I didn't really I liked the idea of programming, but I didn't like the language that much. During my PhD. I was mostly working with Mathematica, also some C++ and old Fortran code for simulations. But after my PhD, I started as a traffic planning in a traffic planning company as a transport model and data analysts and modeling like traffic and stuff like that, like traffic lights, traffic, traffic, traffic modeling for cities and areas and stuff like that. Yeah, even some countries give a four a six.

04:55 Is that where the Audubon names they're from clogging up or more cities Yeah,

05:00 well, they're always a big part. Yes. Modeling that's up because that's the most interesting form some of the economic companies there is. I think my first test there was like converting some old VBA code to Python that transferred structural data from an Excel database to another program, which was horrible. Yeah, it was absolutely horrible. And I immediately realized that I hated VBA. And love Python. That's where I stuck. And late I joined Germany's biggest block store company. And now they're a data engineer for tracking data, mostly working with Python. And the Hadoop, Pyspark ecosystem. Yeah,

05:37 I so you live pretty solidly on the Big Data data science side of Python. Yeah, I'm more of a data science data engineer more data engineering thoughts, really a lot of software engineering. I recently had Tobias Macy on the show. We talked about the whole data engineering landscape. And it's really interesting, I kind of lost track of paying attention to the the data pipeline stuff. And there's a lot of neat tools that are coming out in that area.

06:00 Yeah, there is, actually but it's always hard to migrate from an existing infrastructure to something new, but you always have to. So it's a steady flow of new stuff that's coming in. We have to adapt.

06:10 Yeah, absolutely. All right. Cool. Well, thank you both for being here. Let me just give a quick summary of this. Ask me anything episode. For people watching and listening, though people ask me questions all the time, they'll shoot me a message over email, say, Hey, here's the thing you should check out or this is interesting. I got a quick question. Oh, by the way, here's some question about the podcast in this way, or that those have obviously been building up over time. So I thought it might be fun to just let you guys come on, and basically ask those questions and you to get to be the audience or for everyone out there. And so we collected some questions. Previously, I tweeted this out and maybe mentioned on one of the podcasts, let people fill out a form and ask their question, which is actually how you two got here, right? Because you both exactly asked a question. And there was a checkbox Would you like to be the interviewer of this whole thing? And that's great. And so what we're gonna do is we're going to start with some of those questions we collected previously, but then I can see people like Hong and Daniel and Sam, all in the audience and other people coming in. So maybe there's gonna be some questions from the livestream that we do on YouTube as well. So Edrick I guess we can kick this off. And what's, what's the first question?

07:20 So the first question is by Martine Burruss, so a little bit of background, so he's listening from Germany? So

07:28 yeah, sorry. Let me also add, like everyone put a little tiny bit of background about themselves. And so just kind of make them more part of the show as well. These guys will like fill that in just a tiny bit as well. Yes. Go ahead. Yeah.

07:39 So he's listening from Germany. So hello, from Germany to Germany. I think I started around 2016. I love the shows wide range of Python related topics. And also the sound quality is usually very good. Yes, that's true. And yeah, the question is, what's the first Python code you ever use professionally, or got paid for? And is it still in production?

07:59 And it's a great question. So what is the first Python code that I wrote in production? Well, the first that I got paid for. So really, when I started into Python, I was working as a full time as a software trainer. So I would go around and teach courses. And I used to previously do C# and .net, and C++ and stuff, and was super happy to move over to Python and do more of that, too. The first things that I did around that space was really like a bunch of little example projects and things I kind of explored so that I could teach those ideas to other people. So it's, I don't know, it's possible, someone took that and put it into production. But it's not really the type of code like, Oh, I deployed this one website, or I built that website. And then, you know, after that, I started realizing just how neat and powerful Python was started doing some little small projects with it. And probably the thing that's still around, honestly, is talk Python, the site itself is the oldest piece of Python code that I've written that still around and doing anything. Yeah. So I think that's probably the first one back in the day. You know, it's tricky. I wasn't working at the time writing that much software as a software developer, when I found Python, I would say, so there you go.

09:13 I would say probably suggest quite a lot of us who write Python, a lot of our Python, if it's still in production was only ever run once or twice because it was a quick script to fix some problem that the rest of the system had, and so forth. So it's still around, but not necessarily ever looked at again, because it fixed the problem. And it was solved.

09:30 Exactly. Yeah, I've got a huge folder of like, these are the things I need to run to solve problems or get like a little reports really quick. And I honestly forget if they even exist, you know, like I pretty sure a couple years ago, I wrote this thing that'll you know, I'll put the state or summarize this for me, and I could do it again. But maybe I can find that script. And yeah, I just I did one of those, like yesterday or the day before. Yeah, I think it was Monday.

09:50 On to the next question. It's maybe just worth noting. I think I forgot to mention up front. We are very loosely grouped the questions together. So we're going through a set of kind of software related questions. And then there's a couple of on the software industry and then a couple of them the more podcast specific itself.

10:05 Yeah, sounds good. Hey, before we did the follow up from the the live stream, Sam sam yes say how much of the original talk Python code do you think is still remaining versus how much has been refactoring over the years? super interesting. I would say a lot of it has been additive. You know, people maybe think, Oh, it's just a podcast site. Like it does a whole bunch of little small things behind the scenes that are not super obvious. Like, just couple months ago, I added the ability to have the site like transform during live streams. So if you pulled up talk python.fm right now like, there's like a sort of the whole site is like lit up,

10:05 Oh. We're live streaming right now. And it'll like take you over there and write like, you don't get that with a WordPress. So there's a lot of stuff behind the scenes happening in terms of the biggest stuff that was ripped out and refactored is it originally was written with SQLAlchemy, talking to a Relational Database. And then after a year or two, I switched it over to MongoDB. We collect tons of data, there's like, I don't know, gigs, gigs of data in the database, and, you know, millions of records. So I'm like, Alright, it's gonna be better to switch over and I like it better anyway. So switch that over, probably just ripped out the data layer and put in this new one. That's probably the biggest change. Yeah,

11:07 the next question that was submitted is from Hardy, who describes himself as a longtime listener, first time caller, Who does Automation and Data Science. There's two questions here, I'll ask them both at the same time, you can tackle them obviously, together. First question, Are there any new courses or content or projects that you're currently working on that you can share to your listeners? And the second question, you've done an amazing job covering almost every major Python framework, what you love about them and what you dislike, as a professional content creator? What are the exact features that you're looking for in a Python web framework, not including the common features, but subtleties that may just make up your mind about switching to that framework?

11:43 Awesome. That sounds like three questions, right? Granted,

11:45 there's more or less Yeah,

11:47 yeah. Beautiful. So first one courses and content that I'm working on, I have two main areas that we're focusing on, we have a couple of authors who are working with me, I probably the most exciting one that is just about to come out is we have a course on DASK. So a DASK and Scaling DASK with Coiled that's going to be real, fun series that we're doing. I have a course on Twilio and Flask. So basically, how do I build like a chat bot that will talk to like a back end and in flask, and then like let people put in database, create admin back end notifications for like a company, then they talk back to their customers over WhatsApp. So that's going to be fun that's coming out more FastAPI kind of leads into the next one of the other questions, right. And then I'm thinking I haven't quite got there. But I'm thinking of doing a year long YouTube channel of something like a five minute, here's a cool thing in Python this week thing on YouTube, just like screen sharing, and like, hey, let's just jump in. And oh, did you know about micro or ultra JSON? Look, you can use it like this, but it's faster or something like that. That'd be nice. Yeah,

12:48 yeah. Thanks. Single highlight out of your other podcast, basically, you

12:52 Yeah, exactly. What's in bites occasionally

12:54 highlights a package we may not know about? Yeah,

12:56 exactly. Like, so Python bites, but like, let's actually write some code and see it on the screen last sort of style. So that's in terms of content, then you the other one was about the web frameworks guide.

13:07 You know, it's about putting weight frameworks effectively, what is it that you're looking for in one that given that you seem to have covered quite a few of them? What is it you like most about the ones you like, I

13:17 would say two things that really attracted me to paying attention to those. One is the sort of modern features modern feel, right? If it's using Type hints, if it's using Async, those kinds of aspects, it feels like it's leveraging what Python is now and not what Python used to be. So those those aspects of it makes me excited. But the other thing in terms of when what I think that it's important to pay attention to or when what I think is switching to it is I look at the basically the derivative of the popularity, the number of stars, the number of people that tell me, I should be covering this, the number of articles you see about it. So like how fast is it growing? And how much excitement so for example, like FastAPI, I would say is probably number one, in that rate of growth category right now. And it also touches on the the modern features with Pydantic and whatnot. And it's not say as popular as Django or Flask. I think it's, if you look at the adoption, I think it's 1/3. Compared to them, you look at the GitHub stars, it's 50:50. But it's only been around for two years where those other frameworks are better in 15 years. So you know, to be almost as popular like 50% as popular, but from, you know, just two years. That's a pretty big indicator that people are excited about it, at least at the time. But

14:30 that is Yeah, I was about to say, slanted. If you're half as popular as Flask, or third as popular as flask, and you've been around for this that that is impressive.

14:37 Yeah, exactly. It's a big deal. And I think it is because these other frameworks, while amazing, it's hard for them to say, oh, we're gonna change how you write the code and use like type hints. And you can see both those frameworks are, are working on their strategy to switch to async. Whereas with FastAPI, like literally the Getting Started out of the box gives you a an Async server, it's you can write async View methods if you want or not, and it's just it's unencumbered in which I think is one of the things that's given it an advantage over the others. Perfect.

15:07 Excellent. I think that pretty much comprehensively covers that. On a side note, I do recall in a previous episode, you've made reference to building your site on pyramid. So is it yes, it is a Pyramid you use? Yeah. That's also obviously one of your favorites.

15:20 Yeah, yeah, there's a little bit of Flask in there as well for like some services that are no one would know about or see, maybe our search micro service type thing might be in Flask. But yeah, I'm a fan of Pyramid. I like it a lot. I think it also is in the situation where it's, it's hard for it to make major changes to adopt some of these new features, right? Yeah, one of the things that attracted me to Pyramid is it's, it's a clean, simple, small framework that lets me go, Oh, I'm gonna use relational and I'ma switch to Mongo. And I don't have to, like negotiate with the ORM and the admin integration, and I could just decide how it's going to work. And for me, that's good. Because I've been building web apps for a while, like, I don't know if that's necessarily good for everyone. But for me, that was such a big, positive. And also pyramid was one of the first modern frameworks to massively embrace Python 3, I remember when I was choosing between Flask and Pyramid. Pyramids, like Python 3 straight away. This is like where we're focused. And Flask was like to get out of statement like, yeah, it'll probably work on Python 3, but we've tested on Python 2, I'm like, if I'm starting from scratch, I don't really want to have that as as the way that I feel like, I really want this to work on Python 3. Right. So that was part of the thing that I think is not really relevant now. But it's part of the decision when I decided to go with it.

16:32 It makes a lot of sense. Yep. Cool. Thanks, Patrick. I think that's pretty much that that was all of them from a question.

16:40 This portion of talk Python to me is brought to you by OutSystems. Just in a recent episode, my guest and I were lamenting about how complex building UI oriented applications for end users has become across the industry. There's an entire class of applications that should be a whole lot easier to build. That's why I'm really excited about our sponsor OutSystems. They provide a visual Model Driven yet powerful development environment, you create your apps UI by dragging beautiful widgets, you connect those widgets to a plethora of data sources, like API's, SAS services, and more. You can connect it to your Python back end data using something like FastAPI or Flask services, then you publish your app as a web portal, a progressive web app, or even a native mobile app at the iTunes and Google Play stores. As someone who has created cross platform mobile apps, this whole system is very appealing to me, I encourage you to check it out. It's time to stop telling your team and stakeholders that it's too hard to build a mobile app or a website for your project. impress them with Out systems, this visit talk python.fm/OutSystems. And check out the animated GIF right at the top to see what I'm talking about. Give it a try for free at talkpython.fm/OutSystems. Or just click the link in your podcast player show notes.

17:52 question which is from me, so I'm not going to introduce myself? Yeah, so Yeah, perfect. So yeah, in my opinion, the addition of f-strings in Python 3.6 was the game changer for convincing many people to finally drop legacy pricing. Many libraries today only support python 3.6. And greater. And I know that some of them did so because they wanted to use f-strings. Do you think pattern matching in Python 3.10 could be a similar milestone, or do you think the current content controversies around pattern matching will continue once Python 3.10 will be released

18:27 when thinking about pattern matching. It's really interesting. It's like a switch statement, but much, much more. Right. And that's been improved. That's pretty recent news that that's been approved and will be in python 3.10. As you've hinted, Patrick, I also agree that f-strings were major. And I think it's interesting to just look back on the history of Python, like one of the biggest challenges of switching from Python 2 to 3 was around the way that strings behaved and like bytes versus strings, where it used to just kind of be all the one thing and it's kind of amazing to me that such a simple, oh, we're just changing this one data structure has so much influence, right, that you'd switch to Python 3.6, because f strings, f strings are awesome, or you would be resistant to switch from 2 to 3 because the way strings worth changes, but I think it's true. So will pattern matching be that? I don't think so. You know, it's let me rephrase that, I think for certain use cases. Absolutely. And I think the way that pattern matching is set up particularly it's, it's really useful for things where you're kind of doing an .A maybe almost for Reg X type of work, where it's not just this value equals that or that but like, like the name says, I guess pattern matching, right, and you're writing a parser or something like that, maybe it's really, really important, but to me, it doesn't feel like it's going to make a major difference. I would say it's more going to be a Walrus operator than an Extreme, which is not to disparage the walrus operator. I've come to love that thing. Actually, I really like it. It's like it, especially I think, in the data science realm where you have to do things as a single statement, a single expression, you know, like a list comprehension or something, you can really do nice things with the Walrus operator, whereas like you could create a variable and assign it and then test it. That's not something that's as easy to do without multiple, like duplication or whatever, in a list comprehension. So these sort of places where you work in like one line expressions, I think, actually, the Walrus operator is really super powerful. So I think there'll be something like that, where there's a, a slice of types of problems that you solve, or like, yeah, this is the answer. And, you know, 90% of world would go like, what's pattern matching?

20:33 Well, here's what I'm gonna say, just to jump on to that in terms of the f-strings to come from to come at it from the other side, I didn't move to Python 3, because I wanted to get access to f-strings, as is I stuck with 2.7, long after they were 3's available for legacy reasons. And that's what this stuff had written was written in a variety of reasons. But because it's what I was using for my day to day job, it's what I was using for my personal stuff as well, I hadn't bothered moving to 3. But having now finally done that, I'm not prepared to go back without the F Strings. Now the strings are just, and it's not just strings, but as strings are a nice, a very nice thing to point it to say, this is why I'm staying with Python 3, I'm not. I'm not giving these up.

21:12 I totally agree. You know, it's interesting. Python has many ways to format strings, you got the

21:12 % Modulo thing, you've got dot format, you could even do a plus you had to all those kinds of things. And now f-strings.

21:24 I think the most underrated thing is this when you have an F string of an expression, and you say, letter equals, and it prints a nice, yeah,

21:32 the bugging statement. Yeah,

21:34 I'll put like a (letter = the letter value) that that's pretty nice. I think it's a 3.8 thing. Yeah, I think that's not, which is bad, because we use a lot of 3.6 currently, but we hope to hopefully we'll see this soon switching to 3.8. Now,

21:48 why is this crashing? So I've definitely broken the server, I took down the website, one. So one of my websites were by using the Walrus operator and a little Side Script, but it tried to parse it. And it was on 3.7 at the time or so anyway. Yeah, you gotta you gotta stay back a little. But I think what's interesting is like f-strings are now both faster, and cleaner and shorter. There's always been these trade offs like, well, this is faster. But this is more maintainable. And now it's just clear. So I think f-strings are actually pretty important. I would put pattern Patrick, I put pattern matching in with like, Walrus operator level and my guest guestimation here,

22:21 so it breaks your code.

22:25 Well I think I'm running 3.9 in the server. If I try to put it out too soon.

22:29 Before we move on to the next question or comments just come on from theater. They've been a few previous comments to do with courses, which I think might make more sense to get to when we get down to the podcast side. But this one looks like it might fit in quite nicely.

22:41 Yeah.

22:42 Basically, my apologies. In fact, my apologies to everyone whose name I mangled if I mangled it wrong. During the podcast, basically, you're saying this question, what do you find more exciting these days web development with Python on the back end? or machine learning and AI?

22:55 That's pretty interesting. What is more exciting. I mean, I think there's philosophical exciting. And then there's what am I excited to sit down and write. And for me, there's something beautiful about just sitting down and building an API that you can put out there and just build a website that feels super smooth. Like, you know, the web is so critical to us today. And you go around, and so many sites are like loading, loading. And maybe they're like, Oh, can you use a front end framework, so it seems fast, and then it fills up, and then it just has a bunch of spinners for a while you're like, no, that's just another way of loading slowly, you know, and having some of this just like instant, no matter where you are, just like, there's so I get a great satisfaction in building things like that. And so, and the day to day, sort of, I'm gonna go with the web development in Python. But in the big picture, like, let's dream sci fi sort of World of machine learning AI is is, you know, very captivating. Cool. Are you guys saying, Thomas, I'm

23:47 with you there entirely. I don't do any web development, per se. But similarly, in the day to day basis, if it turns out that for a lot of my workday, I wrote a script that did something relatively simple, you know, select a couple of databases and process some numbers and maybe told us some stuff we didn't know before. And it was a script I wrote in a day, and I ran it on it once or twice on the server, and we never need to do it again. That was a good day. That was pleasing. You know, I sat down, I wrote some Python. It did the job. And it worked. It's Yeah, that was exciting. To me. I like the fact that I guess a problem to solve. I've written some Python to solve it. And it's a neat, self contained thing, as opposed to being big picture. It's a Machine Learning stuff you do for months on end. And that's also very exciting. But there is something very satisfying about solving this particular problem. Yeah, you know, what's the pattern? And pattern makes a lot of it really simple. Exactly.

24:34 Yeah, exactly. Yeah. Patrick, you live closer to the AI world than probably Kimvan. I actually

24:38 started as a data scientist that my company and I quickly switched to be a data engineer because I realized that that's where the hard engineering and the kind of real work was happening. And without the data engineering data cleaning the whole the proper processing of data, you cannot do any machine learning AI you cannot even start That's why I'm there to build kind of a more foundation for me, at some point, I want to more go into this data science world, more machine learning AI, which is really I mean, it's incredible what Google puts out there with image classifiers. And crazy stuff, especially with video or pictures. But I would also say it's, it's really nice to solve a problem the right way. That's more engineering part, which I like, which is more like a web framework where it's predictable. And data science is it's really depend on the data. And it's hard. The hard problem is a really cool quote that Eugene Yan mentioned on the show last time and in some of his writings we time before, but recently, he was on the show. And it was that this cleaning and wrangling of data is not the grunt work. It is the work of Data science, right? Like that's without that you really get nowhere. It's like an iceberg. It's the 90% below the water.

25:56 Without it, yeah, the top bit falls under. Alright, Kim, other live stream questions you want to focus on our want to move on?

26:02 Well, let's see. Are the other lines increasing that may be used with talking while we're talking web frameworks question from? I think it's next month? Basically, that's the one. Basically, what are your thoughts on creating web applications using Streamlit versus Flask versus FastAPI? In terms of pros and cons? and so forth? I know you've had all whole episodes talking about these things.

26:20 Yeah, these are episodes, I have classes on some of these. Yeah, I've put a lot of thought into this, I guess. So let's put Streamlit on one side and Flask and FastAPI to the same other side in a moment. So Streamlit, if you're unaware is really interesting for I want to write some code that looks like procedural code, maybe in the Data science world, or in a Jupyter Notebook, like do this thing, then this, then this, then this, oh, wait, actually, what I want is an interactive website with like a combo box and a select list and a slider that's going to like lifetime update that on the web, to go from that script to that Front end Dynamic website without something like Streamlit is a tremendous amount of work. It involves, like React or vue, requires writing API's. And it requires you understanding like visualization in the broad, like, there's a lot of pieces. So I think Streamlit is incredible from going from like zero to 80, or zero to 70%. On that, I've got that script. And I want to get that up. And for most, for many, many people, 70% is plenty fine. Like the decision makers or the team want to have a dashboard where they can play with the data and look at it. And it kind of looks like this shape. And I can't do a lot of design on it, maybe but who cares, like they just want access to this. And it's better than an Excel spreadsheet better than like letting them query the data directly. So I think like, that's one realm. And the other realm is I want to build like a Production grade API that that other things are going to depend upon, and use and so on. So that comes down to Flask versus FastAPI, I think on the both new feature, neatness, you know, pydantic, pipe(), Async, and await, FastAPI wins. The API's are similar, but it's the new magic plus the derivative of like the growth rate of FastAPI's is higher. So on that regard, I think FastAPI is a really good choice. On the other hand, Flask has 1000s of extensions, you can add to it, and just make it do things really easily. So if you would like to depend on that extension, things that people have done for you, you know, you're going to get, and you don't want to try to do those things yourself, you're probably better off going with Flask in that regard. So yeah, I mean, not everything. Brian had a nice statement quite a while ago, that you're not Facebook, you're not LinkedIn, you're not Google. And I know that it's a false statement for a very small slice of the world. But for most people, your API doesn't have to support 1000 requests a second, five requests a second is fine. And you can do five requests a second on lots of data on a $5 server. You know what I mean? Like exactly with Flask, I wouldn't know anything. So I think, like, Don't go too far. And also, the Flask versus FastAPI, you can switch from one to the other pretty easily. There's similar frameworks, you can switch. It's not sort of a super huge commitment. Streamlit versus those other two. That's a big deal. That's a big difference. Yeah. And Robert says, I agree faster great framework, small and medium size web apps. Great.

29:06 I'm reminded of probably not that many shows ago, you heads over the Django chaps on and I recall one of them one of the chaps saying he basically he ran almost everything on the baked in SQL Lite. You can get quite far on SQL Lite.

29:18 Yeah. Yeah. That was Carlton Gibson, I think, yeah,

29:21 that was it. Yeah, you can get quite full on SQL Lite. And that was a good point, or not everybody, not all your problems at Google scale problems. You don't need to roll out a cluster of databases up front.

29:29 Yeah. And if you write to it rarely, and you read from it frequently, it may well be very good. It's the thing is, you know, it's a lot of people say, Well, you got to use PostgreSQL if you're using Relational, because you could do all this amazing things. And that's, that's true. But my experience is there's a lot of people out there in the world that go, I want to build my first website or API and put it on the internet. Oh, I also have to learn Linux. And that's really intimidating. And now I've got to run another server in the database in production with the on the internet where people could hammer on it and there's all the security and just like they throw up their hands and they run away that I This is just too much for me to connect these different servers securely and maintain them. And and you know, the sequel it answer might be like, I can do this versus it's too much, right. And I think in that case, it's a huge away,

30:10 there's a strong, I think, sometimes overlooked middle ground, I sometimes think we get a lot of resources for how to begin absolute beginner, you've never done any of those pots of stuff before. And all that stuff is brilliant. And you get a lot of writing on Well, this is how we do it, as you say, 1000 requests a second that huge scale and clustering. And we're running Kubernetes clusters, over 15 different locations around the world and all that kind of serious complexity. But most of us aren't in either of those extremes. We're sitting in the middle where, you know, perhaps MySQL is what you companies chosen to use, for example, and it's just fine. It works. You know, it's not as good as Postgres, etc. But, you know, a lot of these tools will meet the need. The need isn't always as big as you think it will be.

30:47 Yeah, absolutely. I mean, I started out on one server, I think, now we have eight, but I didn't start with eight. That would have been super intimidated. Right, like, yeah, yeah. Fantastic. quick follow up from Robert. a fair number of internal apps used by 10 to 15. People running on SQL lite, easy setup, easy to move from servers are excellent. Exactly. Yeah. And backup, the backup. Yes, you know, the SQLite file, you got it backed up

31:07 baked into your Docker container. In my case, for example, and the people using it don't even know there's a database at all. Brilliant. Yeah. Beautiful. Michael Avery a couple more live comments or perhaps certain if any of those live to you that you wanted to take or we should maybe also one of the questions that was sent in earlier.

31:23 Yeah, Magnus had, he was in here early. So I'll give him the chance to get his thoughts in as well. So does in your great, thank you courses seem to be favoring starting from scratch creating files in order to learn step by step. It's not bad, per se. But do you have any thought of maybe doing a TDD workflow? Would this add more value? I think there's a big difference between the right way to create things for somebody seeing it for the first time versus the right way to create things for engineering. And I would say an engineer, well, I would lean more towards having tests. I'm not sure I want to start that I've gone through some experiences where like, Okay, well we're going to do is we're going to build this whole project up doing TDD. And if the whole idea is not to teach testing, per se, but something else, I think for a lot of people that can be distracting, even though it might be a way to nice way to simplify, and the small scale and the large scale, I think that it can be you know, just one more thing to talk about, like a similar thing that people say is like, well, wouldn't it be great to like, also cover Docker in your classes so that it doesn't matter what setup you're on? It's like, Well, yeah, but then I also have to teach people Docker, and that's already its own its own other, you know, thing. And now I end up using SQLite a lot in all my courses, because I don't want you to have to fire up a server and go, why can't I connect? Or why can't I authenticate to this other server? Or actually, even maybe worse, accidentally put data into it? Because you're playing around and then forget that? Oh, that's open on the internet? Whoops. You know, like, there's just a beauty to just having like a laser focus on the thing that you're trying to do. Exactly. That said, Yeah, my stuff in production, I would say there's not 100% code coverage, I find, you know, that that last 30, 20%, whatever it is that marginal returns on that is much farther down the road, then like, what is the essence of my thing I'm building? If I was building like a training engine, sorry, a trading engine for like stock market? Well, the the core part that does the trades and pricing like that should have tests, the part that does a logging, and probably not like exactly

33:21 the bonded emails. Everybody wants a mentor the marketing newsletter. Exactly.

33:24 Yeah, exactly. Right. Like, yeah, I mean, it might be great to have it. But it could be that you could be making important contributions. And the other add on I feel like that if you take it too far in any direction, that like looking for 100% code coverage or something like that, often, you can end up spending huge amounts of time, then you get into a situation where you're like, well, it would be really better if we refactor this. And that's not that much work. But there's like 500 tests that go with that. Now, we got to rewrite this test. And it's just like, oh, gosh, well, maybe we won't make that architectural shift. Because what was a benefit to like, supporting us getting there? Now all of a sudden, I've got all this like baggage to take along, for lack of a better word. Anyway, that's, that's probably a larger answer, then. He was like a four. That's kind of my thoughts on the on

34:06 a couple of other comments that you've you've pretty much covered as well, on the same vein of testing in your courses and so forth. Yeah.

34:12 Yeah. Okay, cool.

34:13 I don't think that Brian Oaken would agree with you, Mike over. But maybe you should have a course on test driven development. That's, that's fine. Right.

34:21 Yeah. And if we do a course, probably, Brian is going to be the one doing that. So I'll let him you know, I just I have a very pragmatic view about that stuff. Like, yes, you should have tests, you should be able to say, if I push this to production, is it going to crash? Or not crap? Like, is it gonna do the thing that it's supposed to do, but at the same time, I think it's also really valuable to not put too much extra burden and calcify your architecture and your decisions on this package or this structure and be able to move quick when you find that there's other things anyway, that's about this. The tension I'm trying to balance in my world not speaking for Ryan, right. If I could just maybe pick up on one of the statements you were making on the way through the other thing, also to bear None of us really have to bear in mind as if somebody is paying you to do this, there are a number of things you could be doing in any given part of the day that would help the company, which is ultimately what you're being paid for. It may be that writing the last 90 to 95% test coverage isn't actually nearly as useful as the next problem on the list. So you got to ask yourself, how upset will either the users or the business folks be if that part of the site stops working? Or if that part of the application stops working? And would they be willing to accept a little bit of uncertainty there for, you know, more features or something like that? Exactly. Yeah. Yeah. That said, when I was when people would ask, and we need this new feature, how much is it going to cost in terms of time and energy? I wouldn't say Well, here's how much the feature cost. And here's how much the test costs. And here's how much the refactoring to keep things clean. I would just put that into one and go, that's the price. And then yeah, you know, they don't have to have that discussion of, well, yes, you can add this feature. But please don't take time to refactor the code so that it's not building up technical debt. It's like, No, no, no, that's the price. This is what it costs. Yeah,

36:01 yeah, exactly. Yeah. I think maybe while while we're going through some excellent comments that have come through, it might be worth this to more than just lipped out to me that are probably interesting discussions. For most people. There's one from daughter goose, which I can just read. It's basically 'pipenv' versus 'venv' versus 'Conda' pros and cons of Scale. Yeah, that's an excellent question, I think, the discussion and then not quite not actually related at all. But in the kind of Python venv, prod one has asked with all the new pip's being merged, and people calling it a bit bloated with features. What are your thoughts on that? Yeah,

36:33 yeah, I can touch on those, I get your both your thoughts on this as well. So for me, I'm not using PIPenv, I'm not using poetry, I'm not using the other things. And that's not necessarily a negative view on those. But for me, I just focused on using pythons virtual env stuff a couple of reasons. I, for me, it just works. I find it simple, I don't have to make sure I haven't thing installed, I don't have to alter my workflow. I'm going through a tutorial, I don't have to go, Oh, well, they said do this thing. But I'm going to do it in this other way. When I'm talking to other people, or maybe making a part of a course, these things, they wax and wane and you know, it might be poetry this year. But next year, it's pip env or vice versa. And you bake that flow into a course. And then people are like, well, really, you told me to use pipenv's, but I feel like 'poetry' is kind of the thing. It's like, Ah, yeah, well, you can't change those once they're, you know, solidified, right. And these are like month long projects. I don't know, for me, it's not ideal. What I would really like to see is the PEP that has Dunder pi packages accepted and kind of like, there's this convention of, you know, if I've got an environment, I just run Python stuff, it just finds the environment. But until something like that comes along, I'm going to go with virtual environment versus the PIPenv, poetry, etc. I think conda is a different story. Right? I think that the all these other things versus conda this is do I choose like the the conda data stat sort of style of supply? Or do I go straight with pip and like the raw Python things? So rocks? Yeah, I don't do condo cuz I'm, I'm mostly doing stuff on the web. And something that really bothers me about the web is every now then you're like, Oh, you need to update on some random library that either your framework is your framework, or your framework depends upon because there's a CVE security vulnerability, and you need to update that hours from the time you know that not days from the time you know that because yeah, pull up the large website, you can see it's just whack, whack whack, and it's constantly being hammered looking for problems. And if something major comes along, you won't be able to go. Now it's like the releases out, put it up now. And the condo site often has a little bit of a lag. Because there's more that you got to like build the binaries and stuff to go along with it. That latency. That's not normally a big deal is a big deal when you are running stuff that people could be messing with. And you want to make sure like if anything needs to be updated, it's updated straightaway. So that's another consideration. But if I was doing say, Patrick's job, that wouldn't matter, probably right, because it's behind the scenes.

39:00 So actually, I'm using condom computer, mainly because I'm used to so when I worked at my first company, I had to use a Windows computer. And I had to date data science stuff. So it's incredibly hard to install.

39:13 Especially there. Yeah,

39:15 yeah, some packages like 'GeoPandas' it's it's hard to install with pip there. Now I'm using Linux most of the time and it works fine. So I'm just using conda for my environments to setting them up. Just I have all environments in one was one comments, something like Pipenv, but then I normally install just to be a pip. So I'm kind of using it wrong. But I know some of my my colleagues especially data science, people that use conda for running jobs in the Spark cluster and but we personally also my team we're using PECS, which is something like Oh, right.

39:49 Okay, interesting.

39:50 civilians, something like this. Yes,

39:52 yeah. So pecs. That's a way to like package the things you're running up and deliver almost like a zip file, if I remember correctly. And then like running that directly, right? Oh, interesting. It's something like a sip

40:03 vnps you need an interpreter by the way. So you have to have the correct interpreter on your system to then run this file or run this Pac file. So it's kind of a nice thing. It's kind of a binary, which you can chip everywhere. That's the thing. You can test it on your CI and then deploy it this thing on a CI and deploy exactly that on production systems. So you don't have to install alter that in any way from your test environment to production, which is nice.

40:30 Yeah, that's pretty interesting. It's almost like halfway to Docker, but not quite.

40:34 Yes.

40:37 Yeah, and I don't mean that positive or negative. It's just It is like, it doesn't come with the runtime stuff of the machine. Like the interpreter and other stuff you might set up like Docker would but it comes with everything else like exactly as you would put it, right. Like the packages and stuff. So yeah, I think this whole packaging and deploying and moving Python applications around. It's interesting.

40:57 It's interesting. It's changing. We're also looking to poetry now and let's see how to how this works.

41:01 Yeah. Speaking of which a man does I use poetry to get into my project. automall however, not be able to edit do edible install via pip is a big hurdle. Yeah. Okay. Interesting. Yeah.

41:12 Yeah. I'm going to have the next question. Jupyter Notebook themes? Yes. Or no? If yes, which one? how interested? Yeah.

41:19 So, for me, I do some stuff in notebooks. I have like accounting and what courses are popular and what are people doing there? What podcasts are popular and that kind of analysis and graphic? do that in notebooks, but boy, it's just the plain old JupyterLab notebooks? nothing super fancy. Right? I looked at some notebook themes after this question. And they look really cool. Maybe I should check it out. You probably spend more time in notebooks and I do anyway, have you done anything with it?

41:47 I don't know, if I spent more time just some basic stuff to play around with code. I think it's it's superior to ipython just the way the UI works. And I played with Jupyter themes once I tried some, but always at some point, there was some weird thing with CSS, in my opinion. And I didn't like it some table formatting stuff,

42:07 right. That's the challenge, right? Like it's how comprehensive is that theme going to be? And you know, once it breaks through, and then like, Oh, it looks good. Looks good. Oh, it looks horrible. I can't even hardly if it gets to the point where he can't even make sense of exam graph or something, then then it's out, right?

42:23 Yeah. And also like the, for example, I played a lot with bouquet, or bouquet. And then also it didn't really fit in that theme, right? It just like wide and everything around it as a start and end it didn't. didn't just feel right. I liked the idea. themes. I've

42:38 also, you know, say like 'PyCharm' has like themes and stuff that I put in there. And I'm always like, well, this one is great. Then I'm like, Yeah, but this part, I don't know. And I didn't I've there's something to be said for just going back to the plain old standard. I guess another important question, Patrick is font ligatures are no font ligatures? Are you familiar with those?

42:55 I have no feeling about that?

42:58 Okay, I kind of like them. But I know that people see them, like, why does your code look weird? and

43:04 whatnot. So I also normally don't use them, because I have the feeling that it's changing stuff. That's not any code. It's a bit weird. It is weird. I

43:13 kind of like it. It's I've kind of feel for the future when I use them. The thing that's okay with me, they've changed the way it looks, but only for me, alright, they don't actually change the meaning. But yeah, they are a little bit crazy. All right, maybe catch a live stream question from Munten, what would be the best item project types to do to learn some cool things you can do things Python can do? Maybe? So you know, Patrick, I want to get your thoughts on this one as well. I think it depends on where you want to go. You know, people ask me this often, it's like, what do you want to go down, I want to build websites and web API's and stuff, then there's a series of things that you can do there to get you down that path. And if what you want to do is you want to go down the data science or data engineering side, there's a different set of things that you should learn, you go to like, so you should be playing with 'Jupyter', and you should be playing with 'Pandas'. But if you want to go do stuff on the web, you could completely ignore those things. So I think you want to decide in the path that you'd like to take, and then start on really small stuff, right? Like, you know what, I'll give you an example. Some that I have to do all the time, I've got a course folder full of MP4's, and I need to turn those into what is the file name? How many seconds long is it? what is the resulting title of that going to be? And I used to just go through by hand and go, Okay, well go to the Finder. Alright, this is a 1' 30''. So that's 90 seconds. And then the title of the file is this. And so the title is going to be that and you have 150 files, you probably going to make mistake, not fun. So I decided instead of complaining about that, week, after week, I wrote a script that would read the file structure, do some stuff to figure out the time, generate the output that it needed and boom, like all of a sudden now that's an instant answer instead of an hour long project. That's airpro everybody's life is full of these little types of projects. Like oh, this is super annoying. I have to do this all the time. Why do I have to Keep doing this, I keep making the mistakes, I do it at the end of the week, because I wouldn't put it off. And if I do it frequently, like the repetition of it just turns up my day. And there's probably a way to do that in Python and make it run in five seconds or less. And then that just completely changes the way that you approach like that part of your drive like, well, that's all that's automatic. Now, what else can I do? And so, you know, Patrick, and Kim as well, what do you guys think? So

45:24 I dropped out just slightly a bit early for the best Python project types to do cool things, I would find, in all honesty, exactly what you're saying the what I ended up doing a lot of with Python, when I first learned it, I didn't have any I wasn't employed at the time I was at university level, I wasn't using it for my master's thesis I was pretending to do. I basically, a friend of mine, knew it and use it. And he found it quite nifty. And I, when I looked at him using it, I thought, well, this could be quite a powerful tool. And ultimately, I had a few small tasks to automate, and afterlife. And we can't remember what they were now. But similar kind of things I had, say 100 files to rename, or I needed to extract the text out of 50 Excel files and join them together simple things like that, that you could do by hand, it would take you a couple of hours, and it would be done or but it would possibly error prone, you'd make mistakes, and so forth. So I tend to Python for that kind of thing. And ultimately, I found before I knew it that I had, you know, 50 Python files on my system doing one thing? Well, once, every now then I you know,

46:24 and you learn other little, you're like, Oh, this time I got to work with Excel. Now you know how to talk to Excel files, oh, this one's got to talk to a database. Now I know how to talk to a database. But they're not huge projects. No, I just

46:33 think of an example, I acquired some music of some form. And I didn't like the way it was the mp3 tags were done at the time. So then I had to figure out a Python library to do whatever those things are called 'itags' or 'tags' or whatever. Yeah, exactly what,id

46:48 affects something like that. Yeah.

46:49 So I had to figure that out. And then suddenly, I know about a new module. And I would suggest, in all honesty, that the best way to learn some Python easily is the next time you find yourself sitting down and thinking, well, this will take me a couple of hours to click and drag and push the buttons, whatever, think about if you can write some Python to do it instead. And keep doing that. And before you know it, anything you contract and button to do becomes an irritating problem, because you're used to writing scripts to solve all your problems.

47:13 That's right. That's why we both said, Oh, we have all these scripts, just lying around for these types of things. Right, Patrick?

47:18 What do you think I can just agree, automate everything That's my answer to that. And if you want to go forward, the problem is you only come so far with that, like self learning. At some point, you have to get in touch with more experienced people. And that's my second answer to that. So at some point, go to a company, or go to an open source project where you have a mentor with people where you can work and grow, which gives you an experience, which you only can get from other people. Yeah, you take some online courses you can to join something like Python, discord, there's a lot of options for where you can find that. But yeah, maybe even that means find a job where you can you're not the smartest person in the room, and in that area rise like, because at that point, you've got no one left to ask. You're just on the internet on Stack Overflow hunting around. And so that can be also a big help. Yeah, yeah.

48:08 It will be the smartest person in the room. Yeah,

48:10 if you can avoid it. Exactly, exactly. I'll says there are some good books out there, like 'Automate the boring stuff' by 'Al Sweigart'. Yeah, yeah, I recommend that it's, it's in the same 'venv' of what we've been talking about.

48:20 I was gonna say I would have recommended 'Mark pilgrim's 'Dive into Python', but it's quite a few years out of date now. And it does really consume, you know how to develop software. But that's also that was what taught me a lot of useful things. For sure.

48:31 Okay. Yeah. Other questions? You guys. Got a few more minutes. We got it maybe five minutes and then wants to call it Kim.

48:37 I think you can choose right. I already stole one of your questions.

48:41 The one about notebook themes, or was it? Yeah,

48:44 I mean, SQL lite and MongoDB. Right. There's one, which we can have. Well,

48:48 let's just maybe we got a few minutes. Michael, I'm going to salt and dental doubtedly asked you the question I submitted if that makes sense. Because I think this invalidates a lot of people. What I basically asked you was more about the software industry and what you're saying in your conversations with people over the last year or, you know, year plus, etc, particularly in the COVID times, have you noticed an increased appetite for employers to be willing to have the developers work fully remotely? I know, as I said, this has become more common in the US, and it's common in other countries in recent years. Yes. I'm wondering if the pandemic is Yeah, work remotely? Yeah. Yeah. As the pandemic hastened acceptance of employees from outside the employees country, and I asked this is South African. Yeah. And there's lots of small nations like mine, we've got a small software industry, for example. But if I think of say, let's say two in Swaziland are two nearest neighbors, if you want to do any kind of software work, you have to at least come to South Africa. And I'm wondering if there's if the scope is opening for those of us from countries like ours to to

49:39 do more global work short answer. I absolutely. I definitely. Definitely think so. I have worked from home in some fashion or another remotely since 2006. Those are earlier days. Yeah, go to where it was a little bit. And I ended up there and interesting way I worked for this company that I love working for and they said well, my wife got a PhD and we moved from the West coast to the East coast so she could go to University and teach there. And so I spoke to the company I worked at, and I said, Hey, you know, I'm not going to completely hold back my wife's career just so I can stay working here. I have to move like we're moving. Would you like me to still work for you, we can figure out something remote, and they're like, I don't think it's gonna work. I don't think we can do this remotely. Alright, I'll find something else. Coincidentally, like a great company reached out to me a week later said, Hey, we'd love to give you a job. And it's like, traveling around remote, whatever. Fantastic. I'll take it. I've moved away. The other company called me and said, Well, are you going to maybe keep working for us? Like, no, I asked. You said no, like, I took another job, I'm gone. Right? That was kind of the thing. It was like there was maybe we can make it work. I really like working with you. But probably not was the way I think that's less so but it's still persistent. Up until 2019. There were many companies like we're gonna get this off campus, we're gonna get an amazing office. Yeah, you got to commute for an hour and a half and beyond some random bus and a bunch of traffic, but it's fine, we'll give it the bus Wi Fi, you're gonna you're gonna love it, right. And then it was you can either go out of business, or you can let people work from home, like, Oh, you know, what work from home is good. We don't mind this at all. And I think specifically for software developers, what has happened is we've built up rules and ways of working, that are already perfect for this disconnected, async way, we've got git, we've got GitHub or something like it, we've got zoom and other forms of screen sharing, we've got voice over it, we've got the way to say, hey, let's work on this project together, I'll just fire up screen sharing. And it's better than if I sit at your desk because we both can control the keyboard. And I can see it right in front of me. I'm not like off to the side. You know, and I think there's a lot of companies that are realizing that worked. We are privileged for that. Yeah, absolutely. And so what I think is, there were many companies who still believed, maybe it's possible, but it's not for us. And they were forced to realize that didn't break everything. So maybe we can hire the best talent around the world, not the best talent out of just Oklahoma City, or out of Lisbon, or whatever, right? Like we could all of a sudden, really expand out and do something amazing. So not every company is going to come along for that ride. But I think many many more are open to it. That's

52:12 encouraging. Yeah, I do agree with you. They entirely I mean, in particularly in a South African context, quite a lot of employers have had to have some of the employees work from home, there was a time we all work from home. But quite a lot of people are now back in the office, but you know, restrictions on gatherings to kind of try to combat the spread of COVID have meant you can't fill the building. So in many cases, the IT staff are the ones who are working from home, because you're right, we are the best equipped to do this. Now we're using get to collaboratively etc. We're mainly talking to servers that aren't our computers anyhow. So whether you do that from inside the office, so do it exactly. All

52:43 this move to the cloud? Exactly. Yeah, the data center is no longer down the hall behind the VPN, the data center is out on Amazon, or Linode, or DigitalOcean, or whatever

52:53 does that matter even if it is done the whole behind the VPN? You're still talking to remotely, you just were sitting at a desk above it instead of at home. So that I think I would like to think and I must hasten to add if my employer happens to be listening, I'm not looking at myself. But there are lots of people in this South African or otherwise environment smaller. It will smaller industries like ours, way less talented and most people don't necessarily know, you wouldn't come looking to South Africa for a software developer. For example, if as you say you're not Oklahoma City, but maybe there is Yeah, kind of a good sign that we'll we'll start expanding this kind of look,

53:23 I think so I think it's going to be progressive, but certainly the trends are in that way. Everybody's been, you know, shocked into realizing how this is going to work. And I think honestly, there's probably some managers and some business leaders who are like, actually don't even want to go back to the office. I kind of like working from home too. Like I hate the traffic. Yeah, you know, not everyone I heard Tim Cook is like, Oh, I can't wait till we get back together is this is what makes us special? And I don't know, maybe it is, maybe it isn't. But I think there's still going to be a lot of people who are like, actually, this is a pretty good way for us to work. Exactly.

53:55 Yeah. I think there's a lot of people along the lines of I'd like to see my colleagues every now and then but keep working from home most of the time.

54:00 Well, we did the company that I was remote for from 2006 to 2018. I guess it was we would have once or twice yearly retreats, we would go to some fun town and spend a week together. Yes, and you know, basically like Sprint's, or, or do presentations to each other. And it was great team building. And we'd go to Toronto, we'd go to New Orleans or go to London or something like that and spend a week together. And we'd all go back to our remote places. But even just that that one week together in that face to face time creates deeper relationships that when you reach you oh now I feel comfortable to reach out to that person on slack and ask for help or or whatever. Right

54:37 and Exactly, yeah,

54:39 I think dependent Nick showed a lot of people who are a lot of deciders that there are many advantages in allowing remote work. It's like you get better people, you get more people. You don't have to pay for offices, which is like a big deal. And people are more willing to come to your company. It's

54:57 it's incredible or you might even like don't tell all The people who are working, but you might even get more time productive hours from people, they're less likely to get distracted walking down the hall. Yes, they're not spent commuting. If they had a long commute, they might just show up a half hour early, or they could actually get more productivity out of people essentially, know for sure there's people who go watch TV, but like, you don't necessarily want to keep working on those people.

55:21 Yeah, I think specially that covers what I was asking quite well. Thank you very much.

55:25 Hi, gentlemen. I think we might be out of time, even if we're not out of questions entirely.

55:30 Yeah, that's probably good. Another tough set of questions we could have. Also, I don't know, if you want to do this, again, sometime clearly looks like there's, there's a lot of good stuff here.

55:38 So let's just do the wrap up real quick. And just do a quick favorite editor or editor use for Python code and then notable 'pipe project'.

55:47 So I'm using VS Code. I like the like the GUI, although I like the auto completion and intelligence of PyCharm more pilots is making a great leap in that regard. You started using peatlands over the

56:02 Python add in, and you find it makes a difference.

56:04 It's pretty good. It's not PyCharm level yet, but I think it's getting there. In my

56:08 case, I would love to use VS Code. I've tried to use VS Code. I know I should be using a modern tool. It's under active development, like these new things that added to it all the time. But my fingers, remember, 'Emacs', and I keep coming back to 'Emacs' because that's what that's how I'm most productive. It is too frustrating to try anything else. And I'm sure at some point, I will just bite the bullet sit down and work through the frustration point and just get myself into VS Code or something that actually sees development. I'm being slightly unfair to the Emacs guys. But I think nobody would disagree vs. codes. He's more development and say, Emacs does. Yeah, VS Code has got a ton of people working on Emacs is where my fingers are. Yeah, it's muscle memory demands Emacs. Yeah. And

56:48 if you said vim like a lot of you know, PyCharm and VS Code have 'vim' modes and stuff. And I didn't know about the Emacs version

56:54 is set of Emacs bindings for VS Code. But it's just not the same. You know, I rely on things that only Emacs can do. Things like things are probably designed roughly before I was born. But I want those things in hand. I keep going back.

57:05 And you just like your your code to run on here. You're editing to run on less? Well, yes,

57:09 I have actually tried to write some less. But that's in its own right. terrifying.

57:13 Yeah, definitely, as in, Samuel says, you might be able to find some Emacs, I've tried

57:19 them. And they work. But there's this underlying Emacs behavior that just I'm just so used to that I just can't get around not having basically,

57:27 it's just the window is freaking you out, they have to have a window and tabs and stuff. Yeah,

57:31 exactly. It's basically boils down to being kind of old and stuck, in my ways, is what I'm politely saying. Yeah,

57:35 got it. Alright, then, you guys quick, notable pipe package,

57:39 can you want to stop? Sure, I

57:40 actually was going to suggest I was going to highlight highlight 2 Python packages that I don't think see a lot of attention. And they are fairly nice, but I use them a great deal. Particularly when I was doing embedded type software, if there's a lot of those devices, you talk to have rs 232, serial, and that kind of low level stuff. And there's a project called 'pyserial' and a project called

57:40 'pyvisa', both of which are under active development. And both of which I would recommend to anybody who is getting into or is to 3.2 Arduino type embedded work in cetera, pi, serial moreso, for that it's brilliant at Rs 232 work, it can simplify a lot of things, you might be finding yourself spending a lot of time in a terminal doing this by hand. So 'pyserial' can really help with a lot of this kind of automation, and then 'pyvisas' very nice, but I just wanted to give a shout out because I don't think anybody ever does. And it's helped me a lot for years. Caesar is the protocol effectively the controls industrial automation. So things like industrial power supplies and multimeters. And the kinds of things you find scattered around factories that turns

58:40 things around, automate that kind of stuff. Exactly.

58:42 Yeah. Python does it very well. They are I mean, National Instruments is built on LabVIEW to be exactly the tool for this. But if you tired of LabVIEW, and if you're into Python, I would hazard a guess as a LabVIEW may be a noisy like it annoyed me something like 'pyvisa' is a great way to get away from LabVIEW for everything, and Python could do a lot of those kind of automation work instead.

59:02 Fantastic, Patrick,

59:04 I could I want to mention 'Click', which is a package for building CLI applications. I don't know I think you already mentioned it at some point, but I just love it. Oh, awesome.

59:13 So instead of using like 'argc()' or just like sys.argv().

59:17 Yeah, test on Flask wipe was decorators. It's because the creator of flask also created. Click, I think yeah, it's

59:24 interesting. There's the CLI frameworks and these web frameworks. And it seems like multiple times the people that make the web stuff, also create a CLI frame. I get something going on there. Yeah. But yeah, that's cool. Yeah, 'click' is quite popular and neat. Yeah,

59:36 there's also 'typer', which is built on click, which is even, like, even easier, and that uses 'type hints' if you're interested. Like,

59:46 yeah, type is cool. That's nifty. They're both cool. Yeah,

59:48 it's maybe just worth pointing out that you mentioned SR log and og POS since all classes bundled into the beta nyeri. And if you are still using sis.org bars might be worth a look. You know, if you if you don't want to install third party applications, you can get your hands on at least og boss to get yourself closer to

01:00:04 their core good advice. There's definitely something to be said for. You don't have to pip install anything. You don't have to create a virtual environment, you can just run it. And so if using 'click' would push you into that boundary, maybe it's worth it. Yes, that's right. Yeah,

01:00:17 we also have it in our production system because at some point, we weren't able to use a personal 'venv'. Now we can with specs, but before we had to use what was there, which was basically nothing interesting. Okay.

01:00:30 Yeah. That's part of the advantage of PACs. All right, Patrick. Kim, thank you for hosting. This has been great, Bill.

01:00:35 Thank you, Michael. My apologies that I wasn't here for some of it. I hope I didn't miss too much. But it was great. We both of it that I was there for I thoroughly enjoyed. Thank you. That was that was very good.

01:00:44 Thank you for having us, Michael. Yeah.

01:00:46 Thanks, guys. See you later.

01:00:48 Bye. Thank you very much. Cheers, guys.

01:00:50 This has been another episode of talk Python to me. Our guests hosts on this episode have been Patrick Louisville and Kim van wyck. Stop telling your team and stakeholders that it's too hard to build a website or mobile app for your project. While then without systems. Give it a try for free at talk python.fm/OutSystems. Be sure to subscribe to the show, open your favorite podcast app and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, the Google Play feed at /play and the direct RSS feed at /rss on talk python.fm. We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talk python.fm/YouTube. This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code