Brought to you by Michael and Brian - take a Talk Python course or get Brian's pytest book

« Return to show page

Transcript for Episode #177:
Coding is 90% Google searching or is it?

Recorded on Wednesday, Apr 8, 2020.

00:00 Hello, and welcome to Python bytes where we deliver Python news and headlines directly to your earbuds. This is Episode 177. Recorded April 8 2020, Michael Kennedy Lambert. And this episode is brought to you by data dog check them out of Python by setup m slash data dog. More on that later. Brian, Can you believe that? It's April? I really can't, it doesn't feel like it. I know. I feel like we're still kind of in the winter mode. And yet it's warm and sunny. For the first time in seven months, I've been told, yeah, well, I'm doing yard work, but just sort of feel like we're gonna skip Easter. I don't know what's going on there. Yeah, it's crazy times. But at least it's it's warming up out there. And that's lovely. So before we get into our main items, I have a very exciting announcement that we were just working on to let everyone know about, too. We're trying to find other ways for people to learn about or consume the podcast, other ways that you can interact with us, your listener. And so we're launching a YouTube project a YouTube channel. So right now, if you can, and you're up for it, go over to Python bicep, FM slash YouTube, click subscribe. I honestly don't know if there's going to be any content there yet. Probably, probably, maybe we're not 100% sure, because there's none now. But by the time this episode comes out, I think we'll have some ideas. Each segment that we're covering, we're gonna have a dedicated little video of Brian and me talking. And if there's another guest, that'll probably involve them as well. And so it'd be really nice to have that. For everyone, I think to just be able to quickly dive in and watch a video see the two of us talking here, as we see each other, but also be able to just focus in on one topic. I'm not quite sure how it's gonna serve us, but we'll put it on the YouTube channel probably put on social media and feedback would be very welcome there. I'm super excited for this. It's gonna be great. Yeah, absolutely. So my, I'm also a little excited for PIP and the whole packaging thing around Python. Yeah, well, I am too, I'm one of the things I'm looking forward to the I think we covered this a couple episodes ago is, uh, the dependency resolver. Coming in, in changes in Pip, which is exciting. But the one of the reasons why we're having I mean, there's been a lot of packaging changes. Lately, we've had a relaunch of pi pi in 2018. Some security features went in in 2019. One of the things I didn't know about was more support for users with disabilities and multiple locales are added in 2019. And there's been more security features and PIP and the dependency resolver being updated for 2020. And a lot of this has to do with some money that came in through some sponsorships in through a gift from the I think it was Facebook foundation or something like that. But anyway, so money came in, but they were one time things. And the Python working group and the Python Software Foundation wanted to keep this going. So they're launching an all new sponsorship program to help sustain and improve the pythons packaging ecosystem. And funds raised through this program will go directly towards improving the tools that all of us and your company uses every day to sustain the continued operation of the Python package index. And so I want to highlight this because I think it's really important, and I depend on pi pi and packaging. And I know my company does even more and more and more people are moving towards more Python tools. We're linking to this page. One of the things on there is, there's a prospectus for what what you get as a sponsor, and you can apply to be a sponsor there. And there's a link to ask questions as well. And then I don't note there that even if your company doesn't want to sponsor you individuals can donate money, either sustaining or one time thing to Yeah, I think the changes they've made lately or have been in the right direction. And I want to have it keep going. Yeah, let's keep it going. The changes, the major changes, like the big rewrite a pie org happened, because there was a grant, I think that one was from Mozilla at the time. But it was we actually have some money, and some folks can put their full energy for several months onto that project. And guess what, when you do that, you make a ton of progress and stuff gets better. And there are so many companies out there, who's bright primary technology stack is running on Python, they have billions of dollars of revenue, and they contribute zero back to Python to keep that base that they are built on strong. So this is definitely a chance to encourage your employer to make, you know, a yearly sponsorship donation or something like that, to the PSF they definitely need it now that pi con got cancelled, that means less revenue for them, as well. So it's more important than even usual. Yeah, and I think it'd be even neat. I mean, a lot of people think about these, we have the news, there's news of these huge grants and stuff and those are those are super nice. But if all the companies that use Python, and you know they're hidden pipe Yeah, all the time, even just pitched in like a couple thousand dollar

