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 #245:
Fire up your Python time machine (and test some code)

Recorded on Wednesday, Aug 4, 2021.

00:00 Hey there. Thanks for listening. Before we jump into this episode, I just want to remind you that this episode is brought to you by us over at talk Python training and Brian through his pi test book. So if you want to get hands on and learn something with Python, be sure to consider our courses over at talk Python training, visit them via Python bisetta FM slash courses. And if you're looking to do testing and get better with PI tests, check out Brian's book at Python bytes.fm slash pi test. Enjoy the episode.

00:28 Hello, and welcome to Python bytes, where we deliver Python news and headlines directly to your ear buds is Episode 245. So it's not the first time recorded August 4 2021. I'm Brian knockin

00:41 Michael Kennedy

00:42 and Pompey. So one day, thanks so much for coming on the show. Can you introduce yourself a little bit before we get into it?

00:50 Thank you very much for having me. So my name is swampy. I'm from this pain in the day, my PhD in particle physics has been working at CERN for four years. Then two years after my PhD finished, I decided to step away from academia and start working in industry. And right now I'm working at financial four, which is a company that develops products for sale force. So I'm not developing product timing the analytics team. So my job is to analyze internal data as well as usage product usage from a customer to allow the board to take data driven decisions and how the company should go forward.

01:25 Yeah, super interesting. Give us your thoughts real quick, on what hand working for a place like CERN, and then the other work in a place that like provides like, enhancements to Salesforce like those sounds? Are they really that different? Are they similar? What's the story

01:40 part? I mean, of course, they are different. But there is a big part, which is very much the same, at least in the in the team that I'm working on. Because at CERN, basically what you do is you didn't know the answer to anything. And you need to first know what you need to ask yourself. And this is very similar to what happens today, my current job because first and marketing come and say, we have this, whatever campaign and we want to know if we're targeting right, and I need to know, what do I need to do to answer that question, but neither marketing knows. So it's like, let's figure things out. But yeah, I mean, it's a pretty drastic chain. But I don't know, I got feeling that I needed to switch. I like coding a lot. And I felt at some point that I was enjoying more the coding part of being a physicist than the physics part. So I said, I mean, I mean,

02:32 he basically described why I'm not in math anymore. Yeah, I was working on projects. And I was having so much fun and writing code on the Silicon Graphics, like huge computers and stuff. And then there'll be parts Why? Because this parts not so fun, that this parts amazing. And I realized the programming parts were amazing. And then when it had to get down to solving the math, it's I'm like, darn, away, go work on the math again.

02:55 I mean, I remember the last year and a half, I was working on a project that was literally designing a system that work within get lab ci to automate paper review publishing. So you don't need to have a lot of people reading the paper and say, Oh, this rule is not much to do, you need to fix this image. So when you build an entire pipeline in Python to check all of this works based on pull requests, and groups, and so on in get lab ci. And I thought, I've been a year and a half not doing almost any physics or my physics work. It was related to review paper, because it was the chair of an editorial board. So had an analysis was pretty cool. But I wasn't I wasn't doing it. I received version review the made common fix this, fix that then go back to the mega pipeline. So it was Yeah,

03:43 okay, exactly. sounds really cool.

03:46 Yeah, good. You kick us off today.

03:48 Well, you want to hear about the state of the developer world. How's that sound? Like state? Yeah, yeah. So here's an interesting survey results, I guess, put together by JetBrains, the state of the developer ecosystem 2021. And I thought this would be fun to talk about, because we do cover the SF State of Python survey and things like that. But I thought it'd be fun to just have a quick look at the broader landscape, what people are doing and where Python fits into that. And you know, JetBrains has done a really good job with a PSF survey. So I thought, you know, this, this will be similar. So let's check that out. So let me give you some stats and some rundown on this. So basically, the idea is that presents the results of the fifth annual developer ecosystem survey conducted by JetBrains and went out to 31,000 are had input from 31 33,000 people. Alright, so there's a couple of interesting things they're doing in the presentation here. But as say, in that world, JavaScript is still the most popular language, not if you ask Stack Overflow, but of those 32,000 people or whatever. Python is more popular than Java overall. However, Java is used more as the main language so there's more people using Python for extra things, or for other things, and so on, which I think that jives pretty well with my understanding of Python is that it's it's really amazing way to like, bring in a little interactivity, bring in a little bit of analysis, a little Jupyter Notebook or something, even if it's not your, your main focus, right? You might be an economist, you're not even a programmer, and but you're still a Python person, in a sense, whereas you probably wouldn't be a Java person as an economist most of the time.

