#175 Python string theory with superstring.py - podcast episode cover

#175 Python string theory with superstring.py

Apr 01, 202033 minEp. 175
--:--
--:--
Listen in podcast apps:

Episode description

Topics covered in this episode:
See the full show notes for this episode on the website at pythonbytes.fm/175

Transcript

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 175, recorded March 26, 2020. I'm Michael Kennedy. And I'm Brian Okken. Brian, we have a special guest. Welcome, Matt Harrison. How are you doing, man? Glad to have you here. Good. Good. Thanks for coming. Come on. Yeah. It's always nice to have you on the show. Before we get into it, let me just tell you this episode is sponsored by Datadog. Check them out at pythonbytes.fm.

Datadog. I'll tell you more stuff about them later. First, I want to just throw this out to both of you guys. The world is, I don't know, is it turned upside down or is it locked down or what has gone on with the world? It's crazy. We're kind of software people, and I know we're all kind of in different boats. I am definitely grateful that I'm a software person. I have a lot of friends that are not, that are in the retail industry or the selling stuff to people sort of industry or self-employed.

And those people, they're really hurting. I've got a lot of people I know that if they're self-employed, you don't qualify for unemployment insurance and stuff. So there's a lot of people hurting. How are you guys? It's crazy. Yeah. Matt, how about you? I just found out this morning that my largest client just dropped all my trainings for the rest of the year. That's not your favorite phone call or email to receive, is it?

Not the best news, but the thought that I have on that is like past couple of years have been very good, right? And people have said like the bubble will burst. And I don't know that we thought that a virus would do this, but I mean, it looks like winter came for better, for worse. And so people are going to have to adapt. And now if you can weather the storm, it's going to be tough though.

I mean, I was even talking with some friends who are in the medical industry and they're like, we're worried about our jobs, right? And these are like doctors and people who work at the hospital. So it's interesting to see what's going on. And I've worked from home for the good portion of the last 15 years. And right now it's scary to see that there's a lot of upheaval and we'll see what happens. How are things going for you, Michael? Well, you know what? It's really interesting.

If you'd asked me this question like six years ago when I was doing mostly in-person training, it would have been like somebody just cut the light switch off and said, you know, we're all leaving. Yeah. Lock the door on your way out, right? It would have been purely traumatic. Luckily now, like online courses are great still. Podcasting is great. Like what's ironic is my work life is literally unchanged, but the rest of my life is scrambled, right?

Like my daughter is home from school because they closed school. Like Oregon's now on full lockdown. Like it's hard to go out to dinner. So everything is changed in some ways, but ironically, not my work life really. I'm sure it'll have some effect eventually, but nothing immediate. I guess one more thing before we move off. I'm just curious. Like what are your plans around training? Like are you going to be teaching over Zoom or is it just focus on other stuff until it comes back?

Yeah, I think both of that. I do have some clients who are moving to virtual training and I already do a bunch of virtual training anyway. So, I mean, it's sad that some of them aren't able to or can't due to circumstances or whatnot, but try and see if other people want virtual training and just work on other products that people are interested in as well. Yeah, absolutely. Well, hang tough.

You guys and everyone out there, it's going to be a wild ride and hopefully the software side of the world is a little bit less bumpy, but it's still, it's crazy. All right, well, let's talk a little bit about the future, Brian. Like we can't predict when the COVID stuff is going to be better, but you could probably predict some stuff about the Python in the future. I'm just still getting excited, used to being able to have Python 3.8 everywhere.

And, but we've got Python 3.9 right around the corner and in October is the scheduled release. I don't know if that'll change due to the virus or not, but that's where it is. And one of the cool things that I noticed from a blog article is that there's union operators coming for dictionaries in Python 3.9. And this is a PEP 584. And there's a article called a dictionary merging and updating in Python 3.9 by not, I think young qui. And there's a couple new operators.

One of them, it's just the bar or the bar equals or the pipe operator, whatever. It looks normal for if you're used to, I guess that's the math or operator. It's like a bitwise or, yeah. I'm kind of excited about it. So you can combine two dictionaries by just doing like a dictionary one or dictionary two or something like that. And then the equivalent assignment operator as well, which is really an update operator and a merge.

The article spent a little bit of time talking about the other older methods that you can use to combine dictionaries now. And I know people have covered those in a lot of places. The one thing, the article actually spent a lot of time on it.