05:00 In a year even Yeah, they would game changing. That'd be great. Yeah. So yeah, absolutely. To onto another good cause, listeners probably know, I'm very passionate about making sure that we address climate change and move to renewable energy, things like that at all of our infrastructure and our content is delivered carbon free, we have a, like a broader initiative to make sure that we offset any of the resources we might be using, and so on. So this next project is sort of in that vein, and it's called energy usage. So the idea is, it's a Python package that will allow you to measure the environmental impact of computation. So you know, we've had like profilers, like C profile, and we've had time at right. So that's basically the idea of this thing, right? But instead of asking, How much time does it take, you can ask how much energy does it use. And what you do is you give it a function, you give it the arguments, and you just say, run this function, and figure out how much energy it uses. So it sounds silly, but it, it can measure how much CPU resources, say versus disk versus network it's doing and actually figure out how much computation that's taking, right? Because time, it just tells you how long it took, it doesn't say, well, actually 18% was CPU, and it was this high, and so on. And it takes all sorts of things into account, like the loss of energy across the wires, how far you are away, the location that you're in. So it will actually the report you get is like, this computation took 1.86 watts of energy. And using geolocation we saw you're in Pennsylvania. So that means you got 25%, coal, point one 7% oil, 30% natural gas 42%, like renewable. And that's how the energy was broken down for this particular run of that function. And is equivalent to say, you know, like, a certain amount of TV watching or driving so far, or us household consumption, and so on. Interesting. Interesting, right? Yeah. So it's just a nice little package that you can point at some code that you're trying to profile and saying, how much energy does this use, but I worry about it shut optimize it. I mean, profiling is pretty close to giving you where you should focus your energy. But if you want to know, okay, this is most of the computation, but how much does that actually cost in terms of carbon or just more specifically, it's measuring energy consumption, which is also just something you have to pay for. If you have a data center, then it's, it's pretty interesting, I think, yeah, we can get like maybe if like a package that would failure your code if it if it uses too much, or something? Yeah, yeah, it's pretty interesting. It will output PDFs. You can run it where it doesn't put anything on the screen, but then it will, you know, save a report to a file or something like that. Does it include the running of the I mean, how much energy does it take to run the usage? energy usage? That's very meta. Yeah. I don't know if it how much is actually is computationally intensive, but it is worth pointing out, sort of because of that it only runs on Linux, because of the system, CPU inspection, parts of it aren't built out to support other operating systems. So you have to be on Linux to do this test on your code. Okay. Anyway, energy, you should people can check that out. It's a cool little package. Now, before we move on the next one, and let me tell you about data dog because this episode of Python bytes is brought to you by data dog. And let me ask you a question. Do you have an app in production that is slower than you like using too much energy? Maybe its performance is all over the place? Sometimes it's fast or slow. But the most important question is, do you know why it's slow? with data dog, you will, you can troubleshoot your apps performance with data dogs and tracing, use detailed flame graphs identify bottlenecks and latency and that finicky app of yours. So be the hero that got the app back on track at your company. Get started today with a free trial at Python slash data dog, cool data dog t shirt included. So Brian, this next one that you put on here, I almost covered it a few weeks ago as well. And I was like, Yes, this is really interesting. But then I did something else. Like there's a shiny object, and it pulled my budget away. So yeah, this is a bit of a philosophical one. Yeah. So this is a we're linking to just a short little article, but I wanted to talk about the topic, the article is called coding is 90%, Google searching a brief note to beginners. And there's really not much here other than saying that, like, I mean, there's I guess there's three points in trying to learning how to program and a couple of them are good in that. Just pick one language to start with when you're learning in a program. And of course, pick Python, and then start to do a project, like try to do a project. Those are great ideas. And then the third point is, anytime you get stuck, Google it. And the point of the article really is I think that coding is 90% Google searching anyway, so and people don't usually tell beginners that and I don't think I agree with this. I was wondering what you think of this. I don't think so.