05:27 I use Python for testing.

05:28 Yeah, for sure. So let's see the top five languages that developers are planning to adopt our go kotlin, TypeScript, Python and rust. The fastest growing languages are Python, TypeScript, kotlin, SQL and go. So for example, JavaScript was the most popular language, Java was the most popular main language, but it's there neither the fastest growing languages. So that's pretty much pretty interesting of this group. 71% people work on a some sort of web back end API's, flask apps or, you know, go apps or whatever. So they have a lot of interesting stuff here in terms of analysis. So they have these blocks that show how popular languages it's been used, or how likely people are to adopt it and pick it up. So there's a bunch of grids if you go to the report, you can check them out. And basically, the Orange is the current state of the world in the there's a darker, almost black, that is like the derivative like how quickly is that world changing? Or the upswing, right? So for example, JavaScript has more orange squares, but it doesn't have as quick of a growth or a plan to growth, I guess. So Python has one of the larger ones of those, so does TypeScript as well. And those are interesting to look into, you can compare those against different things. You can also see the popularity of the language over time pythons been going up and up and up, although this year is kind of plateaued in this report. So that's, you know, maybe something worth noting, there's obvious things going down like Objective C, you'd be insane to work on Objective C right now. And Swiss Swift is like replaced it, although that's going down as well. Let's see, there's a few more things. I have these really interesting graphs that are both like grids, but also heat map. So you can it'll let you answer questions like, Okay, if I am currently a swift developer, what is the likelihood that I'm going to adopt python 6%. But if I'm a kotlin, developer, that's 8% likelihood that I'm going to adopt No, no, go the wrong way. If I'm a kotlin, developer, 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 language to another. I haven't seen any analysis like they have, you

07:39 know, it's pretty interesting. Looking at correlations. So

07:42 the what's the first rule? I'm curious? I'm not planning on changing, so they're most likely to change? Yeah, they're just stuck. Let's see. Also interesting operating systems people use for development 61%, Windows 47%, Linux 44%, Mac OS, which that's pretty high for Mac OS, given its general popularity amongst like, the computing world, I think.

08:06 I think Linux is pretty high, too. Yeah, this doesn't surprise me. But

08:11 yeah, exactly. And then 1%. Other who knows what that is also questions about people using the windows subsystem for Linux, and stuff like that. There's also if you're interested, a similar heat map for like what type of software do to develop? So if you're trying to understand where, like, if I develop this kind of software, what is the distribution for programming languages there, right? Like, it's interesting to say Python is popular or JavaScript is popular. But if I'm in embedded system developer, is JavaScript still popular? I don't know. Probably not. Maybe, but maybe not. Right? Maybe C is like really popular. So there's a really cool thing called what types of software do you develop? There's like a grid plus heat map plus intersection of language and type. So if I develop security software, there's a 9% chance that I would be doing Python versus a 6% chance of Java. On the other hand, if I do blockchain, how does that break down? and so on? Let's see. Where's Python? Kind of notable on utility little scripts? It's quite popular there. Yeah. database back ends, pretty popular in that area. See, another one that maybe is stand out would be programming tools. Actually, that's pretty interesting. And so on. Yeah. What do you guys think of this?

09:24 I think it's weird that there's 39% of the c++ developers are developing websites. The heck yeah. Yeah. What are

09:31 they doing backwards? Maybe? Yeah, maybe

09:32 the back end. Should be bought in the middle. I don't know. But it's weird. Yeah. Yeah. That is quite interesting. And then again, the standard business intelligence it makes us

09:43 yeah, the business intelligence one, that one Python is definitely crushing it there, right. It's like 30% versus 1015 20%. For the others. Yeah, I guess one more there's, there's all these different things y'all can dive into. I guess one more area that might be worth interesting is they broke down like the title coding and software activities you do based on gender. For example, if you're male, like how are like 30 to do straight programming versus testing versus user experience type stuff, or versus female. And let's see this, there were some takeaways is women are more likely than men to be involved in data analysis, machine learning, UI design and research, but less likely to be in directly doing infrastructure development or DevOps. But I kind of had that sense as well.

