WEBVTT 00:00:00.001 --> 00:00:03.720 Hey there, thanks for listening. Before we jump into this episode, I just want to remind you 00:00:03.720 --> 00:00:09.400 that this episode is brought to you by us over at Talk Python Training and Brian through his pytest 00:00:09.400 --> 00:00:14.680 book. So if you want to get hands-on and learn something with Python, be sure to consider our 00:00:14.680 --> 00:00:21.220 courses over at Talk Python Training. Visit them via pythonbytes.fm/courses. And if you're 00:00:21.220 --> 00:00:26.820 looking to do testing and get better with pytest, check out Brian's book at pythonbytes.fm slash 00:00:26.820 --> 00:00:32.240 pytest. Enjoy the episode. Hello and welcome to Python Bytes, where we deliver Python news and 00:00:32.240 --> 00:00:38.740 headlines directly to your earbuds. This is episode 245, so it's not the first time. Recorded August 00:00:38.740 --> 00:00:46.940 4th, 2021. I'm Brian Okken. I'm Michael Kennedy. I'm Juanpe. So Juanpe, thanks so much for coming on 00:00:46.940 --> 00:00:51.360 the show. Can you introduce yourself a little bit before we get into it? Thank you very much for 00:00:51.360 --> 00:00:57.840 having me. So my name is Juanpe. I'm from Spain and then my PhD in particle physics has been working 00:00:57.840 --> 00:01:04.980 at CERN for four years. Then two years after my PhD finished, I decided to step away from academia and 00:01:04.980 --> 00:01:09.660 start working in industry. And right now I'm working at FinancialForce, which is a company that develops 00:01:09.660 --> 00:01:15.440 products for Salesforce. So I'm not developing products, I'm in the analytics team. So my job is 00:01:15.440 --> 00:01:22.320 to analyze internal data as well as usage, product usage from a customer to allow the board to take 00:01:22.320 --> 00:01:27.600 data different decisions and how the company should go forward. Nice. Yeah, super interesting. Give us 00:01:27.600 --> 00:01:32.680 your thoughts real quick on one hand working for a place like CERN and then the other working on a place 00:01:32.680 --> 00:01:38.720 that provides enhancements to Salesforce. Those sounds so different. Are they really that different or are they 00:01:38.720 --> 00:01:44.160 similar or what's the story? Part? I mean, of course they're different, but there is a big part which is 00:01:44.160 --> 00:01:50.160 very much the same, at least in the team that I'm working on. Because at CERN, basically what you do is 00:01:50.160 --> 00:01:56.040 you don't know the answer to anything and you need to first know what you need to ask yourself. And this is 00:01:56.040 --> 00:02:01.560 very similar to what happens today in my current job. Because for instance, marketing come and say, 00:02:01.880 --> 00:02:09.560 we have this whatever campaign and we want to know if we're targeting right. And I need to know what do I need 00:02:09.560 --> 00:02:17.240 to do to answer that question, but neither marketing knows. So it's like, let's figure things out. But yeah, I mean, 00:02:17.240 --> 00:02:25.400 it's a pretty drastic change, but I don't know. I got a feeling that I needed to switch. I like coding a lot and I felt 00:02:25.400 --> 00:02:31.800 at some point that I was enjoying more the coding part of being a physicist than the physics part. So I said, 00:02:31.800 --> 00:02:34.840 I mean, you basically described why I'm not in math anymore. 00:02:34.840 --> 00:02:38.120 Yeah. 00:02:38.120 --> 00:02:42.840 I was working on projects and I was having so much fun and writing code on these silicon graphics, 00:02:42.840 --> 00:02:47.420 like huge computers and stuff. And then there'd be parts where I'd be like, ah, this part's not so fun. 00:02:47.420 --> 00:02:51.460 This part's amazing. And I realized the programming parts were amazing. And when I had to get down to 00:02:51.460 --> 00:02:55.860 solving the math bits, I'm like, ah, darn, I gotta put it away, go work on the math again. 00:02:55.860 --> 00:03:01.720 I mean, I remember the last year and a half, I was working on a project that was literally designing a system 00:03:01.720 --> 00:03:09.880 that worked within GitLab CI to automate paper review publishing. So you don't need to have a lot of 00:03:09.880 --> 00:03:15.240 people reading the paper and say, oh, this rule is not matched or do you need to fix this image? 00:03:15.240 --> 00:03:22.120 So I built an entire pipeline in Python to check all of this that works based on pull requests and groups and so on in GitLab CI. 00:03:22.120 --> 00:03:27.640 And I thought I've been a year and a half not doing almost any physics. So my physics work, 00:03:27.640 --> 00:03:34.120 it was related to review paper because I was a chair of an editorial board. So I had an analysis. It was pretty cool, 00:03:34.200 --> 00:03:41.000 but I wasn't, I wasn't doing it. I received version review the made comment, fix this, fix that, then go back to write 00:03:41.000 --> 00:03:42.360 a pipeline to make the pipeline. 00:03:42.360 --> 00:03:47.160 Yeah, exactly. Yeah. That sounds really cool. Yeah. Go ahead. 00:03:47.160 --> 00:03:48.680 Will you kick us off today? 00:03:48.680 --> 00:03:53.320 Will you want to hear about the state of the developer world? How's that sound? 00:03:53.320 --> 00:03:54.120 I like state. 00:03:54.120 --> 00:03:59.400 Yeah. Yeah. So here's an interesting survey results, I guess, put together by JetBrains, 00:03:59.400 --> 00:04:04.120 the state of the developer ecosystem 2021. And I thought this would be fun to talk about because 00:04:04.120 --> 00:04:11.720 we do cover like the PSF state of Python survey and things like that. But I thought it'd be fun to 00:04:11.720 --> 00:04:17.000 just have a quick look at the broader landscape, what people are doing and where Python fits into 00:04:17.000 --> 00:04:21.480 that. And you know, JetBrains has done a really good job with the PSF survey. So I thought, you know, 00:04:21.480 --> 00:04:26.520 this, this will be similar. So let's check that out. So let me give you some stats and some rundown on 00:04:26.520 --> 00:04:33.080 this. So basically the idea is it presents the results of the fifth annual developer ecosystem survey 00:04:33.080 --> 00:04:39.240 conducted by JetBrains and it went out to 31,000 or had input from 31, 32,000 people. All right. 00:04:39.240 --> 00:04:44.200 So there's a couple of interesting things they're doing in the presentation here, but say in that 00:04:44.200 --> 00:04:50.280 world, JavaScript is still the most popular language. Not if you ask Stack Overflow, but of those 32,000 00:04:50.280 --> 00:04:58.280 people or whatever, Python is more popular than Java overall. However, Java is used more as the main 00:04:58.280 --> 00:05:03.720 language. So there's more people using Python for extra things or for other things and so on, 00:05:03.720 --> 00:05:07.560 which I think that jives pretty well with my understanding of Python is that it's this really 00:05:07.560 --> 00:05:13.160 amazing way to like bring in a little interactivity, bring in a little bit of analysis, a little Jupyter 00:05:13.160 --> 00:05:17.880 notebook or something, even if it's not your, your main focus, right? You might be an economist, 00:05:17.880 --> 00:05:22.760 you're not even a programmer and, but you're still Python person in a sense, whereas you probably wouldn't 00:05:22.760 --> 00:05:28.200 be a Java person as an economist most of the time. Yeah. I'm a test. I use Python for testing. 00:05:28.200 --> 00:05:35.000 Yeah, for sure. So let's see the top five languages that developers are planning to adopt 00:05:35.000 --> 00:05:40.840 are Go, Kotlin, TypeScript, Python, and Rust. And the fastest growing languages are Python, 00:05:40.840 --> 00:05:47.960 TypeScript, Kotlin, SQL, and Go. So for example, JavaScript was the most popular language. Java was 00:05:47.960 --> 00:05:52.280 the most popular main language, but it's, they're neither the fastest growing languages. So that's 00:05:52.280 --> 00:05:59.480 pretty much pretty interesting. Of this group, 71% people work on some sort of web backend APIs, 00:05:59.480 --> 00:06:06.120 Flask apps, or, you know, Go apps or whatever. So they have a lot of interesting stuff here in terms 00:06:06.120 --> 00:06:12.440 of analysis. So they have these blocks that show how popular a language is, it's been used, or how 00:06:12.440 --> 00:06:18.360 likely people are to adopt it and pick it up. So there's a bunch of grids. If you go to the report 00:06:18.360 --> 00:06:23.160 and you can check them out and basically the orange is the current state of the world in the, 00:06:23.160 --> 00:06:29.560 there's a darker, almost black that is like the derivative. Like how quickly is that world changing 00:06:29.560 --> 00:06:36.600 for the upswing, right? So for example, JavaScript has more orange squares, but it doesn't have as quick 00:06:36.600 --> 00:06:42.360 of a growth or a planned growth, I guess. So Python has one of the larger ones of those. So does TypeScript 00:06:42.360 --> 00:06:46.200 as well. And those are interesting to look into. You can compare those against different things. 00:06:46.200 --> 00:06:50.760 You can also see the popularity of the language over time. Python's been going up and up and up, 00:06:50.760 --> 00:06:56.280 although this year is kind of plateaued in this report. So that's, you know, maybe something worth 00:06:56.280 --> 00:07:01.160 noting. There's obvious things going down, like objective C, you'd be insane to work on objective 00:07:01.160 --> 00:07:06.200 C right now. And Swiss, Swift is like replaced it. Although that's going down as well. Let's see, 00:07:06.200 --> 00:07:10.360 there's a few more things. They have these really interesting graphs that are both like grids, 00:07:10.360 --> 00:07:15.400 but also heat maps. So you can, it'll let you answer questions like, okay, if I am currently a 00:07:15.400 --> 00:07:22.360 Swift developer, what is the likelihood that I'm going to adopt Python? 6%. But if I'm a Kotlin developer, 00:07:22.360 --> 00:07:29.240 that's 8% likelihood that I'm going to adopt. Oh no, I'm going the wrong way. If I'm a Kotlin developer, 00:07:29.240 --> 00:07:35.560 I'm 10% likely to adopt, to move to Python and so on. So there's a lot of sort of like flow from one 00:07:35.560 --> 00:07:39.320 language to another. I haven't seen any analysis like this anywhere else. Have you? 00:07:39.320 --> 00:07:41.240 No, that's pretty interesting. 00:07:41.240 --> 00:07:41.240 Yeah. 00:07:41.240 --> 00:07:44.360 My head's looking at correlation or something. What's the first role? I'm curious. 00:07:44.360 --> 00:07:46.280 I'm not planning on changing. 00:07:46.280 --> 00:07:48.280 So they are the most likely to change. 00:07:48.280 --> 00:07:51.800 Yeah. They're just stuck. They're just staying. 00:07:51.800 --> 00:07:56.680 Yeah. All right. Let's see. Also interesting operating systems people use for development, 00:07:56.680 --> 00:08:03.000 61% windows, 47% Linux, 44% macOS, which that's pretty high for macOS, given its general 00:08:03.000 --> 00:08:06.440 popularity amongst like the computing world, I think. 00:08:06.440 --> 00:08:08.840 Yeah. I think Linux is pretty high too. 00:08:08.840 --> 00:08:09.640 Yeah. 00:08:09.640 --> 00:08:10.760 It doesn't surprise me. 00:08:10.760 --> 00:08:15.720 Yeah, exactly. And then 1% other, who knows what that is. Also questions about people using 00:08:15.720 --> 00:08:21.160 the windows subsystem for Linux and stuff like that. There's also, if you're interested, 00:08:21.800 --> 00:08:26.920 a similar heat map for like what type of software do you develop? So if you're trying to understand 00:08:26.920 --> 00:08:33.000 where, like if I develop this kind of software, what is the distribution for programming languages 00:08:33.000 --> 00:08:37.080 there? Right. Like it's interesting to say Python is popular or JavaScript is popular, 00:08:37.080 --> 00:08:42.920 but if I'm an embedded system developer, is JavaScript still popular? I don't know. Probably not. Maybe, 00:08:42.920 --> 00:08:48.040 but maybe not. Right. Maybe C is like really popular. So there's a really cool thing called what types 00:08:48.040 --> 00:08:53.080 of software do you develop. There's like a grid plus heat map plus intersection of language and type. 00:08:53.080 --> 00:09:01.160 So if I develop security software, there's a 9% chance that I would be doing Python versus a 6% 00:09:01.160 --> 00:09:05.800 chance of Java. On the other hand, if I do blockchain, how does that break down and so on? Let's see where 00:09:05.800 --> 00:09:13.480 is Python kind of notable? On utility little scripts, it's quite popular there. Yeah. Database backends, 00:09:13.480 --> 00:09:20.840 pretty popular in that area. Let's see. Another one that maybe is standout would be programming tools. 00:09:20.840 --> 00:09:24.200 Actually, that's pretty interesting and so on. Yeah. What do you guys think of this? 00:09:24.200 --> 00:09:29.800 I think it's weird that there's 39% of the C++ developers are developing websites. What the heck? 00:09:29.800 --> 00:09:36.920 Yeah. Yeah. What are they doing back there? Maybe the backend. Yeah. Should we both in the middle? I don't 00:09:36.920 --> 00:09:41.960 know. But it's weird. Yeah. Yeah. Yeah. That is quite interesting. And then you get the standard 00:09:41.960 --> 00:09:45.880 business intelligence. It makes sense. Yeah. The business intelligence one, that one, 00:09:45.880 --> 00:09:51.320 Python is definitely crushing it there, right? It's like 30% versus 10, 15, 20% for the others. 00:09:51.320 --> 00:09:57.240 Yeah. I guess one more, there's all these different things you all can dive into. I guess one more area 00:09:57.240 --> 00:10:02.760 that might be worth interesting is they broke down like the type of coding and software activities you do 00:10:02.760 --> 00:10:09.160 based on gender. So for example, if you're male, like how likely are you to do straight programming 00:10:09.160 --> 00:10:15.640 versus testing versus user experience type stuff or versus female? And let's see. So there were some 00:10:15.640 --> 00:10:20.120 takeaways. It says women are more likely than men to be involved in data analysis, machine learning, 00:10:20.120 --> 00:10:27.400 UI design, and research, but less likely to be in directly doing infrastructure development or DevOps. 00:10:27.400 --> 00:10:33.480 But I mean, I kind of had that sense as well. But just, I mean, my personal experience is completely the 00:10:33.480 --> 00:10:41.480 opposite. So most of the DevOps people I work with are women, but I think it kind of makes sense. I mean, 00:10:41.480 --> 00:10:45.560 in the industry for what I'm seeing. But for mine, it's completely the opposite. 00:10:45.560 --> 00:10:50.360 Interesting. Yeah. So I'll leave this out here for people to go dive into and explore more. I feel 00:10:50.360 --> 00:10:54.120 like I've gone probably over enough details there to give you all a sense, but there are some 00:10:54.120 --> 00:10:56.040 interesting things to be learned, I think. 00:10:56.040 --> 00:10:57.080 Yeah, definitely. 00:10:57.080 --> 00:10:57.720 Very cool. 00:10:57.720 --> 00:11:02.280 Yeah. And Matt out there in the live stream points out that that might be more than 100%. I'm not sure 00:11:02.280 --> 00:11:06.600 which part you're talking about. I do believe a lot of these had multiple, you could check 00:11:06.600 --> 00:11:11.720 multiple things. Like which languages am I willing to adopt? Well, I might be adopting both SQL and 00:11:11.720 --> 00:11:13.880 Python in the next year. Something like that. 00:11:13.880 --> 00:11:20.200 Yeah. And I think a lot of people are perpetually going to start learning Rust or Go, but never 00:11:20.200 --> 00:11:20.760 starting. 00:11:20.760 --> 00:11:22.600 That's true. 00:11:22.600 --> 00:11:23.800 It's only 12 months out. 00:11:23.800 --> 00:11:25.000 It's not much. 00:11:25.000 --> 00:11:34.520 All right. Cornell. So this was suggested by Yale Mintz. And Michael, you know where Cornell comes 00:11:34.520 --> 00:11:40.120 from apparently? I'm thinking Soundgarden. Some good 90s grunge. I mean. 00:11:40.120 --> 00:11:50.120 Okay. Maybe. So Cornell is a record and replay mock server. And we're going to link to the tool, 00:11:50.120 --> 00:11:58.120 but also there's an introduction blog post about it. And it supposedly makes it really simple to record and 00:11:58.120 --> 00:12:03.720 replay features to perform end-to-end testing in an isolated test environment. 00:12:03.720 --> 00:12:10.360 So the kind of the gist around it, there's a cool tool called VCRPy, which saves cassette 00:12:10.360 --> 00:12:17.160 files for you. You send it requests and you get replies back and then you can save those request 00:12:17.160 --> 00:12:25.960 reply sessions and stuff. And this is a bundling VCRPy with Flask to make a little server. And it's actually 00:12:25.960 --> 00:12:32.040 really kind of a cool idea. The idea, one of the things around it is that you can do, you're not just 00:12:32.040 --> 00:12:37.240 mocking one service. You can just mock in any external service that you're dealing with. It'll, you know, 00:12:37.240 --> 00:12:44.120 do replays on that. And one of the benefits over rolling your own mocks or rolling your own test server or test 00:12:44.120 --> 00:12:52.120 service is that you can, that you don't really have to think about designing the whole thing. It just kind of replays everything. 00:12:52.120 --> 00:12:53.080 Yeah, that is cool. 00:12:53.080 --> 00:12:56.520 It looks pretty fun. I haven't played with it yet, but definitely want to. 00:12:56.520 --> 00:13:01.800 Hey, speaking of play with it, click on documentation. I think it is on that page right there on the bottom left. 00:13:01.800 --> 00:13:02.920 Okay. Documentation. 00:13:02.920 --> 00:13:08.600 And then click on the documentation of that page. There you go. And so you have this kind of like 00:13:08.600 --> 00:13:14.200 series of animated GIFs of scene in action. And I think that that's kind of cool, right? Like you can, 00:13:14.200 --> 00:13:18.840 you don't go along and say, oh yeah, here you're recording a bunch of API calls and then the workflow 00:13:18.840 --> 00:13:23.320 of like how you create it. I just want to give a shout out to the animated GIFs for like, is this 00:13:23.320 --> 00:13:28.200 interesting to me? Let me just watch the GIFs instead of actually take the time to try to adopt it. 00:13:28.200 --> 00:13:31.720 It's simple, but it seems really effective. OnePay, what do you think? 00:13:31.720 --> 00:13:36.600 It's a good idea. No, it's a really good idea. I mean, there are many projects that you think this 00:13:36.600 --> 00:13:41.800 might be cool to work with. And then you start reading walls of texts and halfway through, I don't 00:13:41.800 --> 00:13:47.720 know if it's interesting, but I mean, it's been half an hour. So having a bunch of GIFs is eye-catching. 00:13:47.720 --> 00:13:48.280 Yeah. 00:13:48.280 --> 00:13:49.480 Yeah, for sure. For sure. 00:13:49.480 --> 00:13:49.960 Yeah. 00:13:49.960 --> 00:13:55.000 Yeah. Also, I just want to quick shout out to the live stream. German points out from his experience, 00:13:55.000 --> 00:13:59.080 the data analysis have more men than women, but it could be biased due to the tech sector 00:13:59.080 --> 00:14:02.920 having more men in general. I do think that that's true. I think what they said is, if you're a woman, 00:14:02.920 --> 00:14:06.440 what are you more likely to be doing? If you're a man, what are you more likely to be doing? 00:14:06.440 --> 00:14:13.000 And it's like, of that population, what areas do you work in? Not that user experience has more men 00:14:13.000 --> 00:14:19.560 or women. I don't think it addresses that question. I think my thoughts here, there's a lot of women who 00:14:19.560 --> 00:14:25.640 end up in programming, not down the traditional computer science path. They go into biology and 00:14:25.640 --> 00:14:29.640 then they're like, oh, I've actually learned a little Python and now I really like it. And I work here and 00:14:29.640 --> 00:14:34.200 it's amazing. But they kind of get pulled in tangentially where there's a lot of guys that 00:14:34.200 --> 00:14:38.600 like sign up for computer science and they just go through that path. And some of the areas that were 00:14:38.600 --> 00:14:43.320 called out are more likely to take the straight computer science path people rather than the, 00:14:43.320 --> 00:14:49.160 I got interested and I came in through like psychology or something else where there would be more women. 00:14:49.160 --> 00:14:53.400 So I don't know. I would love to have more women in there, but I think that this is my, in broad, broadly 00:14:53.400 --> 00:15:00.040 speaking, but I think this is my, my thoughts about why maybe those different areas seem to attract people 00:15:00.040 --> 00:15:03.400 not so directly down the computer science path. Anyway. Yeah. All right. 00:15:03.400 --> 00:15:07.800 one Bay, you're up. You talk to us about the next thing you got here. 00:15:07.800 --> 00:15:15.480 Sure. so I want to talk about factory boy. I think it's a very well known library, to 00:15:15.480 --> 00:15:21.720 basically mock objects, when you're running tests and both this and the next tool I'm going to 00:15:21.720 --> 00:15:28.360 talk about came because I, we were working on a system that replicates and it's an entire Salesforce org. 00:15:28.360 --> 00:15:34.280 So we have a infrastructure we've built that takes everything you have, every object you have in Salesforce 00:15:34.280 --> 00:15:39.480 and copy it to a database. This is a way we have to have daily snapshot of the data that we can do 00:15:39.480 --> 00:15:44.360 a time series and analysis and all the models that we have on it, instead of being furious, 00:15:44.360 --> 00:15:50.200 let's say when you modify it, it's lost. So for this, we obviously need to communicate a lot with the API 00:15:50.200 --> 00:15:59.240 in Salesforce. And when you get, API responses, there you need to not only treat the Jason, 00:15:59.240 --> 00:16:04.840 plainly say there's the pain Jason object, but you will like also to have some kind of object 00:16:04.840 --> 00:16:10.520 representation. And for this, I think it's not news for anyone. The Pydantic right now is, taking 00:16:10.520 --> 00:16:17.000 the floor. and, the biggest issue came, when we need to start writing tests for it, because, 00:16:17.000 --> 00:16:23.320 um, we get the JSON file, we stick it in the Pydantic object, it validates everything. 00:16:23.320 --> 00:16:27.640 Everything's beautiful and works fine. But then we have a bunch of objects, a bunch of fields on the 00:16:27.640 --> 00:16:32.520 object that cannot be nulled for instance, or they are not optional. So they need to come in the API 00:16:32.520 --> 00:16:36.840 and we need to validate for those because if the API does not return any of those, it should break and 00:16:36.840 --> 00:16:42.600 tell us, look, this is wrong. It's not what you expected. So when we wanted to, write tests for 00:16:42.600 --> 00:16:48.200 those, and we wanted to create objects for those, in each test, we noticed that out of hundreds of 00:16:48.200 --> 00:16:53.880 fields, we might need to feel, I don't know, probably 80, 90 of them because they were, 00:16:53.880 --> 00:16:59.480 mandatory and it started to be very tedious. And I remember I opened an issue in the Pydantic. I say, 00:16:59.480 --> 00:17:06.680 hey, have you, thought about probably allowing creating an object with random fields that validate 00:17:06.680 --> 00:17:11.960 properly? Like this feels an integer between 10 and 20. So I just don't want to feel it. I don't want to 00:17:11.960 --> 00:17:16.280 feel any of those because I don't care for this test. Is there a way that I can say, okay, just feel 00:17:16.280 --> 00:17:20.680 whatever it validates. And they say, no, it's out of the scope of Pydantic, which also makes sense. 00:17:20.680 --> 00:17:25.080 I just wanted to ask in case. and they said that probably in factory boy, they might be 00:17:25.080 --> 00:17:29.480 interested in this. So I went to factory boy and I read the documentation. it was pretty cool 00:17:29.480 --> 00:17:35.880 because it allows you to create, you define an inside class. So it's a meta class, not a meta 00:17:35.880 --> 00:17:42.840 class in the terms of, Python meta classes, but it's a class called meta within the factory 00:17:42.840 --> 00:17:46.520 that you want. It's weird because everything you say, yeah, this is the meta class. Why do 00:17:46.520 --> 00:17:52.680 meta class? No, it's a class. So you inherit from factory. Then you define a class called meta meta 00:17:52.680 --> 00:17:57.960 where you define what is your model. So this is the object I want to mock with this factory. And then 00:17:57.960 --> 00:18:04.040 you can define many, fields with their default values. The cool thing about this is that it implements 00:18:04.040 --> 00:18:08.840 also faker. So you can say, if I have a username, I don't want to fill it. Just give me an username. 00:18:08.840 --> 00:18:13.480 A faker will give you. Yeah. Faker is really cool for generating stuff like that. Yeah. Yeah. 00:18:13.480 --> 00:18:18.680 And the amount of plugins you find for faker is, outstanding. So you can fake almost anything 00:18:18.680 --> 00:18:24.040 you think of. So the cool thing about this is that it's not only, you plug in the class 00:18:24.040 --> 00:18:27.880 that you have and it will fill it, but you also can work with over M's. Like you can use 00:18:27.880 --> 00:18:35.560 C-blocking over M's or Django over M's and it will generate an object for this over M based 00:18:35.560 --> 00:18:41.080 on whatever you set. These are the default values. So I thought it would be great if I could do this 00:18:41.080 --> 00:18:45.960 also for Pydantic. So I could just say, okay, these are the mandatory field that put something 00:18:45.960 --> 00:18:50.520 faker can think about it and then we're ready to go. But reading documentation, it didn't appear 00:18:50.520 --> 00:18:55.320 anywhere and I thought, hmm, maybe I cannot use it for this case. So I went ahead and opened an issue and 00:18:55.320 --> 00:18:59.880 say, are you thinking about putting this also to work with Pydantic? I mean, it's now is, 00:18:59.880 --> 00:19:04.680 booming and everyone is using it. And if you are reading JSON from an API, it's very likely that you 00:19:04.680 --> 00:19:08.680 have hundreds of fields you don't care about. You might want to fill it with whatever. And I remember 00:19:08.680 --> 00:19:14.520 the author said, I didn't know this. I didn't know Pydantics. Cool. You mentioned it, but 00:19:14.520 --> 00:19:19.240 internally what FactoryGo is doing is creating a dictionary with the parameters you want to fill in 00:19:19.240 --> 00:19:23.480 and just unpacking it in the construction of the class. have you tried it? And I was like, 00:19:23.480 --> 00:19:28.040 no, I have not tried it. And when I tried it worked. So it works perfectly. I mean, 00:19:28.040 --> 00:19:34.120 maybe there are some quirks of Pydantic that it cannot cover. But, if you're using Pydantic to 00:19:34.120 --> 00:19:40.120 store your data from API calls and so on from JSON and validates and so on, FactoryGo is pretty 00:19:40.120 --> 00:19:44.360 cool. I mean, the amount of things you can do with this, you create a, you can create many 00:19:44.360 --> 00:19:48.040 factories for the same class. So you can create fixtures. Like, I don't know if you want to mock a 00:19:48.040 --> 00:19:53.480 user. You can have an admin or a buyer or whatever, and, then you can just define 00:19:53.480 --> 00:19:57.720 different factories and it will give you the usage you've defined. And, it's also pretty cool 00:19:57.720 --> 00:20:05.640 because the faker is randomized, beneath it. So if there is, there are parts of your object that 00:20:05.640 --> 00:20:11.400 your code does not care about, it's also a good test to have those parts being random because, 00:20:11.400 --> 00:20:15.160 if it really doesn't care, you don't care what those fields are. And then at some point 00:20:15.160 --> 00:20:20.040 your test fail, it happens once it means that you actually can just fix something. 00:20:20.040 --> 00:20:25.720 Yeah, absolutely. I did see that if you need repeatable tests, but you want faker to generate 00:20:25.720 --> 00:20:28.760 random stuff, there's a way to seed faker. Exactly. 00:20:28.760 --> 00:20:33.560 Generate the random values, but do it in a consistent way. And one way you might want that is if you have an 00:20:33.560 --> 00:20:38.600 edge case or some value that breaks the test, and then you want to put a break point and press debug 00:20:38.600 --> 00:20:43.880 and go through it again. But like, you know, how are you going to get it to hit that case again in a 00:20:43.880 --> 00:20:48.280 predictable way? Right. So if you, if you trigger, if you tell it to say, always do the same thing, 00:20:48.280 --> 00:20:52.680 but randomly, you know, you'll make it so you can go back and look at it a second time and figure out 00:20:52.680 --> 00:20:58.200 what's up. Yeah. You can fix that. Sometimes it's also good to have them fixed, even if you don't care. 00:20:58.200 --> 00:21:02.840 I mean, you need to have a daytime and for some reason you need to have the daytime being whatever and 00:21:02.840 --> 00:21:08.200 whatever, but you can validate for it. So you can just, or either set it or ensure that it's fixed. 00:21:08.200 --> 00:21:12.360 Yeah. There are many use cases that you can exploit that thing. And it's actually really cool. 00:21:12.360 --> 00:21:19.000 Yeah. Usually I almost always seed faker because I just, I don't, I don't, I'm not using it because 00:21:19.000 --> 00:21:22.680 I want the randomness. So I'm using it because I don't want to come up with the data. 00:21:22.680 --> 00:21:27.880 Yeah, exactly. So make it so that it does the same thing every time, just gives you the random 00:21:27.880 --> 00:21:32.120 day that you want. That's right. Agreed. Very, very cool. All right. The next one up actually is 00:21:32.120 --> 00:21:38.200 pretty sort of related to that. It's called PI instrument. Have either of you heard of PI instrument? 00:21:38.200 --> 00:21:41.560 Not until now. When I read the notes and it sounds pretty cool. 00:21:41.560 --> 00:21:42.360 Yeah. Right. 00:21:42.360 --> 00:21:42.360 Yeah. 00:21:42.360 --> 00:21:43.480 No, I haven't. 00:21:43.480 --> 00:21:49.160 Yeah. So it's a call stack profiler for Python, which is pretty cool, right? It's just going to tell 00:21:49.160 --> 00:21:54.280 you where your code is slow, but it's, you know, it's, it looks really clean. And when you look at 00:21:54.280 --> 00:22:01.880 the output, it can actually give you the results in the terminal. So if you want to see, you know, 00:22:01.880 --> 00:22:08.200 like you run this thing instead of saying Python, my exam, my Python.py file, you would just say 00:22:08.200 --> 00:22:13.000 PI instrument, that same file and it'll run it. But then at the end, it's going to generate a whole 00:22:13.000 --> 00:22:19.880 bunch of things about how long it took and whatnot. And then you actually get like colored output in the 00:22:19.880 --> 00:22:25.800 terminal showing which lines of code are spending how much time in different places. And it seems like it's a 00:22:25.800 --> 00:22:29.000 real good way to just sort of quickly dive in on where you're spending your time. 00:22:29.000 --> 00:22:33.480 Yeah. I'm definitely going to try this. It's cool. Yeah. Yeah. One thing I like about it is the simplicity of 00:22:33.480 --> 00:22:38.440 like pip install, PI instrument, PI instrument, your file. That, that'll give you the answer, right? Like 00:22:38.440 --> 00:22:44.920 That, that for me, solved it. I mean, every time you want to do some profiling, you spend some time 00:22:44.920 --> 00:22:49.240 tweaking things. So you get what you want. The fact that this is just running with PI instrument, 00:22:49.240 --> 00:22:52.280 whatever script you want. I mean, I'm going to try for sure. 00:22:52.280 --> 00:22:57.880 Yeah. Yeah, for sure. And when you do profiling, you end up in this sort of quantum mechanics 00:22:57.880 --> 00:23:01.240 world of if you observe a thing, you've changed it. Yeah. 00:23:01.240 --> 00:23:07.000 And so there might be code that is like this half is 50, 50, and this half is 50, 50 at the time. 00:23:07.000 --> 00:23:12.760 But one is calling an external system once and the other is a tight loop. And if you profile that with 00:23:12.760 --> 00:23:18.280 instrumentation, it's going to wreck it. It's going to make the loop look way slower because 00:23:18.280 --> 00:23:22.760 now you've added a bunch of overhead each step where there's very little overhead to this external 00:23:22.760 --> 00:23:28.440 service sort of thing. And this one uses sampling and the sampling doesn't really have that effect. 00:23:28.440 --> 00:23:32.920 It just every so often, every millisecond or something that says, what are you doing now? 00:23:32.920 --> 00:23:35.880 What are you doing now? Who called you? What are you doing now? Right. 00:23:35.880 --> 00:23:43.880 And so it's more of a polling sort of thing rather than slowing down line by line code. So that's 00:23:43.880 --> 00:23:46.040 probably worth doing as well. Yeah. That's pretty cool. 00:23:46.040 --> 00:23:51.720 Yeah. It looks like you can specifically jump in and just do a section of your code that you care 00:23:51.720 --> 00:23:57.400 about also. Exactly. If you want to say, you know, so one of the things that I hate about profiling is 00:23:57.400 --> 00:24:03.240 it'll say 87% of your time was in the startup code and the imports. You're like, yeah, okay. That 00:24:03.240 --> 00:24:07.640 that's not relevant to me. What I want to know is the part that I'm actually trying to test here. 00:24:07.640 --> 00:24:14.040 How long did I spend there? And please don't pollute that with other junk about like starting up Python 00:24:14.040 --> 00:24:20.120 or loading modules or whatever. Right. And so you can, there's an API and you can say from 00:24:20.120 --> 00:24:27.400 PI instrument import pro profiler, and then you can do a context block in there and run it. And just 00:24:27.400 --> 00:24:32.200 that code will tell you like how long it takes. Cool. Does anything else jump out there out at you, 00:24:32.200 --> 00:24:37.240 Brian? And like with this example, I got on the screen here, that would be hard. It's an async example 00:24:37.240 --> 00:24:43.160 for one. Yeah. As an async and a weight. And so they recently released PI instrument four, 00:24:43.160 --> 00:24:51.240 which will actually give you the information about the async code as well. Right. So it'll, 00:24:51.240 --> 00:24:55.960 let's see what it says. It has async support. PI instrument now detects when an async task hits 00:24:55.960 --> 00:25:01.880 an await and tracks the time spent outside of the async context under the await. Whereas before it would 00:25:01.880 --> 00:25:07.880 basically just profile the asyncio event loop or something silly like that. Right. So if you're trying 00:25:07.880 --> 00:25:13.800 to profile async and await in asyncio, this might be your best option because it specifically supports 00:25:13.800 --> 00:25:20.360 that. That's good. So what happened before if you use a different profile? It would say, yeah, 00:25:20.360 --> 00:25:26.280 it says you only see the time spent in the run loop and it'll basically tell you like, here you see like 00:25:26.280 --> 00:25:32.840 run once and the select, and then the queue control built in. It's just like, there's this asyncio event 00:25:32.840 --> 00:25:36.840 loop that's cranking around waiting for the signal for the IO to be done. And it just says, well, 00:25:36.840 --> 00:25:41.320 you're waiting on this. You're in the loop. You know what I mean? Yeah. Yeah. Yeah. Yeah. So, 00:25:41.320 --> 00:25:42.760 yeah. Very cool. 00:25:42.760 --> 00:25:47.560 And now you get a little bit better. Like it says, okay, you're awaiting on this line of your code for 00:25:47.560 --> 00:25:51.960 a second or whatever it is. Yeah. There's also, I'll shout out a few more things here. Is it in this 00:25:51.960 --> 00:25:57.480 stock? Yeah. So they also, there's also a bunch of simple authentication they did previously about 00:25:57.480 --> 00:26:04.600 network calls and stuff. And there's, there's an interactive Vue.js app that you can get with flame graphs. 00:26:04.600 --> 00:26:09.080 So instead of looking at the terminal, you can look at it in your web browser and explore into 00:26:09.080 --> 00:26:13.240 those. Yeah. There's a lot of neat little things here pulled out of the show notes, but it seems like 00:26:13.240 --> 00:26:17.640 a really nice way to do some profiling and you just high instrument your code and you have a look. 00:26:17.640 --> 00:26:22.360 Cool. Yeah. I personally kind of like the default output. I'm, I know that a lot of people like flame 00:26:22.360 --> 00:26:28.760 graphs. Like they, they don't really do much for me. They look like, I don't see the data, but it's cool. It has both. 00:26:28.760 --> 00:26:33.800 Yeah. A couple of things for the live chat. Maddie says, pie instrument is a statistical or 00:26:33.800 --> 00:26:39.320 sampling profiler, which is better prepared for profiling. I think it depends. I mean, I do the 00:26:39.320 --> 00:26:46.760 instrument patient ones do give you more precise information, but it's also skewed with the overhead 00:26:46.760 --> 00:26:52.280 of that information. So it's, it depends, but this is the least influential one for sure. And then 00:26:52.280 --> 00:26:57.880 Avaro says, how would you use pie instrument with an entry point? That's a good question. 00:26:57.880 --> 00:27:02.840 Not knowing the answer off the top of my head, maybe make another Python file that just imports 00:27:02.840 --> 00:27:08.120 your library and calls the entry point and then profile that. But yeah, there's a real quick, 00:27:08.120 --> 00:27:13.560 cheat, you know, just make it call it and then, high instrument that file, but there may be 00:27:13.560 --> 00:27:19.240 some way to say like dash M and give it a module and a, thing to do. So yeah, that's it, 00:27:19.240 --> 00:27:23.960 Brian, that's it for a pie instrument. Cool. well, I just wanted to remind everybody that, 00:27:23.960 --> 00:27:30.200 uh, Python 310 release candidate one came out yesterday. So Pablo announced it, just, 00:27:30.200 --> 00:27:36.120 just on the third, I think, I think it was yesterday. not the fourth today. Yeah. Anyway. so 310 is 00:27:36.120 --> 00:27:43.160 out. if you've got, if you've got, there, well, 310 RC one is out the timelines that we're 00:27:43.160 --> 00:27:49.160 looking at then we're getting excited. It's coming up. So the, September 6th is the plan for RC 00:27:49.160 --> 00:27:54.360 two and then October 4th, we're planned is the plan for the official release. So we're 00:27:54.360 --> 00:27:58.840 just really right around the corner. It's nice. and this is definitely a time I know we've brought 00:27:58.840 --> 00:28:04.680 this up before, but if you maintain any third party Python packages, you probably should have already 00:28:04.680 --> 00:28:11.160 been taste testing it against a 310. But if you haven't definitely do it now to make sure that, 00:28:11.160 --> 00:28:16.680 people that use your stuff don't, it doesn't break when they need to. And then we, in the show notes, 00:28:16.680 --> 00:28:22.760 we put, just a list of just a reminder of some of the new changes in 310. we've, 00:28:22.760 --> 00:28:26.920 definitely talked about some of these before structural pattern structure pattern matching 00:28:26.920 --> 00:28:32.040 is the switch statement kind of thing. And then, yeah, lots of these other things we've covered. 00:28:32.040 --> 00:28:38.520 I'm kind of actually, I like the union type union types. So you can like, because there's a lot of 00:28:38.520 --> 00:28:44.200 stuff that I write that the default is none, but the normal type is something else. So you can really 00:28:44.200 --> 00:28:50.280 easily say the type is none or it or something like that. and that's a lot cleaner than you 00:28:50.280 --> 00:28:56.040 used than, than before. I'm, I've already started using 310 to test everything that I support. 00:28:56.040 --> 00:28:58.280 So hope everybody else has as well. 00:28:58.280 --> 00:29:03.720 Yeah, cool. I like the optional length checking and zip, right? Zip taking two collections and you 00:29:03.720 --> 00:29:08.120 want to pair up the items. Like if those things don't match, that should be a problem. Also like the 00:29:08.120 --> 00:29:14.120 or for the types, information. And I think dick and some of those types are now don't require a 00:29:14.120 --> 00:29:19.080 from typing imports. Oh, right. Yeah. yeah, I don't think, I don't see it called out here, but 00:29:19.080 --> 00:29:25.000 one of the problem was, maybe that's explicit type aliasis. I'm not entirely sure, but if you want 00:29:25.000 --> 00:29:31.400 to say this type is a dictionary of strings and, integers, you would have to say from typing 00:29:31.400 --> 00:29:37.720 import capital D dict and then dict square bracket, string comma, and whereas now you can just use 00:29:37.720 --> 00:29:43.240 the lowercase D I C T and you don't have to have that import and you can do that sort of thing to it. 00:29:43.240 --> 00:29:47.880 So I'm looking forward to that. Yeah. A lot of the, a lot of, with this, a lot of the common, 00:29:47.880 --> 00:29:53.800 uh, type type hints, you won't have to do the import anymore. And that's, that's great. So I think that's 00:29:53.800 --> 00:29:58.280 really all I was using the import for was things like dict and set things like that. 00:29:58.280 --> 00:30:04.440 Yeah, exactly. Didn't that, I mean, I seem to remember that 3.10 was the one that was including 00:30:04.440 --> 00:30:10.760 these, built in types without having to import from typing. Didn't that update might break some of 00:30:10.760 --> 00:30:19.480 the libraries that is typing. Like Pydantic and FastAPI. The, the thing that that was, was to use it in, 00:30:19.480 --> 00:30:25.320 basically use it as a string and not actually evaluate the type. I think that like, so if you had your own 00:30:25.320 --> 00:30:29.960 type, your own Pydantic type that was a customer, I think you could put customer, but it wouldn't be 00:30:29.960 --> 00:30:35.400 actually evaluated until a type checker hit it or something like that. Like a forward typing. 00:30:35.400 --> 00:30:41.880 Yeah. Yeah, exactly. So this, this ability to specify the type on like lowercase d dict 00:30:41.880 --> 00:30:47.640 is related, but it's not the same. And I'm pretty sure that that, that fear around Pydantic is not 00:30:47.640 --> 00:30:52.920 in 3.10. Yeah. It either got postponed or rolled back or modified. Yeah. Yeah. 00:30:52.920 --> 00:31:02.120 I just want to talk about the one that says, what was the number six to six. Do you have it? 00:31:02.120 --> 00:31:06.040 yeah. The precise line numbers for debugging and other tools. 00:31:06.040 --> 00:31:12.760 It's one of it's, I think it's very underrated. It's going to be one of those things that when 00:31:12.760 --> 00:31:15.080 people get used to, it's like, I don't know how you live without this. 00:31:15.080 --> 00:31:21.560 Oh yeah. Yeah. There's not a good example shown right off the bat, but it is, it's pretty cool. 00:31:21.560 --> 00:31:25.880 Yeah. Yeah. Yeah, absolutely. Very cool. And then we also have better stack trace message error messages, 00:31:25.880 --> 00:31:29.320 right? Yeah. Yeah. Those are coming. A lot of good things to look forward to. All right. 00:31:29.320 --> 00:31:34.360 One pay you got the last item. Great. I think it's time for it. You want to take us out, right? 00:31:34.360 --> 00:31:42.840 Sure. Yeah. So let's talk about time machine. I said, we were building this, tool that 00:31:42.840 --> 00:31:47.080 copies and entire self-assort, one of the things that we need to work straight everything is to 00:31:47.080 --> 00:31:53.800 timestamp almost every action we do. this means that in many places all over the code, we have a 00:31:54.280 --> 00:32:00.360 daytime UTC now method call. And, when we are testing the, we need to be able to mock it. 00:32:00.360 --> 00:32:07.240 And if you've tried to patch daytime UTC now with a usual patch method, you know, it works, you can do 00:32:07.240 --> 00:32:13.000 it, but, you need to do it with a patch and then you pass the string, but, the module where this 00:32:13.000 --> 00:32:18.600 UTC now call is, and then you're good to go. But when you have this in many files in the same test, 00:32:18.600 --> 00:32:22.600 you need to patch every one of those because otherwise it wouldn't work. So I tried to use 00:32:22.600 --> 00:32:27.720 patch object and patch daytime and say, okay, I want to patch the, it's in our method, this object. 00:32:27.720 --> 00:32:34.120 And it will of course complain and say, you cannot patch a built-in, built-in type like daytime, 00:32:34.120 --> 00:32:41.640 daytime. So I was looking for how we could patch this. And I found, Frisgan, which is a very 00:32:41.640 --> 00:32:47.400 well-known library thing to patch this kind of thing. But suddenly I noticed that once I started using 00:32:47.400 --> 00:32:55.480 Frisgan, all of my tests took much longer to complete, it's not like, deal breaker. 00:32:55.480 --> 00:33:01.240 So it went for probably five minutes to seven or seven and a half, but I was very surprised because, 00:33:01.240 --> 00:33:06.120 um, our pipeline or deployment pipeline already take a long time. So every time I can reduce 00:33:06.120 --> 00:33:11.080 it a minute, it's good for me. And when I saw it going up two minutes, I was surprised why, why is this 00:33:11.080 --> 00:33:16.680 happening? And then I learned that what Frisgan is doing is actually scanning all your dependencies and 00:33:16.680 --> 00:33:23.320 making patch for every call you make to the methods of data. and then, trying to see if there 00:33:23.320 --> 00:33:30.920 was something else I found out, time machine, time machine is a very, cool, not so 00:33:30.920 --> 00:33:37.000 well-known, I think, library that allows you to do basically the same that Frisgan allows you to do. 00:33:37.000 --> 00:33:43.560 So you can just, patch, any, almost any method called in daytime or time, with a simple 00:33:43.560 --> 00:33:48.760 decorator in this, in your test. It's also support pytest fixtures that you can use. the good thing about 00:33:48.760 --> 00:33:55.880 this is that it does not scan for imports of date and daytime. And what it does is actually change the 00:33:55.880 --> 00:34:04.040 underlying C-level calls that you make, to get the time. So every time you say, I want to patch any call, 00:34:04.040 --> 00:34:11.400 uh, to be on January 1st of 2019, for instance, it will just call it normally, but the C, the underlying C calls 00:34:11.400 --> 00:34:16.440 that will be made will return this time instead of the other ones. You don't need to scan everything to patch it. 00:34:16.440 --> 00:34:21.240 another thing that says that I thought it was pretty cool is this, you can let the time 00:34:21.240 --> 00:34:28.760 tick after you patched it. So you say, this is for February 1st of 2018. And once you enter the mock, 00:34:28.760 --> 00:34:34.200 either with, a decorator or with a context manager, you can also use like standard patch, 00:34:34.200 --> 00:34:41.240 um, call, then time start passing, starting on that, time that you mocked, mocked it for. 00:34:41.240 --> 00:34:45.720 so you can do a perf counters and all this thing normally, but if you need to stay in a given 00:34:45.720 --> 00:34:51.400 day for a test, you can do it. So I thought it was pretty cool. It solved my two extra minutes running 00:34:51.400 --> 00:34:56.280 because we have many places and many files in the project where we use it. See now. And, it was 00:34:56.280 --> 00:35:01.560 pretty well. So this, this had, this must've had incremental. I mean, it has a little bit of time 00:35:01.560 --> 00:35:05.240 that has to do its work, but it's, it's fast enough that you're not noticing it then. 00:35:05.240 --> 00:35:08.360 Yeah. I'm not noticing anything. I mean, it runs more or less the same. 00:35:08.360 --> 00:35:13.480 Okay. Well, I mean, I imagine there should be some delay, but it's not as noticeable as, 00:35:13.480 --> 00:35:15.000 what happened with Friskin. Yeah. 00:35:15.000 --> 00:35:19.160 Cause it took them, it took some time. I mean, I'm glad you brought this up. This is cool. 00:35:19.160 --> 00:35:24.360 Yeah. We have a bunch of tests. Yeah, exactly. I say, Brian, you probably, this is kind of in your 00:35:24.360 --> 00:35:29.880 world, right? Like dealing with time as a dependency. Definitely. And there's, there's, there's, 00:35:29.880 --> 00:35:34.280 sometimes it's really, you want it fixed because you really want fixed answers. Cause like you've 00:35:34.280 --> 00:35:39.560 timestamps and stuff are in your data. You're going to have to, I mean, it's good to compare against 00:35:39.560 --> 00:35:45.720 known oracles, but there's all the also times where you, you, and this is where Friskin 00:35:45.720 --> 00:35:52.040 isn't so bad is, but maybe this would be really useful too, is, is if you want to test certain 00:35:52.040 --> 00:35:56.280 things, there's weird quirky dates. You want to make sure that your software deals with certain times, 00:35:56.280 --> 00:36:02.920 uh, fine. Does it work fine when it's running over like, overnight on December 31st to January 00:36:02.920 --> 00:36:08.040 1st, things like that, when the year changes and things like that. exactly. Yeah. Yeah. 00:36:08.040 --> 00:36:12.360 Yeah. You always want to test your boundary conditions, right. And crossing over time 00:36:12.360 --> 00:36:17.480 or weird cases like March 29th and stuff like that. You're like, let me just try that and see if this 00:36:17.480 --> 00:36:22.840 is going to survive. Yeah. Yeah. But then, I mean, to, to, to be fair, I think most of the time, 00:36:22.840 --> 00:36:29.320 things, things like this are used are, like was brought up is that the time shows up in the data. 00:36:29.320 --> 00:36:34.840 So in order to compare the, you know, or the log or something in order to compare those apples to apples, 00:36:34.840 --> 00:36:39.000 it's nice to have the same dates there. I can't, I can't tell you how many times I've had, 00:36:39.000 --> 00:36:43.640 had to compare two log files and strip out the times, because those are the old, 00:36:43.640 --> 00:36:48.120 like those are the, every line's different because the timestamp's different. So yeah. 00:36:48.120 --> 00:36:49.880 Yeah. Very cool. Nice find. 00:36:49.880 --> 00:36:50.840 Right. 00:36:50.840 --> 00:36:52.120 That's all for time machine. Yeah. 00:36:52.120 --> 00:36:58.040 Yeah. Super. well that's our, that's our six items. everybody, have you got 00:36:58.040 --> 00:36:58.920 anything extra, Michael? 00:36:58.920 --> 00:37:05.800 Well, I have the old thing that is new again. Let's see. I have some bandits. So, the, 00:37:05.800 --> 00:37:12.040 the drama around supply chain vulnerabilities and open source repositories goes on. So this, 00:37:12.040 --> 00:37:17.960 this one, I think actually the other article I'm going to talk about, comes to us from Joe 00:37:17.960 --> 00:37:23.960 Riley. Thank you, Joe, for sending that in. But basically there's some more malicious things 00:37:23.960 --> 00:37:30.200 in by PI again, and people just remind everyone to, to be careful and be whitelist off or yeah, 00:37:30.200 --> 00:37:35.080 this one, I don't know what this one was. If it was typo squatting this time around, 00:37:35.080 --> 00:37:40.360 or it was just something else that got put up there. Yeah. There's one is one headline is credit 00:37:40.360 --> 00:37:45.560 card stealing malware found in official Python repository. And the other one is the same one 00:37:45.560 --> 00:37:50.200 about ours technical article says software downloaded 30,000 times from PI PI ransacks 00:37:50.200 --> 00:37:55.160 developer machines, developers machines. Expect to see more of these Frankenstein type things. 00:37:55.160 --> 00:38:00.040 Cause it's a, basically a systemic threat. Like how, how does it get dealt with? Right. I'm not 00:38:00.040 --> 00:38:05.320 sure if they list out. Yeah. So they used, they did interesting stuff as well. Like they did simple 00:38:05.320 --> 00:38:10.760 obfuscation of the code that was being run. So you couldn't look at it and say, look for a credit 00:38:10.760 --> 00:38:15.640 card or look for a Bitcoin wallet, and then go do your evil deeds in Python source code. So they would 00:38:15.640 --> 00:38:23.000 do things like, base 64 and code the Python code, and then just in memory decode it, then run it. 00:38:23.000 --> 00:38:28.440 So they were trying to get around things like that. So anyway, people can check that out. And it's not 00:38:28.440 --> 00:38:35.400 ideal, but just a reminder to be aware. Yeah. Yeah. Yeah. Yeah. Yeah. This is why we can't have nice 00:38:35.400 --> 00:38:39.800 things. Come on people. Why we can't have nice things. Well, I get a couple of things I wanted 00:38:39.800 --> 00:38:46.760 to bring up just things I've been up to. just released episode one 62 of, testing code. And 00:38:46.760 --> 00:38:52.600 I kind of run through, all the different flavors of test-driven development that I know of. 00:38:52.600 --> 00:38:57.400 so there are quite a few versions. So check it out if you're interested in test-driven development. 00:38:57.400 --> 00:39:02.840 And then, I'm just, working on wrapping up the talks and continuous integration chapter for 00:39:02.840 --> 00:39:06.840 the second edition of the pie test. It'll be coming out hopefully within a week. 00:39:06.840 --> 00:39:08.520 Very cool. Good to see you making progress there. 00:39:08.520 --> 00:39:10.440 do you have anything extra, Juanpe? 00:39:10.440 --> 00:39:11.560 Nope. 00:39:11.560 --> 00:39:11.960 Nope. 00:39:11.960 --> 00:39:12.680 Okay. 00:39:12.680 --> 00:39:14.200 I mean, I'm very happy to be here. 00:39:14.200 --> 00:39:15.720 Let's go to a joke. 00:39:15.720 --> 00:39:18.680 Yeah. It's good to have you here. All right. Let's go to a joke. 00:39:18.680 --> 00:39:23.480 So this one's a visual. If, if you're, if you're listening, you're going to have to go to the, 00:39:23.480 --> 00:39:27.320 scroll down to your podcast show notes at the bottom. Just click on the joke 00:39:27.320 --> 00:39:32.280 link. One of the things you guys, I like about Python is there's a lot of stability 00:39:32.280 --> 00:39:36.280 in the code that we write. You know, if I wrote something on Flask five years ago, 00:39:36.280 --> 00:39:40.120 chances are it'll still run, right? If I write my Python code now, it's probably still going to run. 00:39:40.120 --> 00:39:43.240 Yeah. There's new things. There's new shiny visualization frameworks and stuff, 00:39:43.240 --> 00:39:46.680 but generally it's pretty stable. You know, what is the opposite of that? 00:39:46.680 --> 00:39:52.840 JavaScript. So, so here's a little animation saying, and it says JavaScript developer bouncing 00:39:52.840 --> 00:39:57.720 from framework to framework. And it's this incredible, like almost people are awesome type 00:39:57.720 --> 00:40:03.720 of thing where somebody set up, you know, 50 workout balls on a running track, the whole 00:40:03.720 --> 00:40:09.640 straight of a quarter mile running track. And somebody jumps on it and just like glides 00:40:09.640 --> 00:40:11.160 from one to the next. What do you all think? 00:40:11.160 --> 00:40:14.600 The fact that he's able to do this is surprising. 00:40:14.600 --> 00:40:21.240 It's really impressive that he pulls it off. And it's on one of these like sandy, gritty running 00:40:21.240 --> 00:40:25.400 tracks. It's going to hurt like crazy if he misses it. So maybe there's the motivation, you know? 00:40:25.400 --> 00:40:26.600 Yeah. 00:40:26.600 --> 00:40:32.440 So I remember the Jambrain report you said before I was thinking, I didn't say anything, 00:40:32.440 --> 00:40:36.840 but I didn't want to mean, but you were saying, how likely are you to change languages? And it was 00:40:36.840 --> 00:40:41.400 like, well, JavaScript, they're going to change a lot. Then I thought, oh, their language is not frameworks. 00:40:41.400 --> 00:40:45.800 Yeah, exactly. How likely are you to change your framework? Well, that's like, 00:40:45.800 --> 00:40:47.800 like nearly a hundred percent. 00:40:47.800 --> 00:40:52.040 Yeah, that's true. I mean, people stick around like, 00:40:52.040 --> 00:40:55.480 uh, you got Django developers have been doing it for years. 00:40:55.480 --> 00:40:59.160 Yeah. 10 years. And they're more excited today than ever about it. Right. They're not like, 00:40:59.160 --> 00:41:04.360 we're ditching this. Yeah. All right. Well, that's, does that count? Does that count as a joke? 00:41:04.360 --> 00:41:05.480 Yeah. Oh, I laughed. 00:41:05.480 --> 00:41:09.400 All right. Perfect. Well, that's what I brought for you all. 00:41:09.400 --> 00:41:15.160 Well, thanks to everyone for showing up and, had a fun day today. Hope everybody else did. 00:41:15.160 --> 00:41:16.200 Thanks a lot for me here. 00:41:16.200 --> 00:41:17.800 Thanks, Brian. And thanks for being with us. 00:41:17.800 --> 00:41:19.160 Bye. Bye. Bye. 00:41:19.160 --> 00:41:23.960 Bye. Thanks for listening to Python Bytes. Follow the show on Twitter via @pythonbytes. 00:41:23.960 --> 00:41:29.640 That's Python Bytes as in B-Y-T-E-S. Get the full show notes over at pythonbytes.fm. 00:41:29.640 --> 00:41:34.520 If you have a news item we should cover, just visit pythonbytes.fm and click submit in the nav 00:41:34.520 --> 00:41:38.120 bar. We're always on the lookout for sharing something cool. If you want to join us for the 00:41:38.120 --> 00:41:43.560 live recording, just visit the website and click live stream to get notified of when our next episode 00:41:43.560 --> 00:41:49.960 goes live. That's usually happening at noon Pacific on Wednesdays over at YouTube. On behalf of myself and 00:41:49.960 --> 00:41:54.600 Brian Okken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your 00:41:54.600 --> 00:41:55.640 friends and colleagues.