And I just think it's something to watch out for and be aware of is when you're combining dictionaries, usually the, if there's overlapping values, like if there's a value with the same key in both dictionaries, you'll get the second one will take precedence. It's just something to be aware of. Yeah. Yeah. And that's the way it works in the, like the current operators as well, right? The star star sort of combine stuff and whatnot.

Yeah. As long as you're aware of it, it's good to know, but this is clean. It's actually something that now that I see it, I'm surprised that we don't already have a, an operator already in to combine dictionaries because it's something I kind of do a lot of. So. Yeah. And if you look at the syntax there for the pipe, I mean, the pipe is already in the set operator.

And prior to sets existing, when people used to use dictionaries to emulate sets, I mean, they wouldn't do the or operator, but, but it's, it's interesting that it's sort of coming around circle now that we originally had dictionaries. People started using dictionaries as a simple replacement for sets. And we got sets, which had the pipe operator and now the pipe is coming back to the dictionary. Interesting. So why do you guys think they didn't use plus?

Like you want to combine two things like two lists. You don't use a pipe to put them together. You use a plus for strings. Use a plus. Plus already existed. I think it's because of the union operator already being used for sets. Yeah. You think so? Yeah. All right. Cool. Well, yeah, it's good to see some nice shorthands coming there, but if we can have a pipe equals operator, give me the plus plus. Come on. I just want the plus plus. I want the double pipe. Yeah. Double pipe.

What does that mean? All right, Matt, you got the next one. This one is short and sweet, but it looks pretty cool if you got the use case for it. Yeah. Yeah. So there is this super string library, which is a new library that's a replacement of, well, not a replacement, but it's a new string library for holding sequences of characters. It's built on this rope data structure, and apparently it's pretty optimized.

It uses a 20th the amount of memory and a fifth the speed, so operates five times faster for a lot of operations. I think this could be super useful for people who are manipulating data. So it'd be interesting to look at if the people who are doing NLP could take advantage of this. Definitely the memory constraints, using a 20th the amount of memory would be awesome, even in places like Pandas, NLP as well, natural language processing. The API is pretty basic right now.

It's got concatenation, getting to the length, doing some indexing and slicing and stripping and uppercasing and lowercasing. So that could be a good, with the speed and memory performance they're showing, that could be a good enough limited set of capabilities. Sort of for me, the elephant in the room is the F string. For me, that's the best feature of Python 3. I know. Implement that, and let's use it.

Yeah, the other thing that's missing is negative indexes, but that can't be hard to add, honestly. Maybe it's hard to add quickly, but it can't be hard to add negative indexing. That's a good point. I mean, they don't make any reference to whether they support Unicode. So that's, I guess, another question, right? If they do support the Unicode capabilities, the Python supporting, I mean, Unicode can make indexing a little bit more complicated, but that might be what's going on there.

But this will be interesting to watch, interesting library to watch. What do you think, Brian? I'm just not in a place where the strings are the memory or the bottleneck in any of my applications. Yeah. Yeah, but to give you an example, like a real world example, like I've been playing with some Markdown stuff for like the sort of CMS side of things that I'm writing in Markdown.

And if you've got something that's maybe 10, 20 pages of Markdown, it takes half a second to convert that from Markdown to HTML. I don't know how much of that is like the actual string juggling and how much of that is just converting it to Markdown is slow. But that's a non-trivial amount of processing that's like sort of around the corner. I mean, you would never do it manually. You would use a library, right? But still, you can benefit from that.

On that, you can think of all the people who are using static libraries, right? For web pages who, you know, once you get, they all complain about once you get X number of pages in there, they start getting slow. And the rebuild takes five seconds instead of a half a second or whatever, right? And so something like this could help there as well. Right. Theoretically. So this is not a super popular library, but I'm glad you put it on here because I think it's pretty cool. I guess two thoughts.

One, it'd be interesting to look at what they're doing and if there's any easy low-hanging fruit to bring back to CPython because it would be better if just Python strings were faster. And they're like, why would you make this? It's the same speed. You know what I mean? Then the other, Brian, you may have noticed, there's no tests. Yeah, it looks like it's recent. It's like, I don't know if it's even been around for more than a week. Yeah, I think it's pretty new.

So if somebody's like, oh, this is cool, let me try it out. Like maybe a way you could participate is like write some tests just to verify things, right? But yeah, pretty cool. It's just imaginary. If there's no test, it's like no picture, no proof, man. If it continuously deployed in the woods and there were no tests to hear it, did it actually happen? Something like that? Yeah, yeah, exactly. Sure. That's the saying, I think, the historical version.