10:28 But just my personal experience is completely the opposite. Most of the DevOps people I work with her women. I think it kind of make sense. I mean, in the industry for what I'm seeing. But my it's a completely opposite.

10:45 Interesting. Yeah. So I'll leave this out here for people to go dive into and explore more. I feel like I've gone probably over enough details there to give you all a sense, but there are some interesting things to be learned. I think they're pretty cool. And, and Matt out there in the live stream, he points out that that might be more than 100%. I'm not sure which part you're talking about. I do believe a lot of these had multiple, you could check multiple things like which language Am I willing to adopt? Well, I might be adopting both SQL and Python in the next year, something like that.

11:13 Yeah, I think a lot of people are perpetually going to start learning rust or go, but never started. That's true. In much, all right, um, Cornell so this was suggested by Yale mints. And, and Michael, you know, where Cornell comes from? Apparently,

11:35 I'm thinking Soundgarden. Some good 90s grunge. I mean,

11:40 okay, maybe. So Cornell is a recording and replay mock server. And the, we're going to the link to the tool, but also to there's a, there's an introduction blog post about it. And it's supposedly makes them makes it really simple to record and replay features to perform end to end testing in an isolated test environment. So the kind of the gist around it, there's a cool tool called VCR pie, which saves cassette, like cassette files for us, you send a request, and you get replies back. And then you can save those requests, reply sessions and stuff. And this is bundling VCR pie with flask to to make a little server. And it's actually really kind of a cool idea. The idea, one of the things around it is that you can do, you're not just mocking one service, you can just mock in any external service that you're dealing with. It'll, you know, replays on that. And one of the benefits over rolling your own mocks or rolling your own test server or test service is that you can that you don't really have to think about designing the whole thing. It just kind of replays everything. Yeah, right.

12:52 It's cool. Pretty,

12:53 it looks pretty fun. I haven't played with it yet. But definitely want to pay to begin to play with it, click on

12:57 documentation, I think it is on that page right there on the bottom. Okay, documentation, and then click on the documentation of that page. There you go. And so you have this kind of like, series of animated gifs, of seeing in action. And I think that that's kind of cool, right? Like, you can, you know, go along, say, Oh, yeah, I hear you recording a bunch of API calls. And then the workflow of like, how you create it, I just want to give a shout out to the animated gifts for like, is this interesting to me, let me just watch the gifts instead of actually take the time to try to adopt it. It's simple, but it seems really effective on pay. What

13:31 do you think idea? No, it's a really good idea. I mean, there are many projects that is that you think this might be cool to work with. And then you start reading walls of texts and halfway through, I don't know if it's interesting, but I mean, it's been helpful. To give is I gotcha.

13:48 Yeah, for sure. For sure. Yeah. Also, I just want to quick shout out to the livestream. German points out from his experience to date analysis have more men than women, but it could be biased due to the tech sector having more men in general, I do think that that's true. I think what they said is, if you're a woman, what are you more likely to be doing? If you're a man, what are you more likely to be doing? And it's like, of that population? What areas do you work in? Not that user experience has more men or women? I don't think it addresses that question. I think my thoughts here there's a lot of women who end up in programming, not down the traditional computer science path, you know, they go into biology and then that I go I actually learned a little Python and now I really like it I work here and it's amazing, but you know, they kind of get pulled in tangentially where there's a lot of guys that like sign up for computer science and they just go through that path and some of the areas were called out are more likely to take the straight computer science path people rather than the I got interested in I came in through like psychology or something else where there wouldn't be more women so I don't know I would love to have more women in there but I think that this is my in bra, broadly speaking, but I think this is my my thoughts about why maybe those different areas seem to attract people Not so directly down the computer science path. Alright, uh, one day you're up. You're talking about the next day you got here? Sure.

