Python Bytes - #277 It's a Python package showdown!

Episode Date: April 2, 2022

Topics covered in this episode: March Package Madness nbpreview strenum Code Review Guidelines for Data Science Teams Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/277

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 277, recorded March 28th, 2022, and I am Brian Ocken. I am Michael Kennedy. And I'm Thomas Geiger. Welcome, Thomas. Welcome to the show. Thanks for coming on and being a guest. Can you tell us a little bit about you? Thanks, Brian, and thanks, Michael. Big fan. So it's an honor being here. I'm the creator and maintainer of the Piper Task Runner, which it so happens you discussed

last week. So I come in riding on that wave. Yeah. Yeah. Very cool projects. Congrats on it. Thank you very much. Well, so Michael, it's March.

It is March. It's like March Madness, right? Yeah. So Chris May sent in this thing that says, hey, Python Bites people, here's a fun thing to cover. March Madness, but for Python. And for those of you who are not college basketball fans and follow it carefully, March Madness is basically the playoffs for the college basketball and it's single elimination. You start with 16, I think, and then every team plays another one that's down to eight, then down to four and so on. So that's the idea, but for Python. And check it here. We

have round one, I guess it starts with 32 and then 16 and so on. So we've got these different rounds and some of the rounds have already occurred, but the winner, the champion is still yet to be crowned. So you all need to get out there and vote. I'll tell you how in a second. I'm a bit amazed NumPy is outdoing PyTest there. It's outdoing it pretty handily. I mean, it did outdo it, right?

So if you go here, what you see is this tournament bracket. And the first ones were like NumPy reddit and redis and numpy won and then pytest versus lxml parser and pytest won that one handily and then numpy and pytest had to uh face off and as thomas says surprisingly pretty pretty badly beat up on pytest iest. Brian, are you okay with this? How are you feeling? I didn't get to vote, so I'm not sure how this was done. Yeah. This is going to be the start of a long blood feud

between the NumPy community and PyTest. Well, and the other part of this story I'm telling, the other side of the bracket was Scikit-learn versus Beautiful Soup. And Beautiful Soup, oh my gosh, I think it was a buzzer beater came in at the last second and it's like 52 to 48 beautiful soup one and so now this week we're in the elite eight and so uh you can come and vote i'm gonna vote like um and my metric here sort of how useful and how impactful is this thing not necessarily do i like it better. So I'm going to vote over here.

I'm going to say for NumPy versus Beautiful Soup, NumPy. I actually would use Beautiful Soup probably more, but I think NumPy is more impactful. Pip versus Matplotlib. I'll pip all day long. Same reason. Pandas versus Docker. Ooh, I do like me some Docker. I'm going to go with Pandas.

And then wheel versus requests. I'm going to go with requests. I know wheel is important under the covers, but I don't see it. So I'm going to go with pandas. And then wheel versus requests. I'm going to go with requests. I know wheel is important under the covers, but I don't see it. So I don't want to think about it. So requests, top of mind, I use that all the time. So here you can see I voted and everyone else who would like to, you can just click the link in the show notes

and you can vote too. And these are basically open for a week and then the elimination happens and it moves on. So we're going to see what happens in the final four coming real soon, actually. So, okay. we're going to see what happens in the final four coming real soon, actually. Okay, we're going to have to highlight this earlier in the month next year so that people can vote. You want to create some voting blocks like in the reality TV shows. The one on the island, Survivor.

Yeah, Survivor, exactly. Oh, you know, I'm sad to say scikit learns uh torch has been extinguished you're gonna have to leave the island yes that's right anyway thank you chris for sending this in this is fun and uh it's it's very low stakes it's just sort of uh you know bragging rights for what it is yeah bragging rights and whatnot so uh we'll we'll send out a tweet or something about it you can get in there and check this out so definitely yeah how about you brian what's your next one i'd like to talk about nb preview which actually i thought we covered but i couldn't find it anywhere um so nb preview is a notebook previewer so ipython or jupiter notebook um and uh it's it's kind of neat it's a command line thing

and i like to spend a lot of time on the command line so this um so you you just once you pip install it uh or um since it's not really part of your project i used pipx pipx installs of this oh yeah but it's um so you you you say in B preview and then you can give it some options, but then a notebook file name and it will, um, uh, it just previews your, your notebook in, in ASCII, uh, which is awesome. Um, but it's not just ASCII it's rich. So it's, uh, we've got colors and nice colors and tables and stuff. There's actually quite a few features that I want to run down.