10:00 agree with it either, but I'm not sure I agree with you yet either. So let's talk about it. Because it is interesting. And we probably do agree, honestly, I think programming, developer, career evolution goes through phases and seasons and whatnot. I think in the beginning, you're just super lost, you just start trying to figure out syntax and whatever. And then you feel really good because oh, I really got this syntax figured out. And it turns out that that's a minor part of programming. Now you got tracking down bugs and using libraries, you're like, I got to learn what SQL alchemy is, Oh, my gosh, like, what is the migration? Okay, Google migration? How do I do migrations? Well, this isn't working, let me like Google and up at Stack Overflow. And in that sort of stage where you've crossed over, like, I'm kind of a competent language user of the language, but I'm not really like the world is actually open. And all these libraries and packages are out there. And I have no idea what I'm doing. Like, I don't even know what third normal form is. So I better figure that out. Because it says I need it in my design for my SQL, alchemy classes, or whatever. I think in that season of your career, I kind of agree with this, like you're just googling like crazy. And it's okay, because Google, is it really good. And the resources out there are really good. But when I saw this article, I thought, okay, that's a pretty good message to people who are kind of new, like, you hear how horrible it is to do copy and paste coding. And yet, this person is saying, like, like they were, I think, a couple of years into their career. They're like, Look, I do this a lot. And I don't feel like I'm cheating or whatever. And yet, I don't feel like if I had to put a number on, I would say, coding is 5%, Google searching for me these days, five to 10, depending on what if it's like, something new, I'm doing it, it's probably 10% to 15. But most day to day work, it's 5% or less, I don't know, how do you feel about that? I definitely agree. Like, for instance, I'm picking up a new framework or something I'm gonna be, I'm gonna be looking it up a lot, right? There's there's little spikes as you adopt a new thing, but then it really goes back down, right, but I was paying attention. So I was thinking about this last couple weeks and pay attention to my coding style. And I do, there's probably at least a handful of times during the day where I'm googling something. But it isn't like everything, it's it's definitely a more of a 5% thing or less. And then I realized that a lot of the things I'm googling is stuff that I've just decided to not memorize, right? Like the syntax of weird things, like, I'm pretty sure that I can have like a step size in range, the range function, but I don't use it very often. What's that, again, you know, things like that, like little egg extra stuff. And a lot of this actually a lot of this stuff, editor support really helps. Anyway, if I already know kind of what I'm doing, the editor can pop up what the syntax is, that's a really good point. Because if I was using just pure Emacs or something that had zero autocomplete, I'd be googling more for sure. But anyone pi charm, you hit dot and like, well, there's three choices. And it tells you the parameters. Like you don't need to Google for that stuff anymore. Because you got the better tooling. Yeah. And there's different stuff like so the syntax, I leave the ID a lot. There's definitely a skill. So one of the things that kind of missed out of this article is, it's not that nine that Google searching is 90% of coding, it's, it's a big chunk of your skill set is to learn how to Google something effectively. So encoding, like, like the, instead of trying to summarize what the error message is, and then googling that, I'll just paste the entire error message in. That's it like one trick to do. And so there's a whole bunch of coding Google tricks to find the information fast, because I don't want it to be 90% of the time, I want something that I kind of think I remember to be able to look that up in just seconds, and then go back to coding again. So yeah, I hope it's not a 90%. That would be a very slow way to code it would be but I remember that being the case back in the day. And for me, it wasn't googling because I think we had when I was first doing programming, you have to see if you can remember yours. But I was using AltaVista, I'm pretty sure.

14:09 Right, like people who are listening to Joe know what that is, that was a search engine that was nowhere near as good as Google that existed before Google. But the things you would end up there was not StackOverflow to search from and all those sorts of things. And so it was a lot of books and a lot of user groups, and not user groups, like Usenet groups, whatever those were called. So there was a lot of like, reference research stuff in the early days for me as well. And I wish there was Google, I could have done a lot more effective Google searching. But certainly I think that that is a just past stage of one of your career is this is a reasonable way to see the world but you're right. It's absolutely a skill and the more effective you can be at narrowing in the better but then I think it actually is. If people are living that life now like googling all the time, this just must be like the rest of my life. I'm gonna just do this. That one