15:08 So I wanted to talk about factory boy, I think it's a very well known library to basically mock objects when you're running tests. And both of these. And the next tool I'm going to talk about came because we were working on a system that replicates an entire Salesforce org. So we have infrastructure with build that takes everything you have every object you have in Salesforce, and copy it to a database. This is a way we have to give daily snapshot of the data that we can do a time series analysis and all the models that we have on instead of being ference, let's say when you modify slots, so for this, we obviously need to communicate a lot with API in Salesforce. And when you get API responses, then you need to not only treat the Jason plainly say there's the pain as an object, but you will like also to have some kind of representation. And for this, I think it's not news for anyone that by downtick right now is taking the floor. And the biggest issue came when we need to start writing tests for it. Because we get the JSON file which stick it in the Python tick object, it validates everything, everything's beautiful, and works fine. But then we have a bunch of objects, a bunch of fields on the object that cannot be null, for instance, or they are not optional. So they need to come in there behind we need to validate for those we can see the API does not return any of those should break and tell us look, this is wrong itself is respected. So when we wanted to write tests for those, and we wanted to create objects for those, in each test, we noticed that out of hundreds of fields, we might need to feel, I don't know, probably 8090 of them because they were mandatory. And he started to be very tedious. And I remember I open an issue in the pedantic I say, Hey, have you thought about probably allowing creating an object with random fields that validate properly, like these fields in interest between 10 and 20? So I just want to feel it, I want to fill in those because I don't care for these tests. Is there a way that I can say, okay, just fill wherever it validates. And they say, no, it's out of the scope of what antic which also makes sense. I just wanted to ask in case, they said the probably in factory boy, they might be interested in this or went factory boy. And I read the documentation. I was pretty cool, because it allows you to create unifying an inside class. It's made a class not a meta class in the terms of Python meta classes, but it's a class called meta within the factory that you want to wear. Because everything you say, yeah, this is the middle class, the middle class. No, it's a classmate. So you inherit from factory and you define a class called meta, meta, would you define what is your model? So this is the object I want to mock with this factory. And then you can define many fields with their default values. The cool thing about this is that it implements also Faker said you can say if I have a username, I don't want to fill it. Just give me a username a faker will give you

18:09 Yeah, Faker is really cool for generating, like,

18:12 yeah, yeah. And the amount of plugins you find for Faker is outstanding. You can fake almost anything you think of. The cool thing about this is that it's not only your plugin, the class that you have any will feel it. But you also can work with our M's like you can use SQL alchemy Rimando and Django Roman over him, and he will generate an object for for this ORM based on whatever you set, these are the default values. So I thought it would be great if I could do this also for pyknotic. So I could just say, hey, these are the mandatory field that puts something fake, you can think about it, and then we're ready to go. But written documentation, it didn't appear anywhere. And I thought, maybe I can reduce it for this case. So I went ahead and open it up didn't say, Are you thinking about putting this house to work with pedantic I mean, it's now is booming, and everyone is using it. And if you are reading Jason from an API, it's very likely that you have hundreds of fields you don't care about, you might want to fill it with whatever. And remember, the author said, I didn't know this. I didn't know biotics called you mentioned it. But internally, we'll factor what he's doing is creating a dictionary with the parameters you want to fill in and just some putting it in the constructor of the class. Have you tried it? And I will, No, I have not done and when I tried it worked. So it was perfectly I mean, maybe there are some quirks Pilati that cannot covers. But if you're using Python to to store your data from API calls, and so on from Jason and validates and so on. factory was pretty cool. I mean, the amount of things you can do with this you create, you can create many factory for the same class, you can create fixtures like I don't know if you want to mock a news, you can have an admin or buyer or whatever. And then you can just define different factories and it will give you the usage if defined. And it's also very cool because the Faker is random Nice with it. So if there is there are parts of your object that your code does not care about. It's also a good test to have those part being random. Because if it really doesn't care, you don't care what those fields are. And then at some point, your tests fail. It happens once. It means that you actually fix something.

20:20 Yeah, absolutely. I did see that if you need repeatable tests, but you want Faker to generate random stuff, there's a way to see Faker. Exactly generate the random values, but do it in a consistent way. And one way you might want that is if you have an edge case or some value that breaks the test. And then you want to put a breakpoint and pressed a bug and go through it again. But like, you know, how are you going to get it to hit that case? Again, in a predictable way, right? So if you if you trigger if you tell it to say always do the same thing, but randomly Yeah, you know, make it so you can go back and look at it a second time and figure out what's up. Yeah,