One of the things I, I loved right away. It was, um, it's not just a file. I said, I tried it out on some local files, but you can give it like, uh, like a URL or something. There's a, there's a great way to, you can get a whole bunch of stuff. You don't have to have local notebook files to put it in. Oh, that's cool. The yeah, here it's showing even you can curl something and pipe it to it.

So it'll take inputs as pipes. And the, the, the fact that it's a command line tool and it deals with pipes correctly is what I really like about it. So you can pipe a notebook to it. I don't know if you'd do that or or not but you might want to pipe output so by default you get these nice colors but if you pipe it to an output you can pipe it to grep or something and you can grep for things um so this is kind of great i don't know if you've ever tried to grep for something in a notebook but there's a lot of junk around it there's a lot of formatting stuff that and if that's not really what you're looking for it's not helpful so be having this tool to strip that out

it's pretty nice oh yeah that's really nice i love the ability to just pull this up and view them and given that it's based on rich like it has yeah formatting for all the cells i mean jupiter is like markdown plus code and rich does rich highlighting for both of those. So that's cool. It looks like it's got some pigments under the hood also, which happens Ian brought up last week, I think. Yeah, exactly. A lot of continuations this week. So a lot of cool stuff that you would expect,

like code highlighting and stuff. But the thing that really stood out to me is what does it do with images, like graphs and stuff. And the images are kind of amazing they're like these uh by default these block things which uh not that clear to to use for you you know utilities but it's kind of shows you what it's going to do and there's a there's a few options you can do um uh you can do this this block level thing. And I like the characters.

So it does like the ASCII art stuff of your images. Or it uses the Braille stuff. I don't know if there's an example here, but you can do Braille for all the dots to show up, which is kind of neat. It even does like cool data frame rendering. So if you've got a data frame printed out there in your notebook, it'll format it nicely. So even LaTeX is formatted, which is kind of a surprise.

I didn't expect that. So that's kind of neat. Anyway, I specifically, oh, cool, hyperlinks too. So you can click on HTML that's in there. That's kind of neat. The thing that I really liked that is the simple part though is to be able to strip stuff and pipe it to grep and things like that.

So this is handy. Nice. Thomas, what do you think? Oh, this is great. I don't really use notebooks all that much, to be honest with you. So it's a little bit lost on me, but more command line is absolutely good, and it looks delicious.

Yeah, it does. The terminal, the TUIs, the terminal user interfaces are definitely coming on strong these days. We forgot to ask you, what kind of Python do you do? What's your flavor of Python? Are you building APIs? Are you doing data science? What kind? Oh, yes. Well, the Piper project is what consumes most of my hours. do you do? What's your flavor of Python? Are you building APIs? Are you doing data science?

What kind? Well, the Piper project is what consumes most of my hours. So I guess that's normal-ish Python as opposed to notebook-ish Python. Data science, I don't really do too much either. So it's mostly traditional style Python programming. Yeah, got it. All right, well, your topic is up next. Tell us about it. Well, funnily enough, this is very traditional programming. What I bring for you for your delectation is PyFakeFS, which I think is a sadly relatively unknown open source library.

And I'd like to give them some props and recognition because I think it's amazing and it's made a huge difference to me and my own code and the Piper project. So hopefully this helps out some other people. Now what it is is a fake file system. So in a nutshell it intercepts all calls from Python to the actual file system. So if you think of the open function, the built-in open that is, or SHU tool or Pathlib, all of those that might have real world side effects in terms of the disk, the fake file system will intercept these.

And this is completely transparent. And which is to say that your functional code doesn't need to know about this. So the patching happens without you needing to inject something or without you needing to go and alter your functional code doesn't need to know about this. So the patching happens without you needing to inject something or without you needing to go and alter your actual code to take countenance of the system. Now, what's great about this is the moment you start talking

about testing a file system, you're almost by definition in integration testing or functional testing terrain. Like it's not a unit test anymore, which comes with its own disadvantages. So if you do want a unit test, then let's consider a simplistic example, right? If the code under test writes an output file. So first of all, you need to patch out that if you're in your unit testing framework with something like mock open. But secondly, you probably have a path lib in there somewhere where you're either creating the parent directories for the path to check that they exist