15:00 The way it is, yeah, I'm thinking back in my memory, though, when I learned to program, there was no internet. So there was more if it was if there was I didn't have access to it. So early 90s, late 80s, it was books. So I references and still even even through my career, early career, I had a couple books that that I would rely on because I knew I knew how to look things up quickly. So I had like, for instance, I had like a sticky note, right? Where the like the printf translator thing. So if I knew how to how to print f scan f how, what those little percent signs were and all that stuff. So yeah, that's a really good point. Yeah. So I remember my, I had a c++ primer or something like that. And boy, that thing was all tattered. And I use that a lot as well. Yeah, but it's not that way. Either. It doesn't matter whether it's a book or Google or whatever. It's a phase, but it's not all of coding for the rest of your career. Right. And then there's, there's stuff that you just end up remembering that you like, I'm never gonna remember this. I know, I'm gonna always have to look this up. Because there's some block like printf, decoders and stuff like that. Yeah, exactly. Yeah. Like, this stuff for parsing strings and dates. Like, that is not that is always a Google search for me, because I've just, I'm not gonna remember all the details there. Yeah, this next one, if I were to set this up, this would definitely be a Google search for me as well. So I'm considering it. But luckily, I don't have to Google search it because we'll cover it in the show. And Chris Moffat is covering he wrote it all up for us. So Chris Moffett wrote an article, he's been on talk Python, before. And he wrote an article called using Ws l to build a Python development environment on Windows. So Ws L is a Windows subsystem for Linux. Okay. And this is interesting to me, because I just recently had this experience where I finally broke down and I decided, I've been using parallels on my Mac and ever super fast Mac like a I nine, with six cores, to it should be able to run virtual machines just fine. And yet still, when you're working in Windows, or you're working in any of the virtual machines, like even a virtualized Mac OS, it's still like a scrolling a little bit off. Like the keyboards tiny bits of late, there's just a little bit where it just doesn't feel good to work there. Right, you can totally do it. But it's kind of you can tell it's, it's not a perfect experience. So I finally broke down and installed Windows and boot camp. So I can boot into Windows, and have a true native experience, or just keep booting into my Mac OS and have that. And that is a lot nicer. But one of the reasons I don't want to go to Windows is I really love the terminal and Mac OS, way more than even on on Linux, it's just super nice. And some of the tools you have there are like in deployment on Linux machines. So you have this sort of closer to production world, but you have a nice house with like GUI tools and little widgets and whatnot with Mac OS. And I was thinking, you know, it's not really fair to Windows to like, stick it into this little crummy system. So it's nice to have this other option. But I don't want to go there and do development because I don't have this Linux type system. Right. It's nice terminal to what Chris talked about. It's basically how to set up windows subsystem for Linux. And there's a new version that came out mid last year called Ws l two, that is a lot better, especially around file performance, and IO and sharing and like crossing over between the windows and a boon to or whatever you choose to read. Okay, do you do this any? So I tried it really early on. And I haven't tried it since w so two's out. Yeah, it sounds like it might be worthwhile. If so, if you look at the this thing Chris wrote, he talks about, there's like a little motivation of how it runs and whatnot, oh, give people the lowdown. But mostly it's like a step to a guide of how to set up the various things you want. So for example, if you want to be able to have a nice terminal on the windows side, but then that can talk to the windows subsystem talks about installing the new windows terminal, which we already covered it recently. It talks about getting a boon to from the store, how to upgrade old wsl installations to like the version two, also how you can set it up to use Visual Studio code. In Windows that is actually like working on the windows subsystem for Linux. So like you fire up VS code, and you're doing your work. And then one of the environments you could choose is like a Ws l environment that's actually running Bray on an ultra lightweight version of Linux. So you know, when you get the little terminal and VS code, and you type over there, right, it's, it's running Linux commands, but on your machine still, without a VM. I mean, sort of a VM, but not really, it's like halfway between doctor and full VMs this looks nice. So what I am usually doing is I'm off to try this out again, but i i agree with you that I like to pretend I don't have windows, but I do. I mean, my day job I work on a Windows machine, so maybe this is extra helpful for you because you're gonna be there anyway. Right? Yeah, but I mean

20:00 So I've already worked around most of it. So I use Git. So Git for Windows comes with Git Bash command, which is kind of have both of them, you can do windows stuff and work around and bash and it sort of feels like Unix environment. So nice. Well, I'm very excited about the possibility of just having native feeling Oh, my z shell on Windows. Oh, yeah. That's gonna be nice. Yeah, well in it. And I hope this is a direction that I think it is that this w SL stuff is just more and more integrated with the rest of Windows. Yeah, the integration is pretty sweet. So if you're in Ws L, which is effectively like you're in a boon to right, you can type explorer on the terminal, and it will open up the Windows Explorer in that folder in the Linux folder, but it'll open up the Windows Explorer, the native UI, file stuff, right on Windows, and things like that. So the integration is pretty sweet now, which is what I was thinking it's worthwhile also, to start up this w cells like one second. So it's basically feels like starting a sluggish terminal.