20:53 you can fix that. Sometimes also good to have them fixed. Even if you don't care. I mean, you need to have a daytime. And for some reason you need to have the daytime being whatever, whatever you can validate for it. So you can just or either set it on ensure that it's fixed. Yeah, there are many use cases that you can exploit a thing and suffer vertical.

21:12 Usually, I almost always seed Faker, because I just don't I'm not using it because I want the randomness. Oh, I'm using it because I don't want to come up with the data.

21:24 Yeah, exactly. So make it so that it does the same thing every time just gives you the random day that you want. That's right. Agreed. Very, very cool. All right. The next one up actually is pretty sort of related to that is called pi instrument. Have either of you heard a PI instrument? Not until no? notes? And it sounds pretty cool. Yeah, right. Yeah. Yeah, so it's a call stack profiler for Python, which is pretty cool, right? It's just going to tell you where your code is slow. But it's, you know, it's, it looks really clean. And when you look at the output, it can actually give you the results in the terminal. So if you want to see, you know, like, you run this thing, instead of saying Python, my exam, my python.pi file, you would just say pi instrument, that same file, and it'll run it, but then at the end, it's going to generate a whole bunch of things about how long it took, and whatnot. And then you actually get, like colored output in the terminal showing which lines of code are spending how much time in different places? And it seems like it's a real good way to just sort of quickly dive in on where you're spending your time.

22:29 And I'm definitely gonna try this school. Yeah,

22:31 yeah. One thing I like about is the simplicity of like pip install pi instrument, pi instrument, your file, that'll give you the answer, right? Like,

22:38 that's me sold it. I mean, every time you want to do some profiling felicidades, you spend some time tweaking things. So you get with the fact that this is just running with PI instrument, whatever script you want. I mean, I'm gonna try for sure.

22:52 Yeah, for sure. And that, when you do profiling, you end up in this sort of quantum mechanics world of if you observe a thing, you've changed it, yeah. So there might be code that is like this half is 5050. And this half is 5050 of the time, but one is calling an external system once and the other is a tight loop. And if you profile that with instrumentation, it's going to wreck it, it's going to make the loop look way slower, because now you've added a bunch of overhead each step where there's very little overhead to this external service sort of thing. And this one uses sampling. And the sampling doesn't really have that effect. It just every so often, every millisecond or something that says, What are you doing now? What are you doing now? Who called you? What are you doing now? Right. And so it basically, it's more of a polling sort of thing, rather than slowing down line by line code. So that's probably worth noting as well. That's pretty cool. Yeah, you can specifically jump in and just do a section of your code that you care about also, exactly, if you want to say so one of the things that I hate about profiling is it'll say 87% of your time was in the startup code. And the inputs, you're like, yeah, okay, that that's not relevant to me. What I want to know is that I'm actually trying to test here, what how long did I spend there? And please don't pollute that with other junk about like starting up Python or loading modules or whatever, right. And so you can, there's an API and you can say, from pioneer summit, import fro profiler, and then you can do a context block in there and run it. And just that code will tell you like how long it takes. Who does anything else jump out out there out? You Brian, and like what this example I got on the screen here,

24:34 that will be hard. It's an async example for one.

24:38 Yeah, as an async and await and so they recently released pi instrument four, which will actually give you the informant information about the async code as well, right. So it'll, let's see what it says it has async support panzram it now detects when an async task hits an await and tracks the time spent outside of the async context. Under the await, whereas before it would basically just profile the async IO event loop or something silly like that, right? So if you're trying to profile async and await and async i O, this might be your best option because it specifically supports that.

25:14 That's what happened before. If you use a different profile,

25:19 we would say, yeah, it says you only see the time spent in the run loop. And it'll basically tell you like, here you see, like, run once and the Select and then the queue control built in just, it's just like, there's this async IO event loop just cranking around waiting for the signal for the IO to be done. And it just says, well, you're waiting on this here. You're in the loop. You know what I mean? Yeah, yeah. Yeah. So um, yeah. Now you get a little bit better. Like it says, okay, you're waiting on this line of your code for a second, or whatever it is. Yeah. There's also I'll shout a few more things here. Is it in the stock? Yeah. So they also, there's also a bunch of simplification they did previously about network calls and stuff. And there's, there's an interactive Vue JS app that you can get with flame graphs. So instead of looking at the terminal, you can look at it in your web browser and explore into those. Yeah, there's a lot of neat little things here pulled out of the show notes, but it seems like a really nice way to do some profiling. And you just I instrument, your code, and you have a look.