before you try and write to that location. So now we already have two things we have to patch out. And then on top of that, you might be doing it in a loop. You might be writing more than one file. And the testing becomes very clumsy very quickly whereas once you use the pyfs library um you can just write as normal validate against that file system using the standard python inputs and what you end up with is and once the test finishes it all just goes out of scope and you don't even need to bother cleaning it up what's yeah that's cool and you can specify the string that is the content to the file so when the thing reads it you can control the what it sees right so it comes with a and brian you're going to love this it comes with a super handy pytest fixture so if you are using

pytest which you should you can just add the fs fixture to your unit test and now everything in your in your unit test will be going to the fake file system rather than the real underlying file system. That's pretty cool. Yeah. And the helper functions allows you, like you were hinting at, Mike, you can specify encodings, you can write in binary. It's super useful.

Something else that I use quite a lot is the ability to switch between Linux, Mac, and Windows file systems, which again, for a piper is such a boon to be able to test the cross-platform compatibility. Oh, interesting. So if it asks for the representation from a pathlib thing, it'll do SQL and backslash instead of forward slash. Yeah, exactly right. So all of these things are achieved.

I'm relatively conservative when it comes to pulling in new libraries because I'm, especially if the library feels heavy and I feel I can do it just using standard lib functionality. And also with some libraries, I'm a little bit worried that they might stop being maintained or something like that. But PyFigFS has been around since 2006,

developed by Google. It was open sourced in 2011. The maintainers are really on it. I submitted and had a PR merged earlier this year within an afternoon on a Saturday, which for open source is very quick. So they're on top of it. Great project. Check it out on GitHub. Check out the documentation too. It's well documented and it's super useful. And I was looking at the Taksini. It looks like it's tested to be compatible with PyPy also, which is kind of nice. Yeah. Yeah, absolutely. Especially for what I'm doing in Piper, where wrangling configuration files is a lot of the functionality as a task runner.

You're forever reading JSON, writing out YAML, converting between formats, converting between encodings, swapping out values inside configuration files, merging configuration files. And I'm now able to test all of this stuff without having to write integration tests for each and every permutation, which has been such a boon. This actually does way more than I thought it did. I'm going to check this out. This is neat. Yeah, there's a lot of cool stuff there. Absolutely. Yeah, and also if you've...

Chris and Alvaro both think pretty, pretty neat out there. They're digging it. Yeah, and I see the comment there. It is like Temp Path, with the difference that it's not actually writing to the disk itself, of course. And what's also a little bit difficult when you're using the temp directory and the temp file modules is depending on how you're testing, it doesn't always help you very much because the thing that might be generating the file might be the code under test. So you're effectively going to have to intercept that and create a temp file to attach to it. And then the temp file will clean itself up. But that starts interrupting the flow of the functional code so much that I start questioning whether it's even a useful unit test anymore. Yeah, absolutely. Well, very, very cool.

So Brian, before we move on, let me tell you about our sponsor, all right? All right. This episode of Python Bytes is brought to you by Microsoft for Startups Founders Hub. Starting a business is hard. By some estimates, over 90% of startups will go out of business in just their first year. With that in mind, Microsoft for Startups set out to understand what startups need to be successful and to create a digital platform to help them overcome those challenges. Microsoft for Startups Founders Hub was born. Founders Hub

provides all founders at any stage with free resources to solve their startup challenges. The platform provides technology benefits, access to expert guidance and skilled resources, mentorship and networking connections, and much more. Unlike others in the industry, Microsoft for Startups Founders Hub doesn't require startups to be investor backed or third party validated to participate. Founders Hub is truly open to all. So what do you get if you join them? You speed up your development with free access to GitHub and Microsoft Cloud computing resources and the ability to unlock more credits over time. To help your startup innovate, Founders Hub is partnering with innovative companies like OpenAI, a global leader in AI research and development, to provide exclusive benefits and discounts. Through Microsoft for Startups Founders Hub, becoming a founder is

no longer about who you know. You'll have access to their mentorship network, giving you a pool of hundreds of mentors across a range of disciplines and areas like idea validation, fundraising, management and coaching, sales and marketing, as well as specific technical stress points. You'll be able to book a one-on-one meeting with the mentors,

many of whom are former founders themselves. Make your idea a reality today with the critical support you'll get from Founders Hub. To join the program, just visit pythonbytes.fm slash Founders Hub. All one word, no links in your show notes. Thank you to Microsoft for supporting the show. Awesome. Thank you, Microsoft. Now, let me tell you about something that sounds incredibly simple, but as you kind of unwind it, you're like, wait, it does that too? Oh, it does that too? Oh, that's kind of cool.