21:05 Yes, right, then it's up and running. Right? Yeah. Anyway, so this is a really cool breakdown of how Chris is working. And the various tools like the various plugins for VS code, and how you configure them to make them all work together and stuff. So if this workflow sounds interesting and useful to you, check out the article. It's got a bunch of details and screenshots on how to do it. And it's not really worth going into those. But I think it's a cool idea. And I just want to give a shout out to Ws l two and do in Python on it. Yeah, very nice. You got a solid one for us. Ah, we've kind of kick this can down the road a few times, but I thought we'd take a crack at it. There was a an article written by Derek D, called a pythonic. Guide to solid design principles. Are you familiar with what the solid principles are? single responsibility? Open? closed? liskov substitution in something and dependency injection?

22:02 Is eyes interface segregation principle? There you go. Okay. Yes. on that one, I cheated. I always have to look it up. But I, I was curious. So this article is interesting. It's an interesting article. So the idea is taking this all these principles, and I'm gonna have to go through and spell check these. But anyway, I don't even know where these came from. But they're this idea that if you're doing object oriented design, you should have solid object oriented design. I don't know if I completely buy it. Actually, I'm pretty sure that I don't. But the this article goes in and also talks about kind of relates each one to the Zen of Python as well, in sometimes it's a little bit of a stretch. And then also just really how to apply these principles in programming in coding in Python, I guess I'll just say, my take on solid design principles are there things that are good to know about? And there's lots of different design principles to know about, and these are some of them. And in developing object system systems with objects and all Python uses objects, whether you think it does or not, if you look at some code, and it's hard to maintain it, or it already is hard to maintain, maybe some of these principles might help refactor so that it's in a better state. But blindly following these rules, actually, I think could possibly make your code even worse is my take on it? Yeah, well, I'm a big fan of design patterns, I really love the concept of design patterns. And one of the things I love about them is, once you start to think of code and design patterns, you can think of trade offs and higher level building blocks than just functions, or here's a class you can think, Oh, this is a, you know, this is gonna be an interface. And so what that means is, here's a benefit. And here's a drawback. And do we want to go down that path, right, or, I like that it lets you think in bigger abstractions than just lines of code or functions. So I'm a huge fan of that. But one problem that I've seen a lot when people adopt design first, when they learn design patterns, they become super passionate, like, Oh, my gosh, this is so awesome. It can be so easy to go. All right, well, these are going into everything, like every chance I can get to use the visitor pattern. It's going in and you're like way, way way. The visitor pattern is super complicated. And it only solves a cool problem. But it is really not obvious or easy to maintain. The problem it solves have better be glaring and massive, or you're just making it worse. And so I see this kind of stuff as salt, and pepper and paprika. Its code is better with it. But that doesn't mean it should be ultra doused at it. Because it is not better anymore. It's all of a sudden, like, this is a really cool study and design patterns. I have no idea what's going on. Like for example, dependency injection, like there's a few places where dependency injection like at certain layers might be cool and you could apply it and it's really neat.