26:18 Yeah, I personally kind of like the default output. I'm, I know that a lot of people like flame graphs, like they didn't really do much for me, it look like I don't see the data. But it's cool. It has both.

26:28 Yeah. A couple things from the live chat. Maddie says pi instrument is a statistical or sampling profiler, which is better prepared for profiling. I think it depends. I mean, I do the instrument, patient ones do give you more precise information. But it's also skewed with the overhead of that information. So it's It depends, but this is the least influential one for sure. And then of aro does, how would you use PI instrument with an entry point? That's a good question, not knowing the answer off the top of my head, maybe make another Python file that just import your library and calls the entry point and then profile that, but there's a real quick cheat, you know, just make it call it and then pi instrument that file, but there may be some way to say like dash m, and give it a module thing to do. So. Yeah, that's it. Right. That's it for pi instrument. Cool.

27:21 Um, well, I just wanted to remind everybody that Python 310 release candidate one came out yesterday. So Pablo announced it, just just on the third, I think, I think it was yesterday, the fourth today. Anyway, so 310 is out. If you've got, if you've got the well, 310 RC one is out the timelines that we're looking at, then we're getting excited, it's coming up. So the September 6 is the plan for RC two. And then October 4, we're planning is the plan for the official release. So we're just really right around the corner. It's nice. And this is definitely a time I know we've brought this up before. But if you maintain any third party Python packages, you probably should have already been taste testing and against 310. But if you haven't, definitely do it now to make sure that people that use your stuff, don't it doesn't break when they need to. And then we in the show notes, we've put just a list of reminder of some of the new changes in 310. We've definitely talked about some of these before structural pattern structure pattern matching is the switch statement kind of thing. And then, yeah, lots of these other things we've covered. I'm kind of actually I like the union type union types. So you can like because there's a lot of stuff that I write that the default is none. But the normal type is something else. So you can really easily say the type is none or int or something like that. And that's a lot cleaner than us then then before. I've already started using 310 to test everything that I support. Everybody else has as well.

28:58 Yeah, cool. I like the optional length, checking in zip, right zip taking two collections, and you want to pair up the items. Like if those things don't match, that should be a problem. Also, like the or for the types information. And I think dick and some of those types are now don't require a from typing imports.

29:15 Oh, right. Yeah. Um, yeah,

29:17 I don't think I don't see it called out here. But one of the problem was, maybe that's explicit type aliases, I'm not totally sure. But if you want to say this type is a dictionary of strings and integers, you would have to say, from typing import capital D, dict. And then dict, square bracket, string, comma, and whereas now you can just use the lowercase di CT, and you don't have to have that import. And you can do that sort of thing, too. So I'm looking forward to that.

29:44 Yeah, a lot of the a lot with this. A lot of the common type hints you won't have to do the import anymore. And that's, that's great, too. I think that's really all I was using the import for it was things like dict and set things like that. Yeah, exactly.

29:59 Didn't that I mean, if I seem to remember that three point 10 was the one that was including this building type without having to import from typing didn't, that update might break some of the libraries that he's typing, like by

30:13 the antic and pacify the thing that that was was to use it in, basically use it as a string and not actually evaluate the type. I think that like, so if you had your own type, your own pedantic type that was a customer, I think you could put customer but it wouldn't be actually evaluated until a type checker hit it or something like that before we're typing. Yeah, exactly. So this, this ability to specify the type on like, lowercase d dict. is related, but it's not the same.

30:43 And I'm pretty sure that that that fear around pedantic is not in 310.

30:48 Yeah, either got postponed or rolled back or modified. Yeah, yeah.

30:53 I just wanted to talk about the one that says what was the number six to six? You have a

31:03 Yeah, the precise line numbers for debugging and other tools. So one of its

31:07 I think it's very underrated. It's gonna be one of those things that when people get used is like, I don't know how you live with.