Pretty similar to the fake file system that Thomas was just telling us about. This thing called Sternum. Sternum is a fantastic name. It's short for string enum, right? Enums, when were enums added? Was that three, four, something like that? A little while ago. So enums have been in Python for a while,

pretty much prehistory now that those are no longer supported. And with enums, you can write cool code that says, this class, its fields are enumerations. And then you can say, you know, enum type dot enum value. And you can use that instead of magic words. So for example, you might have HTTP method or something like that, or let's say HTTP status. Start with that one. Cause that's like a built-in type thing you could do easily. You could have a 200, a 201, a 400, a 500, a 404,

those kinds of things. So you could have a like HTTP statuses dot, and then those types with those numbers, right? But there's a couple of challenges to working with those. Their natural representation is a number, not a string. And I know you can derive from enum and then also derive from string. But like I said, more stuff happening than just that. So this sternum allows you to create enums like that and use the enum auto the enum.auto field. So I can say, here's an HTTP method,

but verbs is really probably what it should be. So you have a get, you have a head and a post and a put, and you just say auto, auto, auto, auto. But the actual representation is that the get is a string get. And the put, want, or post is put or post. Yeah, and Alvaro is out there pointing out, thank you, that sternum was temporarily part of 3.10, but that it was dropped.

So there was- I saw a note that it might be included in 3.11 again. Okay, that'd be fantastic. It would be. Yeah, so there's some really neat stuff in here. For example, one of the things that's nice is because this thing basically has the value string where you're using it, you can actually use it where a string would be accepted. So here, if you're doing a request to a URL and you've got to say method equals here,

you can say method equals HTTP method dot head or whatever from the enum and it directly passes just the string head to the method. So it's a really nice way to gather up string values that are part of a group, right? Like HTTP verbs or something like that. Wow. So that's pretty neat. Okay, the side question is, I don't really use auto much.

Is auto used anywhere else, or is auto just an enum thing? It comes out of the enum module. Okay, so it's part of this. So it comes out of the enum module okay so it's um so it's part of the enum thing all right and one of the things i really like about this that is super tricky with enums is databases so for example imagine we had um we had like get head and post so we just had auto but it was an integer based one so it's like one two three and we store it in the database right as a one or two or three and then you parse it back fine but then somebody adds another auto thing in there and they don't put it at the end they're like oh this one starts

with a d so it goes after delete yeah well all the stuff after that one is now off by one in the database right like so this if it goes into the, it goes in as a string and it'll parse back as the string. It also has cool stuff like lowercase sternum and uppercase stringinum. So you can derive from that instead. And then no matter how you define your field, you get a lowercase string version or an uppercase string version.

And there's other cases as well. There's Pascal case, snake case, kebab case, macro case, and camel case. Woo! Go crazy on them people.

And you can have the same code, but then like the string representation varies. So that's pretty awesome. I think I'm going to go with kebab case just because that's fun to say. It's so fun, I know. And then, yeah, you can also directly assign the value. So enum value equals some string and then you don't have to worry about a casing. It's exactly the string that you put.

Yeah. Right? So there it is. It's like regular enum, but strings. And as people pointed out that it's not that different from what people have been considering for CPython. I'm pretty sure I heard about it as well in being in there,

but the fact that it's not there, maybe it'll be there, maybe not. We'll see. It's interesting, but this has a lot of cool features. And if you're not using 3.11 or want to depend upon it, this is a small little project.

Yeah, it's nice. Cool. Thomas, what do you think? This is great. I especially Yeah, it's nice. Cool. Thomas, what do you think? This is great. I especially like how it's smart enough to autocast so that when you use the enum, it will end up translating to a string when you're actually hitting the database

or your underlying API. Yeah, it makes it actually usable in those situations just directly, which I think is great. And funnily enough, the example they chose is so great by way of great documentation because http verbs are just almost the the example of magic strings right yeah exactly exactly quite cool all right right over to you i'd like to review your code a little bit no um i don't know i was trying to do a transition thing going. But so Tim Hopper wrote this article, which I absolutely love.

And it's called the Code Review Guidelines for Data Science Teams. And I just recommend everybody go read it. It's short. It's good. But one of the things I really like that he highlighted is before he got into the code review or the code review guidelines, he started with, why are we doing a code review? What is a code review for? team is going on and talking, maybe even sticking it in a, a, a participation guideline, uh, in a project, open source project even is that, um, it's not just, it's not just so that we can look at the code or, you know, check it, merge it. So his reasons for a code review are first code