I thought your new testing strategy is if it doesn't have tests and you don't commit it. Didn't you say you're using something like that? Yeah, that's good. Yeah, that's a good way for sure. All right. So this next one is going to affect everybody who works with Python. This is a big deal. Hopefully it's not a bumpy deal, but it's a big deal. So the Python Packaging Authority folks, the PSF subgroup, they recently got funding to hire some developers to make pip better. So pip is awesome.

We all pip things. And even if you don't pip things, if you pip them or you poetry them, you really pip them down below, right? So they got a bunch of funding to make that better. And one of the challenges, one of the first challenges that they're tackling is that pip will, it's not, it doesn't take into account all the stuff you're trying to do. It just says, I see a requirements file. Let me just go from top to bottom, just start hitting it, right? Install the first one.

Install the second one. So they're rolling out a new pip resolver at the end of the year. That's pretty cool, huh? Yeah. This is neat. Yeah. So the idea is basically, it's going to go and it's going to look at the dependencies of the various packages and try to install something that is consistent across all of them. Like maybe the first package in your requirements files requires, I don't know, docutils 16. And the second one requires docutils 15.

Or maybe the first one doesn't even specify and 16 is just the latest. If you pip install dash R that you're going to get 16 and then it's going to complain that you have 16 and not 15. You know what I mean? It's like, it just doesn't even factor in the larger system that these two things have to coexist. So that's one of the things they're working on. So to reduce inconsistency, it'll no longer install a combination of packages that's mutually inconsistent and it will be no pushover.

It can be strict. If you ask it to install two packages with incompatible requirements, it will say no. It will not do it. Yeah. And then it just doesn't install anything, I think. Yeah. Yeah. It just says, no, I can't install it. That might cause some problems, right? Yeah, it might. Or make people's processes work differently. Because I mean, right now I know there's a bunch of library top of each other and I can sort of just install them over on top of it.

I have my libraries and some of them sort of work and some of it doesn't refuse to install them. So this might be a speed bump in the road for a lot of people. And maybe in the end it works out better, but might cause some consternation in the short term. Yeah, that was my first thought exactly. It's like, oh, there's going to be a bunch of stuff that just won't install anymore.

Yeah. Maybe a library itself can't install because two of its base libraries dependencies like themselves are inconsistent. Well, how are they working now then? You just get a warning and it just still works. It's not that they're necessarily truly inconsistent. One says, I require library less than equal to this version. Another one says, I require library greater than equal to that version. That doesn't necessarily mean the one that requires the lower one wouldn't work with the newer one.

It's just that's what the requirements state. You know what I mean? Like, for example, Boto3, which is the Python 3 library if we're talking to AWS and its underlying library, BotoCore, at one point we're having different dependency, like inconsistent dependency statements or something weird like that that I was running into. But it didn't matter. It still ran. I'm just like, oh, I better run the unit test. It says these aren't going to work together.

Let's see if they, you know, like maybe there's some corner of that thing that doesn't work, but I don't use that corner. So like, I don't care. Yeah. Or you have like in the machine learning side, you have like this library depends on some old version of TensorFlow, but it doesn't. You're not using TensorFlow. You're using some utility library in it, but it also has support for TensorFlow, but you're not using it.

So if you had a different version of TensorFlow on it, it wouldn't really affect you because you weren't using that portion of it. Right. But it sounds like pip will say, no, I can't install these things. They make statements about two things that they can't coexist. But you're like, I don't really care that they're working. You know what I mean? So I think this is good. I think it makes things more predictable. But you're right, Matt. It's definitely going to cause some challenges.

And maybe it'll get people to update things like the base library statements that they depend upon more carefully. Yeah. One of the things I'd like to see for talking about pip is that I'd really like to see Python come out with dot releases that if there's a new version of pip that all the latest versions of Python have the latest version of Pip. I'm just really tired of installing Python places and immediately having pip out of date.

Yeah. I actually have an alias that when I create a virtual environment, then immediately does a pip dash install --upgrade pip and set up tools. Because why doesn't it just do that for me? Yeah. Anyway. Can I just update the top level one so that all my new virtual environments get the newest one? Yeah. Anyway. This is coming. They blogged about it. I linked to the blog post from the PSF.