31:15 Oh, yeah. Yeah. There's another good example shown right off the bat, but it is. It's pretty cool. Yeah,

31:21 yeah. Absolutely. Very cool. And we also have better stacktrace message error messages, right? Yeah. Yeah, those are coming last a lot of good things to look forward to. All right. Well, hey, you got the last item? Great. I think it's time for you to take us out, right?

31:36 Yeah, so let's talk about time machine. I said, we will build in this tool it copies and herself or one of the things that we need to work is to read everything is to timestamp, almost every action we do. This means that in many places all over the code, we have daytime UTC now method call. And when we are testing day, we need to be able to mock it. And if you've tried to patch, daytime, etc. Now, with the use of batch method, you know, it works, you can do it, but you need to do it with a patch. And then you pass the string but the module where this UTC now called AES, and then you're good to go. But when you have this in many files in the same time, you need to patch every one of those because otherwise it wouldn't work. So I tried to use patch object and patch the time and say, Okay, I want to patch the it's in our method, this object and it will have, of course, complaints, you cannot patch a built in built in topic data and that time, so I was looking for how we could patch this and I found prescan, which is a very well known library thing to purchase can things But suddenly, I noticed that once I started, use a free scan, all of my tests took much longer to complete. It's not like deal breaker so it went for probably five minutes to seven or seven and a half. But I was very surprised because our pipeline or deployment pipeline will take a long time. So every time I can reduce it a minute is good for me. And when he started going up two minutes, I was surprised why why is this happening. And then I learned that with free scan is doing is actually scanning all your dependencies and making a batch for every call you make to the methods of data and then trying to see if there was something else I found out time machine. Time Machine is very cool. Not so well known, I think library that allows you to do basically the same that freezin allows you to do so you can just patch any almost any method call in date time or time with a simple decorator in your test. It's also supported by this fixture that you can use. The good thing about this is that it does not scan for inputs of date and daytime. And what it does is actually changed the underlined sea level calls that you make to get the time so every time you say I want to patch any call to be on January 1 of 2019 for instance. It will just call it normally but the car the underlying t calls that will be made will return this time instead of the other one so you don't need to scan everything to patch it. Another thing that that I thought it was pretty cool is this you can let the time tick after you passed in so you say this is for February 1 of 2018. And once you enter the mark either with decorator or with context monitor you can also use like standard patch CO and then time start passing starting on that time that you mocked, mocked it for so you can do perf counters and all this thing normally where if you need to stay in a given day for a test you can do it. So I thought it was very cool itself my two extra minute running because we have many places and many files and the project will be used it See now and it was pretty well.

34:56 So this this had this must have had increased minimal. I mean, it has a little bit of time that has to do its work. But it's it's fast enough that you're not noticing it, then

35:05 I'm noticing and if I mean it runs more or less same. Okay. Well, it's pretty mean. Yeah. I imagine there should be some delay, but it's not as noticeable as what happened with fiscal year is it took some it took some time.

35:16 Yeah, I'm glad you brought this up. This is cool.

35:19 Yeah, we probably pressed Yeah, exactly. I say, Brian, you probably this is kind of in your world, right, like dealing with time as a dependency.

35:27 Definitely. And there's, there's just sometimes it's really, you want to fix because you really want fixed answers, because, like you timestamp stamps and stuff are in your data, you're gonna have to I mean, it's good to compare against known Oracle's. But there's also times where you, and this is where prescan isn't so bad is, but maybe this would be really useful to is, is if you want to test certain things, there's weird, quirky dates, you want to make sure that your software deals with certain times bind, does it work fine when it's running over? Like, overnight on December 31 to January 1, things like that, when the year changes and things like that.

36:07 Yeah, yeah. Yeah. You always want to test your boundary conditions, right? And crossing over time, or weird cases, lag, March 29, stuff like that. Like, let me just try that and see if this is going to survive.

36:18 Yeah, yeah. But then, I mean, to be fair, I think most of the time, things that things like this are used are, like was brought up is that the time shows up in the data? So in order to compare the, you know, or the log or something in order to compare those apples to apples, it's nice to have the same dates there. Again, I can't tell you how many times I've had had to compare two log files and strip out the times. Because those are the like, those are the every lines different because the timestamps different. So