correctness. And that's, that's what we think about is making sure the code's correct, but also code familiarity. So you might be the expert on a project and everybody else is only kind of new on it. You still should have code reviews for your code changes so that everybody else can watch also and get familiar with the changes going on. So that's nice. Design feedback, of course, and mutual learning and regression protection are all reasons why he did a code review. And the other thing I also love is what to leave out of code review. So code reviews are not about trying to impose your guidelines on somebody else. And they're or and they're also not a reason to to push off responsibility so as long as your code's getting reviewed it does not be correct right because everybody somebody will catch any problems it's a bad thing to do in a code review so uh make sure

your code's correct that as far it's all cleaned up as soon as you, what you think is it's ready and then submit it, but then also be nice. So, um, being nice is important. Yeah. Very cool. So then it goes, he goes through, uh, I'm not going to go through all these here, but he goes through different things about, uh, what to think about before you do a, uh, create a pull request and then what to do if you're reviewing a pull request. And a lot of these are just, they're just around being a kind human to the person on the other end. So that's really kind of what it's about. I saw a mention in there somewhere that I really liked, which is, I mean, by nature, a code review is sort of nitpicky, right? You're paying attention to

flaws, but it's nice to complement also like if there's something nifty or cool or cute acknowledge compliment call attention to it oh that's that's a good point and i really like that i also think so one of the things that you don't want to do in a code review is um like one of the guidelines is is we're not looking for perfection uh we're just it it's gotta you know that isn't one of the things we're looking for. So what happens if you notice something and you're like, it's a little weird. I'd like to say something about it,

but I don't know how to say that. His comment is to have, if you've got a minor thing that you want to comment on, go ahead and sort of tag it. He recommends tagging it with knit in it for a nitpick or something. Um, just to be clear that I'm, I don't know if I like the word knit, but, uh, to be clear, Hey, I noticed this. Maybe we want to change this in the future, somehow indicate to the person that they don't need to fix this before the PR gets merged.

You're just noticed it. Um, so, and it might be something that the, the person that submitting the PR didn't realize in the first place and went, Oh yeah, I don't like that either. I'm going to fix it. Or yes, I do know about that and I do plan on fixing it later or what, you know, whatever. So, uh, just an interesting guideline. And, uh, I think it can just, I'm kind of, uh uh i've been on a kick lately of reading things about community and um and creating cohesive teams and the review process is definitely some somewhere to you need to have attention to for most teams so anyway that's it yeah i like it this is really handy um i love the idea of having as much as possible have the automation make the complaints.

Definitely. And like Thomas said, have the people give the compliments and the sort of interesting discussion, right? But like if black can just take care of the formatting, like you shouldn't have to debate the formatting. Yeah. And if a linter can tell you, you know what, there's something wrong with this, just like let the linter be the bad guy. Yeah, it was one of the guidelines that he brought up, which is interesting, especially with CI, and we're pushing a lot of things on black or linters to wait. So wait a little bit. So don't review a code review right away,

especially not if the CI hasn't finished. Let the CI finish and let the person creating it fix anything before you jump in. I also, pet peeve of mine, don't comment on it right away. I might, one of the things I do frequently is I'll create a PR, especially for in a work setting. I'll create a PR and then there's some complicated things. So I plan on going through and writing some comments around some of the complicated bits. Like, why did I do certain things?

And so if you see a PR right away, especially from me, wait 10 minutes or so before commenting on it. Because I might have answered your question before you get a chance to ask it. An exclamation might be coming. Yeah. Indeed. Anyway. Awesome. All right, might be coming. Yeah. Indeed. Anyway. Awesome. All right, Thomas,

over to you. We're about to head into controversy because there's been some discussion. Are you going to bash on something? Come on.

I'm going to bash it over the head like a caveman. Bash it with Python. So partly inspired on the continuation of last week's discussion you had about running subprocessors from Python. And Itamar Turner-Trowing wrote an article this week called

please, please, emphasis mine, stop writing shell scripts. Now this, as you might imagine, raised a bit of questions on the usual places like Reddit and Twitter. But if nothing else, controversy aside, the article is a very good and succinct summary of the most common gotchas and problems with Bash, which we can almost all summarize as that error handling is strange if you're used to other programming languages. Like Bash is a kingdom unto its own when it comes to programming languages. So he also gives a great recommendation for if you really, really have to write in Bash, what you might want to do.