They said there's a couple of things you can do to help first and most fundamentally help them understand how you're using Pip. They have some user experience research going on. There's a link to go do part of that. You can check right now if this is going to be a problem for you. Go to your project, your virtual environment, activate it and type pip check. And it will tell you if you are in this inconsistent state. I had one website that was, a couple that weren't.

I hacked around until I fixed them up and everything was good. Make sure you test the new version of Pip. It'll probably be out in May. Help spread the word. All three of us are doing that. Ta-da. Awesome. And if you develop a tool like Poetry or something that lives on top of this, make sure that you test integration with the thing coming out in beta in May. All right. Really quickly before we move on, let me tell you all about Datadog. This episode is brought to them, brought to you by them.

So let me ask you a question. Do you have an app in production that's slower than you'd like? Is its performance all over the place? Maybe fast, sometimes slow, others? Here's the important question. Do you know why it's slow or inconsistent? With Datadog, you will. You can troubleshoot your app's performance with Datadog's end-to-end tracing. Use the detailed frame graphs to identify bottlenecks and latency in that finicky app of yours.

Be the hero that got the app back on track at your company. Get started with a free trial today at pythonbytes.fm/Datadog. Use a cool product. Help support the show. Matt, I think this next topic you got here, this pretty much is on everyone's mind right now. And maybe you're trying to not think about it, but there's some useful stuff going on here. Yeah. Just with the whole coronavirus, COVID-19, I've been thinking, you know, what can I do as an individual to help?

And I think a lot of people are trying to flatten the curve or limit the growth. And I think a lot of people, at least in our community, understand the importance of that, but maybe not the general populace as well. So one of the things that I thought that I could do is just, you know, spread among my local community through my local social media. Like, what is the growth locally here where I'm based? I'm based out of Salt Lake in Utah. And so I had a problem actually getting the data.

I mean, there aren't any repositories that have local Utah data. The local Department of Health is reporting on it, but their data, there's not a source of data that you can cleanly pull. So I've been pulling, making my own data source. And then I've been just posting those on Twitter and LinkedIn just with my local data to sort of track what that growth looks like and sort of put that in people's minds to sort of, hey, think about what's going on locally and see what changes you can make.

And I did some basic modeling to sort of predict what's going on because I've been reading other people's models about, you know, this is an exponential growth weight, blah, blah, blah, what that looks like. And so I did some basic models using machine learning. But it's also in the Twittersphere and elsewhere, people are saying all these data scientists are coming and just throwing machine learning at this, and that's not the right thing to do.

The right thing to do is read the literature and see, you know, what epidemiologists and others have done. And so I just want to point to some things that might be interesting. I've got a link to a Kaggle project that shows making some basic machine learning models, but it also points to a library that's found in SciPy that probably a lot of people don't know about. I know about it because I teach about it.

And that's in SciPy, there's an ODEINT function, which is a solver for what's called ordinary differential equations. And so this is probably a math class that you may have taken in college. I took one in college, and it was purely theoretical, and I've basically forgot everything since then. But there's what's called an SIR model. And that stands for you have people who are susceptible to being sick, you have people who are infected, and you have people who are recovered.

And so typically, these flatten the curves are looking at the infected part, the infected growth of that. But there's a relationship between all these three different groups, and they're more complex models. But if you use ordinary differential equations, that is the tool that epidemiologists and statisticians use to plot these and determine what's going on here, rather than just throwing it at linear regression or trying to do a machine learning model that way.

So I just want to point people at this Kaggle project has got an example of doing this SIR model. It's also got some basic machine learning models as well. But be aware that, you know, a lot of these things that we learn about, that in theory, you think, oh, that doesn't make sense. This is actually a case where ordinary differential equations are the right or one of the right tools to look at this data and understand what's going on there. Yeah, this is a cool project.

Yeah, definitely a cool project. I'm sure there's a ton of data science going on around all of this. There's a lot of data. It's coming from different places, like live dashboards and stuff. And I think this is really cool. I didn't know about the SIR model. That's cool. There are a bunch of other Python libraries as well that epidemiologists have created and whatnot that implement these SIR models. And there's another one, S-I-E-R.

And so check those out if you're interested in sort of digging with the data. But a plea to people to think about what you can do for your local community. You know, if you've got skills to help out, what can you do locally to help out and help others? Yeah, absolutely. Also, random side point here, looking through this code on Kaggle, I'd never realized that you could unpack a tuple in a nested way. Like thing, comma, tuple unpacking thing, right?