36:48 yeah, pretty cool. Nice. Find a tougher time machine. Yeah, yeah. Super.

36:53 Um, well, that's our that's our six items. Everybody. Have you got anything extra Michael?

36:59 Well, I have the old thing that is new again. Let's see, I have some bandits. So the the drama around supply chain vulnerabilities and open source repositories goes on. So this this one, I think, actually the other article, talking about a kosher to us from Joe Riley. Thank you, Joe, for sending that in. But basically, there's some more malicious things in by pi again, people just remind everyone to be careful and stuff. Yeah, this one note what this one was, if it was typo squatting this time around, or it was just something else that got put up there be out there's one is one headline is credit cards, stealing malware found in official Python repository. And the other one is, say wine bars technical article says software downloaded 30,000 times your pi pi ransacks. Developer machines, developers machines, expect to see more of these Frankenstein type things because it's a basically a systemic threat. Like how, how does it get dealt with? Right? I'm not sure if they list out. Yeah, so they use, they did interesting stuff as well. Like they did simple obfuscation of the code that was being run. So you couldn't look at it. And you know, say, look for a credit card, or look for a bitcoin wallet, and then go to your evil deeds and Python source code. So they would do things like base 64, encode the Python code, and then just in memory, decode it, then run it. So they were trying to get around things like that. So anyway, people can check that out. And it's not ideal, but just a reminder to be where? Yeah, yuck, yuck, is why we can't have nice things come on people, right, we can have basically,

38:37 well, I got a couple things, I want to bring up just things I've been up to just released Episode 162, of testing code. And I kind of run through all the different flavors of test driven development that I know of. So there are quite a few versions. So check it out, if you're interested in test driven development, and then I'm just working on wrapping up the toxin continuous integration chapter for the second edition of the PI test. It'll be coming out hopefully, within a week. Very cool to see making progress there. Do you have anything extra? Nope. No. I mean, I'm very happy to be here. Let's go to a joke.

39:15 Yeah, it's good to have you here. All right, let's go to a joke. So this one's visual. If if you're, if you're listening, you're gonna have to go to the scroll down to your podcast show notes at the bottom, just click on the joke link. One of the things you guys I like about Python is there's a lot of stability in the code that we write, you know, if I wrote something on flask five years ago, chances are it'll still run, right? If I write my Python code now, it's probably still going to run. Yeah, there's new things. There's new shiny visualization frameworks. And so but generally, it's pretty stable. You know, what is the opposite of that JavaScript? So here's a little animation, say and it says JavaScript developer bouncing from framework to framework and it's this incredible, like almost people are awesome type of thing where somebody said, you know, 50 workout balls on a running track the whole straight of a quarter mile running track and somebody jumps on it and just like glides from one to the next. What do y'all think he's able to do this is it's really impressive that he pulls it off. And it's on one of these like Sandy, gritty running tracks. It's gonna hurt like crazy if we miss it. So maybe there's the motivation, you know.

40:27 Lisa, remembered the gen brain report you said before, I was thinking he didn't say anything, but I didn't want to mean, but you're saying how likely are you to change languages? And it was like, What Java's people they're going to change a lot of their language is not framework.

40:42 Exactly. how likely are you to change your framework? Well, that's nearly 100%.

40:49 Yeah, that's true. If people stick around like, you get Django developers have been doing it for years

40:55 and 10 years, and they're more excited today than ever about it. Right? They're not like this. Yeah. All right. Well, that's it. Does that count? Does that count as a joke? Yeah, I laughed. All right, perfect.

41:09 Well, thanks, everyone for showing up and had a fun day today. Thanks for

41:15 having me here. Thanks, Brian. And thanks for being with us one day, but I thanks for listening to Python bytes. Follow the show on Twitter via at Python bytes. That's Python bytes as in BYT. s get the full show notes over at Python bytes sarafem. If you have a news item we should cover just visit by them by sarafem and click Submit in the nav bar. We're always on the lookout for sharing something cool. If you want to join us for the live recording. Just visit the website and click live stream to get notified of when our next episode goes live. That's usually happening at noon Pacific on Wednesdays over at YouTube. On behalf of myself and Bryan Aachen, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.

Back to show page