And that would be to use the unofficial Bash strict mode, which basically involves setting that boilerplate on top of your bash. I'm not going to cover all the details, but basically the E and the U option will fail immediately on error. It will fail on unsaid variables. And if you add the pipe fail option, errors won't pass between pipes. A pipe will actually fail immediately if there's an error processing. Awesome. Like it should. Like it should indeed. But the point is there's batches in all technology and there's a lot of problems here.

And let me add, although this article mostly aims at batch, I am very happy including born and SSH and fish and take your pick underneath the same dictum now he goes on to talk about the typical reasons we hear of why we should be using bash of which the top one is well it's the most common you're guaranteed to have an sh runtime at least on any given machine that you're going to be using but But the point is not really, because when we're doing code automation, almost by definition, the programming language you're coding in, its runtime is on the server. So this argument that somehow it's good to go to the lowest common denominator, aka SH or bash, when you already have Python on the machine is sort of,

well, why? And especially when we're talking Python on the machine is sort of, well, why? And especially when we're talking about Python, which is so great at automation, it just baffles the mind. That's a good point. You don't have to set up a compiler or any of that kind of business. I'd say the same thing about Golang. By definition, when you're compiling Go, the Go compiler is right there. You might as well be writing a go script or whichever your

programming language is. I mean, maybe if you're starting to talk about like C or C++, there's maybe a different argument that we can have there. The second point he brings up is what I'm going to paraphrase as get good, which is this bash guru response, which we saw a bit off in the last week that, oh, you're just bad at bash. Like if you were better at bash, you wouldn't be complaining about these things, which, you know, is not a great reason. It's, you know, just because it's not better because it's hard, right? We have better tools available.

We have tools that behave more responsibly. And something that I think is very important in line with what you've been talking about, Brian, about building teams, is very often your automation activities start becoming this specialized zone that only two or three people on the team can even look at because they're the bash gurus and everyone else is too afraid to touch it. Whereas if you keep your automation activities within the language you're coding in, suddenly everyone on the team can start carrying their weight, right?

Yeah, I kind of relate to this a lot. I've been on projects where we've had a lot of our automation in Bash and others that have been other languages. Right now, it was one of those things of especially if you're not if you're not looking on a windows environment bash isn't there all automatically so um and a lot of the team members might not be familiar with it so the the thing that i don't know if he addresses this

the thing that was i was thinking about was um we all know Python if we're programming Python but we might not all know the autumn the like the automation parts of it though the way to do like file manipulation or right I say yeah until and that's that's kind of stuff that we might be familiar with with bash because we if we're using it all the time on the command line, I already know how to do it. But I might not know how to do that sort of stuff in Python because I'm not using Python like that. But anyway. Well, my response to that would be that whatever the thing is that you don't know how to do in Python, your chances of running into trouble with Bash are, to my mind, a lot higher than they are with python or at least when things misbehave in python your control of flow is better so that you probably will have a especially as the scripts start getting bigger you will have better control over where the issues

might be or you you would be better able to isolate those areas that you're not exactly sure of. I saw someone in chat last week raise the specter of make files that call shell scripts that call make files. And I mean, this is not uncommon. I'm sure we've all seen these things. And I'm actually very interested in the psychology around this because we're all coders, right? I assume we're here because we enjoy automating things. We enjoy solving problems. We probably have a certain problem-solving sort of mindset that got us into this to begin with. Yet, it seems like we spend so much time automating our customers' business processes that we forget to automate our own coding processes. Or when we do, we

deallocate the priority, we debududget it we end up focusing on all sorts of other things other than this essential housekeeping yeah or treat it like a throwaway code instead of code that needs to be carefully factored and exactly right and i would argue it's a bit like housekeeping you know no one likes doing it but if you don't want to live in a pig style you've got to do it you know instead yeah instead. Yeah. Well, also, to be honest, I was there once of like, I don't know how to do this automation stuff in Python, but it bugged me that I didn't know how. So I'm like, OK, well, what do I need to learn? Like the few things like searching for stuff like I normally would have used Perl for Regex

or something like that or said all that stuff you can do with Python. And actually there's tons of articles on it. It's really not that hard to go, okay, the pieces I'm missing, uh, how do I do that? And just go learn it. And, uh, and then it's not that hard to switch a lot of automation to Python. Yeah, definitely not. And I mean, so much other automation happens in Python anyway. I mean, in fact, kind of compiled programming languages will often use Python as an automation