So where you can layer these in deeper and deeper. That's pretty awesome, actually. Yeah. Your data structure is nested, right? Not necessarily going to make your code easy to read, but you can have fun there. It can definitely make it shorter. All right, cool. That's a nice one. Brian, you're getting all philosophical on this with this next one. What's up? Okay, so this is totally, we're going from serious to definitely not serious. So I noticed this also.

So there's a Reddit thread that's now, or I don't know if it was Reddit or Stack Overflow, but it got taken down. But essentially the question was, why does all return true if the iterable is empty? So there's an all keyword in Python that I guess actually a lot of people don't know about. That takes an iterable and it returns true if all of the elements of the iterable are true. Or evaluate to true in a Boolean context. That's really helpful for a lot of things.

The interesting aspect is, what should it do if the iterable is empty? And because, you know, actually the person asking the question said, shouldn't it be false? Just like, you know, you can say if list, and if it's an empty list, it's false. Why would all be true if it's empty? And I enjoyed the conversation. And somebody wrote an article called, about this, why is, why does all return true?

The end lesson is, it doesn't matter why, because the core team decided it, and you just need to know it. And work around it. It's been thusly decreed to be true, so therefore it is true. Yeah, and then one of the things I wanted to point out from this discussion is the statement, all unicorns are blue. I just love that. You can't tell me, it is definitely true, because there are no unicorns. So therefore it's true for me to say all unicorns are blue. Yeah. And so I like that.

And I guess I'm glad that my daughter doesn't listen to this to hear me say that there are no unicorns. Sorry, honey. Don't break her heart. Next, you can talk about no Santa or what's going on here. Like the tooth fairy is not real? Come on. But the person writing this article, Carl Johnson, is actually also a philosopher and a programmer. So he talks about this 2,500-year-old debate in philosophy about whether or not all unicorns are blue, should be true or false.

And also we get talk about predicate logic and Socrates and Aristotle and syllogisms and things like that. Actually, we never, at the end, I still don't know why the core team chose that that is true. But it's a fun thing to look into. That's fun. So looking at it from the outside, I envision it working like this. The way all works to be efficient is it says for thing in collection, if not thing, return false. Go all the way in, return true. And it just never goes into that loop, so return true.

Probably, yeah. But I probably got to go and open up the CPython source code to find out. Matt, what do you think? I don't know. I'm looking at the Unicode symbol, the Unicode emoji in my Python REPL right now. And that's hex code point 1F984. And it doesn't look blue. It looks pink. So something's got a pile of... We definitely got to put... Somebody's going to have to put a comment on that blog post. Yeah. Yeah, that's not true. All unicorns are pink.

It's interesting that they did make it true to your point, like in a Boolean context, right? Anything empty in Python is false. So... Yeah, yeah. I mean, another option would have been to raise an exception so you can't ask for the truthiness of nothing. The main reason why I wanted to bring it up and the main reason I enjoy reading this article is now I will never forget that all of nothing is true. I'm also thinking, have I ever used all in an if statement?

I don't know that I have used all in an if statement. Where do you use it? Hey, yeah, I guess I have. Yeah, I've used it. Usually I'll put like a set... Not a set... Some kind of generator expression in there. Because I don't usually want to test all the things are actually true. I want to test like the dates are greater than today for all of them or something, right? So put a little comprehension in there and then ask all of that.

Yeah, I guess it returns a Boolean, so you would put it in an if statement. I guess so. I don't use it a ton either, but every now and then I'm happy with it. If I put it in an if statement, am I going to loop over the contents of all, right? I don't know that I have it in an if statement. I loop over... No, no. It would be to avoid a loop, right? It would be like one line of loop, basically. Yeah. Cool. Yeah, I won't forget either now.

I didn't realize it was so philosophical, but apparently here it is. All right, last one. This was really quick. This is a project written by Jean-Sebastien Douai. Did I close it right? Called pytest Monitor. And the idea of pytest Monitor... Brian, are you familiar with this one already? I looked it up quickly, yeah. But I haven't used it before. Yeah, but okay, cool. Basically, you pip install this and then anytime you run a pytest test, it's going to automatically collect some data for you.

It'll analyze memory consumption, timing, CPU usage, stuff like that. And it'll put it into a little local SQLite database file, and you can look at it over time and whatnot. So it's pretty cool, right? If you want to say, well, how long does this code take to run on the production machine versus on our laptops, right? You actually get tracking and whatnot from that. So not a huge addition, but it's kind of cool. It's built on a couple of libraries.