22:02 But if you do it everywhere you're like, I have no idea what anything is or how any of them get to each other. I just know that this is a complete mess. And I needed to bug her to even figure out what's happening all the time. And like, that's kind of my feeling about solid, especially in Python, it's definitely my feeling about design patterns. What do you think I definitely have to agree one of them. And one of the things that Well, I think I agree, both design patterns and the idea around solid are, they were really developed for other languages, I don't think they're definitely not the first tools that I reach for, for making Python more maintainable. And design better. Like, for instance, the, like you mentioned, dependency injection. This is, as far as I can tell, dependency injection is, should be used very sparingly in Python. And there are great, great ways to examples. Like for instance, in an application that where you don't want to depend on a particular database style or database, you can set up the database configuration early on, and then pass that to the system. But the problems with looking up, if you want to know more about solid and more about design patterns, almost all the examples are going to be not appropriate for Python, because they're going to be like, you know, Java examples, or C sharp examples or something. Right. And in static language examples, yeah, yeah, I also think that they get, the way they get used, they get used in this, like, overly general over complicated way. So for example, dependency injection, I've got something I can maybe have a data access layer, and I want to be able to configure the type of database access it uses. And I want to be able to configure the logging messages that it can send or whether or not it logs to a file or at all right, you could take that and require everyone to always pass it, database, core instance, do it and always pass a logger thing to it. Or you could just have the data access layer, have defaults, and then you override them only if you need to, usually in testing, so you can set them up. So you always have to feel the pain of this structure, or you can set them up. So you only even know that it exists if you need to look into it and change it. And I find a lot of times it gets used in the hard way only. But the problem is there's like a little bit of hard here and a little bit of hard there, then you could pose it, it's a little bit more hard at the top, you're like we need 20 things to like create this class and get it started. And I don't even know what they're for. They got to be passed away down and like, now we need IOC. Now I can't figure out where stuff is coming. There's just a lot of like layers that it adds on. So I don't know, salt, I think is my best like spice. Yeah, and sometimes simple is good. Sometimes just a cookie is good. Yeah, well, you're right. And you can always strike cookies. Good. You can always start with just write it the simple way and then add this stuff if you need it. Right. Are you really feeling the pain that these kind of patterns would solve? Okay, bring it in, right? Got refactoring tools, got tests, right? Yeah. And the other. The other thing with the I mean, solid includes things like the liskov substitutability principle. How arrogant does that sound? I mean, that's one of the things that just I have a problem with is it just it reeks of I'm smarter than you because I know about this stuff. And yeah, I just don't like that. But yeah, yeah. It's a cool article, though. And the solid principles are good to know. Even if you're not using them everywhere. It's good to know like, these are some design principles, and I'm choosing to use them here. And I'm choosing not to use them there. Because, right, do it consciously, right. Definitely. Speaking of making choices and trade offs, Instagram rura, cool article recently that I thought would be fun to cover. Because it's a look inside how they're running their Django app, they want to basically take typed Python, like type annotations, which they're loving, right? They actually did a Python presentation, or I don't know if it's officially under Instagram. But a Lucas Linga covered basically how they're using types to add Instagram when he was there. And that was really, really interesting. But they're like, Look, we have a few HTTP endpoints they have, they've talked about how they're not doing micro service. So they have a single Django app. And it has a few thousand HTTP endpoints in the one app on top of other stuff. Wow, that is a lot of API endpoints. Yeah. And they all exchange like rip rich types with validation. And so they asked the question, you know, our methods in code have type annotations. We can check that with my PI, and stuff like that. But how do we have developers know whether their API's are still matching? what they should be because everything returns a JSON result, or JSON response. Everything takes an HTTP POST or a JSON object and like, what are you gonna do with that, right? So they went on this mission to try to add this typing to their API. So they came up with this decorator that they can put on a regular type method.