language. It's so handy for the automation process. There is another psychological thing, which I find, or I think psychological thing that I find quite curious here, which is this dealing with complex shell scripts almost becomes this like technocratic rite of passage, where when you couple that with imposter syndrome, it's very easy to be intimidated by the bash bros when they do these really clever one-liner bashisms that you can't make head or tail of. And it's like, yeah, look how clever this is. But it's very hard to maintain. And it's almost hard to call that to account unless you're very sure of yourself. Because you almost have to justify yourself as to why you dislike it.

Like you first have to prove your bona fides. I think it's sort of the tech equivalent of, you know, back in my day, like we didn't have X. You know, like whatever X is, shoes or toilet paper, like whatever. Just because something used to be difficult doesn't mean it needs to be difficult forever more right yeah like the extra difficulty doesn't make it better it's not a video game like elden ring you know like the easier this is the more quickly and effectively you can do the housekeeping the more you can get up with the features that actually pay the bills which is to say the shiny functional stuff that you can demo and put in front of customers. Yeah, absolutely. I have some real

time feedback and also a comment for you. Alvaro says there's a VS Code plugin called Shellshock, if he's remembering it correctly. Tells me when I'm doing something wrong or might blow up. There's also a plugin for PyCharm. So if you're going to do it, have those things for sure. Yeah, funnily enough, we've got immediate feedback to that, which is the author of the original article mentions shell check, which is effectively, like the commenter mentioned, a linter for Bash. But the article also mentions that it doesn't actually catch all things either. So like all linters, it can very easily lull you into a false sense of security, while it's not really necessarily addressing the underlying problems. And I almost feel like

I don't even need to say this because anyone who's ever tried to debug a long bash script should know this. They're tricky. They fail in mysterious places and it's very hard to figure out why and how. yeah but i do like the the this article pointing out how if you have to to set up those flags to make it um you know fail quicker because that helps a lot so it's nice yeah yeah for sure and also just to be to give the author massive amounts of credit this isn't clickbait he he didn't position this as never ever use a bash uh fact, he explicitly says at the end, okay, if you're doing something super simplistic, like the typical sort of things

that goes into a get hook, a pre-commit hook, where you're just running a command or two, then yeah, sure, of course, shell script's fine. But I would say as soon as you're running loops, as soon as you're doing conditional branching, as soon as you're worried about retries, as soon as you're doing... Ohing as soon as you're worried about retries as soon as you're doing oh yeah definitely switch to python absolutely yeah yeah and then another quick question just a quick follow-up have you considered conch i i've not even heard of concha considered it so um it's i haven't done much but I've sort of looked at it. It is a shell, like a competitor to Bash or ZShell or something like that, where it's a proper Python environment directly in the shell. That's almost PowerShell-esque. Yeah, it's a little bit like PowerShell, where PowerShell is like kind of.NET C Sharp, like kind of, but not really.

I suspect it's similar here, but. And I know it's supposed to be pronounced conch, but my brain says zonch because it's funner to say. Squanching. I know, but it has the shell. It has the conch shell. So, you know, that's how you got to say it. Yeah, they even have the S card going on for the logo. That's interesting.

They do indeed. They do indeed. All right. Well, cool, Thomas. That was a good conversation. So do we have any extras? Michael, do you have any extras? You know I got extras, right?

Also, first, real quick follow-up, a real-time follow-up from Henry Scheiner and the audience, that PEP663 was the PEP around string enum. Oh, okay. And he's not sure if removing the support for that PEP means removing string enum from the standard lib or not, though. Doesn't do all the other stuff like the casing and the various other things that that cool package I talked about does. So maybe that package is no matter what relevant still or inspiration for the next one or whatever.

In terms of extras, I do have some extras. Let me see what order I wanted to cover them in. I had two, but then one got rescheduled. This is supposed to be the transformation from bugs.python.org over to GitHub, but that got pushed back a week. So I'm not going to talk about that. You just did. Well, I was going to say it's happening.

It should have happened by the time you hear this. Go check it out. No, it's not true anymore. Oh, okay. Just if you're curious, supposedly it's moved to April 1st, but it's April Fool's Day. So I'm not sure if it's really going to happen or not.

Maybe it's a long con where the joke is being set up for in advance. Yeah, exactly. Oh, we're actually never doing this. No, I'm looking forward to that happening. That's great. All right. I just have like a general theme