PSutil and memory profiler, which let it basically go and ask all these questions on a per test basis. It's cool. And then obviously it just runs in pytest. That's cool. I could see where you might want to have a report where you just want to run, limit what that's running on. I don't know that I would want that necessarily on everything, but you might have some hotspots or whatever where you want to monitor that and report on that.

Having it on everything seems like... I don't know what the performance implications are of all that monitoring. I think it'd be cool to see... This is one of the parts where I'd like to actually see the reporting of this project have some reporting that's nicer around it, because that's some really cool information, but I think some reporting would help it. Yeah, it doesn't look... It's not beautiful, is it? It is in the SQLite database.

You could grab it and do what you want, but then you've got to write that. It's like coverage. One of the wonderful things about coverage is the reporting part of it. Yeah, absolutely. All right. Well, if that's something you guys care about, go install that and check it out. All right. Well, that's it for all of our major items. Brian, Matt, you guys got anything you want to throw out there extra before we get to our joke? Stay safe. Yeah, absolutely. I've got nothing extra.

How about you, Michael? Well, I took two of my projects that I've been kind of fiddling with for either a short time or a long time, depending on which one, and put them both up on PyPI as things you can now pip install. So that's kind of cool. So the switch laying, my little extension to add switch to the Python language, you can pip install that now. I still love that thing. I use it all the time. And then my markdown subtemplates. Oh, what's that, Matt? You use that in production. Oh, yeah.

All the time. Awesome. Yeah, there's like a couple of places where it would be like this huge if statement or some other weird lookup. And it does cool stuff to say like, oh, you already tested for this case. Or you're like, have the same case in two places. And you would miss one, the second one, because it'd be caught by the first and so on. Cool. Yep. And then the second one, the markdown subtemplate thing, which we talked about before, but it was not then pip installable. So now it is.

People can check those out. Do you have tests on these, man? Of course we got tests on those. Okay. I don't have pytest monitor on it, but we got tests going. I have tests in there. So they do exist. The code does exist as tests. It does. Yes, we can speak of it. Yes. Are you all ready for a joke? Yes. This one is, it's not really that funny. It's more like... As opposed to the rest of our jokes. Dude, I think I've done that. Well, some of them are like meant to be straight out funny.

This one's like funny, ironic, because yeah, I did that too at one point or something like that, right? So this guy on Twitter sent a message, sarcastic pharmacist, sent it over and said, I was listening to a discussion on TalkByThon about rebooting a server instead of chasing bugs and thought you should check out xkcd.com 1495. And there's just a picture and it has like a trade office. It says, okay, why is everything broken in my life? Here's the deal.

like I could spend one to 10 hours figuring out why my server keeps running out of swap space and crashing. Or I could spend five minutes plugging it into a light timer that reboots it every 24 hours. That takes five minutes. Let's do that. Yeah. So true. Yeah. That's actually an interesting thing. We just ordered a bunch of web programmable power strips. Yeah. Because one of the things you do when working with electronics is sometimes power cycle the things.

Ain't no way to go and do that when I'm working from home. So. How interesting. So you built that into like the CI, CD, hey, with the tests, like let's do that. Sleep. Most of the time, these aren't problematic, but there is the occasional in development instrument where, or in development operating system portions or something like that, where it gets into flaky situations and rebooting is a good, is a good thing to do from the start.

Because as a software developer, I can get things into really wacky states. It doesn't happen a lot, but it happens enough to where it's good to know that, yeah, that you can buy these web power switches. We're getting industrial ones, which are kind of expensive because you can stick them in instrument racks, but they're just a normal power strip, but you've, they've got a web address and a rest or on a rest like API that you can put them in strips.

And if you, yeah, if you want to use them in a CI, CD pipeline, you can call them that way too, if you want. But normally we just have them as a backup so that we, we can log in and reboot them if we need to. You don't have them connected to Alexa. Alexa, reboot my computer. No. Yeah. My test won't pass. Help. Shall I reboot again? Yes, please. Awesome. All right. Well, Brian, thank you as always. And Matt, thanks for being here today. It's fun to chat with you. Yeah. Thank you.

Yeah. Thank you for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at pythonbytes.fm. If you have a news item you want featured, just visit pythonbytes.fm and send it our way. We're always on the lookout for sharing something cool. On behalf of myself and Brian Okken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.

Transcript source: Provided by creator in RSS feed: download file