22:02 that converts it to an HTTP endpoint in Django. Okay, right. So I've got a regular function, it just it declares its variables. It declares their of this certain type, it returns some of another type, and you just decorate this thing and boom, it becomes an HTTP endpoint that returns JSON, based on what it exchanges JSON based on what comes in and what goes out, which is pretty cool. So that's a start. And it says, well, you're still just returning JSON responses. So how do you get better validation than that? So they decided to start using data classes, or data exchange, because data classes have a type. They can be immutable, because you can set the frozen decorator on them. They have type validation through things like my pie and whatnot, which is all really cool. But remember, they have millions of lines of code, and thousands of endpoints in a single Django app, and they're not going to go, Well, you know, what, we're gonna upgrade every single interaction to use data classes, right? There's a bunch of dictionaries circling around. So have you heard about typed dict? Yeah, it's neat. Yeah, it's really cool. So that comes out of one of the my PI extensions. And it lets you create a dictionary, but then also express the types like this key is supposed to be an integer. And this key is supposed to be a date. And so for the older code that couldn't be written with data classes, what was just dictionaries, they added in typed dicks to help give validation to that and type explicit type definitions. Instead of saying this thing returns a dict. It can return a type that has a type deck, but still compatible with API. That's pretty cool, right? Yeah. This is interesting. Yeah. It's super interesting. And so they also talked about how do we. So once we have these API's, and they have types, and they have type validation? How do we communicate that back to people? So they leverage open API to come up with very nice documentation. If you got the article open? Brian, you could scroll down and see like a very beautiful, like API reference that was just automatically generated out of the API methods. Yeah, that's an API is really nice. Yeah. So that's really cool. Now, what's also interesting is, they go through this whole process of what they've done and how they done it. And this is on medium, implicitly, it's on their blog, but they're blogs on medium. So you can go and see the comments in there. And a lot of people are like, Hey, this is cool. Why don't you use pedantic which we've covered pedantic before, it's, it solves many of these problems for data exchange validation, another person like you should use fast API, because fast API has this typed API methods natively at the boundary, you don't have to like, have this decorator that'll transform them into Django. That's really cool. But all of these are like, Hey, I know you have a couple million lines of code for like a huge, huge project in production. Why don't you rewrite that and fast API? No, right. That's just not gonna happen. 30 in Django, I mean, yeah, I was thinking, Oh, it's kind of like fast API, except for they're in Django. So yeah, exactly. I mean, who wants to take on the job of rewriting the entire millions of lines of code, when they've just gone through the progress process of going, upgrading Django and upgrading Python two to three, and so on. So there's a bunch of interesting comments about alternative ways to solve this problem. If you were starting from scratch. Yeah. But I think it's also interesting to think about that now, one thing that did come out that they could use, somebody said, this is cool. And if you have typed API's and nice documentation already using open API, why don't you check out skim a thesis schema, thesis schema? schema thesis. So it's a tool for testing your web apps based on their API definition? So it goes in reverse, it looks at the documentation. And it says, Okay, we're going to call your endpoint according to the documentation and see if it really matches that or not. Yeah, it's really cool, actually. Yeah. So I think that that's actually pretty neat. I've never used this, can this, I recommend it. But it seems pretty interesting if you've already got the open API stuff in place. So I like that. Yeah. Alexander Hoeppner brought it up the schema thesis project up when we I talked to him on testing code 107. And it sounds pretty neat. Yeah, yeah. Very cool. All right. Well, that's it for our main items. Brian, you got anything else you want to share with folks? One of the things we've done for the past couple episodes, just talk about the current COVID-19 stuff and working from home. And we didn't mention that at the beginning. But I have got like, actually, I wanted to just take this section to like, bring up some things that I'm running into. And I'm curious if any of our listeners have some comments, but I'm curious about you as well. If you have any suggestions, so you don't normally switch between Windows and Mac, is that correct? No, not usually. And if I I'm actually I told you, I disabil got boot camp booting into it. And it's driving me crazy, because even when I was using parallels I remapped Ctrl C to be Command C. So even in Windows, I could do Command C, Command V. And windows. I could do command W to close a window, but now I got to do alt f4. But oh yeah, the crazy touchbar thing doesn't have function keys.

22:02 Now how to do alt f4 with no function key, like there's just a bunch of like, yeah, it's, it's a challenge, if I'm not running a VM, so yes. Okay, so I've got two laptops, one of them runs Windows, one of them's running Mac to Mac. And so I've got my setup with my like my monitor and my keyboard and everything. And I can switch between them. I would love to have just a magic switch. But apparently USB switches don't happen. So I just plug in the USB C, from one to the other. So if anybody's got a switch that they know about, great, but I don't want to pay like $1,000, I was thinking like 50. Anyway, what I'm noticing is this whole Ctrl C thing. So on Mac, its Command C, Command V, all that stuff's great. And then it's Ctrl. A, that's the thing I'm messing up is the copy and paste, and all that stuff is different on the two. So any idea? Is it easier to can you remap on a Mac? Can you make it do Ctrl C and Ctrl V? Also? I think so I'm pretty sure you can, you can go one thing that I do all the time on the Mac is if you go to the keyboard preferences, okay. And then you can go in there, you can go to shortcuts. And so I say all like go to that, like app shortcuts. So if you go to App shortcuts, you could add a new one, you could pick all apps or just one. So go and say Edit mean, you know, paste means this copy means that it might not always work, you might have to add it for different apps because it has to match the menu item Exactly. So if one is like a you know, copy and paste, or I don't know, like paste with a capital P or lower p or, not a dot, dot dot, those would not be compatible. But you could go in there and add the shortcuts, just say Ctrl Ctrl V means paste, or paste dot.or capital P based or whatever you got to do for a few of them. And then I bet you could map it over like that. Now, the other thing that you could do that I used for a little while is I had a Windows machine and a Mac at the same time on two different computers. And I set up a like a network KVM which is kind of what you're talking about. And it lets you actually just have two monitors on two computers side by side and the mouse will just move straight across from one to the other computer. Like without changing stuff. So there's a place called share mouse comm I cannot recommend I've never used it, I can't seem to find the one that I used to search for and use back like five years ago. But like a network KVM switches what you want or something like that. So check that out that might let you like actually have both at the same time. Maybe you can remap command to control across that as well. Okay, the other thing is, so we're on episode 177. Right? We've done all these most of these episodes where I'm using a laptop, and now I'm using a monitor. Is it distracting to do and it's nicer to me to look at you while I'm talking? But is it distracting to see somebody looking sideways? While you're talking? Right, right? Because your camera is on your laptop? Yeah, that's your main high risk monitors front of you without it right? It's not distracting to me because I'm used to it I there's so many video calls that I'm in these days, where it's some sort of setup like that. Okay, I think I'm just over taking it personally. The person never looks at me like or you just don't really like the way I look. And you always oh geez. Oh,