of sort of stuff that's like, they're all together, kind of a changing of the guard if you will um let's see here so i have been switching so much of my software stuff around i've started using vivaldi you know i've been using firefox for a long time i started using vivaldi which i think is a really neat take on a browser so switched over to vivaldi and started using that um you know there's a bunch of different things, like Mozilla laid off 250 people recently. And they're axing their developer tools team too,

which is just tragic. Exactly. Cut the developer tools team. They cut the threat team, the team that looks for like attacks. It's like, I don't know. It's starting to make me a little nervous. So I'm trying out Vivaldi. I've been doing that for like a month or so

and I'm enjoying that, right? Mike, you said it's a different take on a browser. So it sounds like there's something conceptually different about it. It's just super customizable. I think that's the thing. It's like, there's just all sorts of stuff. It comes with a built-in ad blockers and tracker blockers.

I know some of them do tracker blockers, but built-in ad blockers, nice. I mean, Brave is the other one that kind of does that, but Brave's like, well, let's just trade those ads for our cryptocurrency ads that we'll put in there for you and you get a little bit of cryptocurrency. This is like, no, we'll just block the ads. So anyway, I switched over to that,

partly motivated by just concern around this, but also just wanting to try some stuff out from Google Docs over to Zoho for other stuff and for a business email, there's so interesting stuff going on there. And then like also DuckDuckGo, I've been using that for a while. And I, I tried that a while ago and it just, I didn't feel like you switched to me. Now there's just like almost no difference in the quality compared to Google these days where it used to be. I tried like, ah, I might have to go to Google for that. Like, you know, it's several times a day. Now I don't really, if I get stuck here, usually I'd try to go to Google and get it and I get still stuck. So just got to deal with it. So

that's it for all my items. I'm just down to tell on a joke. Thomas, you got anything extra you want to share throughout there to the world? Not particularly. I'm looking forward to your quick shout out to Piper real quick. Oh, yeah. Check out last week's episode. I know we covered it last week, but yeah. Michael actually did as good an introduction to Piper as I could give. So congratulations and well done. Thank you. If you do want to check it out, support open source software, do the usual share, like,

subscribe, all the rest of it. You can check it out on GitHub. It is the Piper task runner, P-Y-P-Y-R. And incidentally, if you don't want to run bash scripts, then a task runner might be a good way of not doing so. Yeah. I was thinking about your project while you were talking about this. I don't want to shill too horribly. So I try to keep that to the end. That's our job. We basically just shill that to the end. That's our job. We basically just shill cool stuff all week.

That's our podcast. Ryan, how about you? Got anything extra you want to shout out there? I've got some stuff, but there's nothing I can share right now. All right. Well, we'll be waiting. How about we share a joke then and wrap it up? Sounds good.

So I feel like this is a missed opportunity because we had ian on last week and he was all about cyber security and using notebooks to track threats and stuff well has he considered this it was that was uh it wasn't a james bond movie right it's been several it could have been like so here is like a big server rack with just, you know, like a hundred Ethernet cables. And in a big printed sign on it, it says, in case of cyber attack, break glass, pull cables. I'll also say what surprises me. The Internet is going soft in its old age because back in my day, the first comments would have been complaining that the cables aren't tidy enough. Wow. You got to get a aren't tidy enough. Wow.

You got to get a good grip on it. Yeah, exactly. Just one zippy move with your arm and you get a yank and all hundred come out. This is exactly what I'm saying. There's a lot of cables. They should put like orange tags on the ones that are important to pull or something. Yeah. Exactly.

This is the sort of criticism that I would have expected. Actually, the entire thing has a power switch just to power off the whole thing. You don't want to lose data. I mean, come on. No, just kidding. Also, where's the axe? How do you break the glass? Exactly. Or just open the door handle. Very not very thought through. It reminds me a little bit of that. In case fire, get commit, get push, run. I mean, you know, also we're talking about IT people

who generally probably aren't, you know, that much into the pushing regime. So, you know. Or lifting axes. You know, that might be a strain. Sorry, I'm going to get hate mail for that. Oh, we are. Yes, indeed.

Well, I thought it to get hate mail for that. Oh, we are. Yes, indeed. Well, I thought it was fun, Brian. So, well, thanks everybody for having a fun episode again. Thank you, Thomas, for showing up. Thanks, Michael. And thank you, everybody in the chat for showing up. So we'll see you all next week. Bye, everyone.

Bye, everyone.