22:02 no, just kidding. No, I think it's okay, I do have a Logitech. I have my MacBook in the I would be off to the side as well where the cameras but I got a little USB camera to go at the top. Okay, just go get a USB camera. Yeah, who knows? But, okay. Anyway, that was it. And also, for some reason, I've got an hour and a half extra with no commute time. But I don't know where it goes. I don't seem to have more time in the day. I seem to have less time. But yeah, anyway, maybe you're more accessible. I mean, you used to be like kind of accessible to the people who are near you. And now the entire company has equal access to you and your time, right? Yeah, I booked it on your Outlook calendar. Oh, no, not my God. Look at that.

22:02 Anyway, okay. Got to know where my time goes either. But yeah, we don't have more. I've lost getting used to that. Although I did have to drive my daughter to school. And sometimes and that time it's back. So yeah, I guess I have some time as well. I have a quick follow up really, really quick. So we talked about superstring and their benchmarks last week the benchmarks showing that like superstring is much faster on Python and lower memory usage on Python for cool a bunch of operations and whatnot. And I convinced Matt Harrison to cover it and and whatnot. But on Twitter's a couple people are like, Hey, I looked at the code and I don't really know where the memory improvements are coming from. If you look at the benchmark stuff, honestly, I don't know how much better it is or isn't I haven't dug super deep into it. But it looks like a lot of the improvements in speed are around slices and like new string creation is not necessarily that much better. Anyway, just wanted to link to a conversation.

22:02 with Anthony Santilli and a few other folks who are chatting about that, so might want to jump in if you're like, hear about superstring. Yeah. And also, I'm glad you brought it up because I really love that, that people are calling us and stuff like people pay attention and go, Hey, wait a second, you've you've covered something. And I don't think that it's as cool as you think it is. That's Yeah, that's why we have awesome listeners. Like, usually the feedback is you covered this one thing. Did you know there are seven others like it that you've never heard of? Or like no, or why did you cover this other thing you don't know about? Well, because I didn't know about it till now. Yeah. Are you ready for a joke? I'm so ready. All right, this one is a little bit. We've covered this before, but like 75 episodes ago or something like that. So I feel like it's okay to cover it again. Because I've talked a lot about Windows, Windows subsystem for Linux. You just talked about the the sharing keyboard around it. So you're in all good natured joking at windows. Here's a joke. Do you know how many programmers it takes to kill a cockroach know how many to one holds the other installs of windows on it?

22:02 That's funny. It takes way more than one person to install Windows.

22:02 Oh, fun. All right. Well, that's good. Good topics this week, Brian, thanks for sharing me with with everyone. Thank you. You bet. Bye. Thank you for listening to Python bytes. Follow the show on Twitter via at Python bytes. That's Python bytes as mb yts and get the full show notes at python If you have a news item you want featured just visit Python by set FM and send it our way. We're always on the lookout for sharing something cool. On behalf of myself and Brian rockin. This is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.

Back to show page