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 Okken.
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 PyPro Task Runner, which it so happens you discussed last week.
So I come in riding on AtWave.
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 Bytes people, here's a fun thing to cover.
For 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.
Then it's down to eight, then down to four, and so on.
So that's the idea, but for Python.
Oh.
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.
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 versus Redis.
And NumPy won.
And then pytest versus LXML, Parser.
And pytest won that one handily.
And then NumPy and pytest had to face off.
And as Thomas said, surprisingly, NumPy pretty badly beat up on pytest.
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 Psykit-learn versus Beautiful Soup.
And Beautiful Soup, oh my gosh, I think it was a buzzer beater.
It came in at the last second, and it's like 52% to 48%, Beautiful Soup won.
And so now this week, we're in the Elite Eight.
And so you can come and vote.
I'm going to vote.
Like my metric here is 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.
Ooh, I do like me some Docker.
I'm going with Pandas.
And then Wheel versus Request.
I'm going to go with Request.
I know Wheel is important under the covers, but I don't see it, so I don't want to think about it.
So Request, top of mind.
I use that all the time.
So here you can see I voted, and everyone else who would like to 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.
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 Learn's torch has been extinguished.
Oh, no.
You're going to have to leave the island.
Yes, that's right.
Anyway, thank you, Chris, for sending this in.
This is fun, and it's very low stakes.
It's just sort of, you know, people just enjoy this for what it is.
Yeah, bragging rights and whatnot.
So we'll send out a tweet or something about it.
You can get in there and check this out.
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.
So NB Preview is a notebook previewer, so IPython or Jupyter notebook.
And 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 you just, once you pip install it, or since it's not really part of your project, I used pipx.
pipx installed this.
Oh, yeah.
But it's so you say NB Preview, and then you can give it some options, but then a notebook file name, and it will, it just previews your notebook in ASCII, which is awesome.
But it's not just ASCII.
It's rich.
So 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 loved right away was it's not just a file.
I tried it out on some local files, but you can give it like a URL or something.
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.
Yeah.
It's showing even you can curl something and pipe it to it.
So it'll take inputs as pipes.
And 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 do that 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.
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 formatting for all the cells.
I mean, Jupyter is like markdown plus code and rich as rich highlighting for both of those.
So that's cool.
Yeah.
It looks like it's got some pigments under the hood also, which happens.
Ian brought up last week, I think.
Yeah, exactly.
So a lot of continuations said this week.
So a lot of cool stuff that you would expect, like code highlighting and stuff.
But the thing that like 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, by default, these block things, which not that clear to use for utilities, but it kind of shows you what it's going to do.
And there's a few options.
You can do 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 will 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 like that is the simple part, though, is to be able to strip stuff and pipe it to grip 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.
It's 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?
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 shutil 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 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 you want to, if your, 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 pathlib 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 in 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 PyFaFS library, 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.
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 unit test will be going to the fake file system rather than the real underlying fake 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 PyPer is such a boon to be able to test the cross-platform compatibility.
Oh, interesting.
So if it asks for, like, the representation from a pathlib thing, it'll do c colon backslash instead of forward slash.
Yeah, exactly right.
So all of these things are, you know, like, 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 PyFakeFS 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 toxinny.
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.
This is I'm going to check this out.
This is neat.
Yeah, there's a lot of cool stuff there.
Absolutely.
And 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 desk 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 temple 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/foundershub, 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.
It's 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 because 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 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, enum dot auto field.
So I can say, here's an HTTP method with like verbs is really probably what it should be.
So you can have a get, you can 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 like put one or post is, you know, put or post.
Yeah.
And Alvaro is out there pointing out, thank you, that sternum was temporarily part of 310, but that it was dropped.
So there was...
I saw a note that it might be included in 311 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 like gather up string values that are like 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?
It comes out of the enum module.
Okay.
So it's part of this.
So it's part of the enum thing.
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, we had like get head and post and we just had auto, but it was an integer based one.
So it was 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 do this.
If it goes into the database, it goes in as a string and it'll parse back as the string.
It also has cool stuff like lowercase sternum and uppercase string enum.
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.
Okay.
And there's, 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, 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, you know, enum value equals some string and then it like, right.
You don't have to worry about a casing.
It's exactly the string that you put.
Right.
So there it is.
It's like regular enum, but strings.
And as people pointed out that it's, it's not that different from what people have been considering for CPython.
I'm pretty sure I'd 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, you know, this is a small little project.
Yeah.
It's nice.
Cool.
Yeah.
Thomas, what do you think?
This is great.
I especially like how you can, how it auto, it's smart enough to autocast so that where you use the enum, it just, it's, 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.
Yeah.
Which I think is, 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.
Yeah.
Quite cool.
All right.
Ryan, over to you.
I'd like to review your code a little bit.
No.
I don't know.
I was trying to do a transition thing on, but so Tim Hopper wrote this, this, this, this,
this article, which I absolutely love.
And it's called the code review guidelines for data science teams.
And I just recommend it really go read it.
It's, it's short.
It's good.
But one of the things I really like that he highlighted is before he got into code, the code review or the code review guidelines, he, he started with, why are we doing a code review?
What is a code review for?
And, and this is something that I think that is important just to talk with whoever, whatever team is going on and talking, maybe even sticking it in a, a, a participation guideline.
In a project, open source project.
And that's, that's what we think about is making sure the code's correct.
But also code familiar, 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, you know, watch also and, and, and get familiar with the changes going on.
So that's nice.
Design feedback, of course, and mutual learning and regression protection are all things, reasons why he did a code review.
And, and what, the other, 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.
Um, 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 doesn't have to be correct.
Right.
Cause everybody, somebody will catch any problems.
It's a bad thing to do in a code review.
So, 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, being nice is important.
Yeah.
Very cool.
So then it goes, he goes through, I'm not going to go through all these here, but he goes through different things about, what to think about before you do it.
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.
So I saw a mention in the summer 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 compliment also.
Like if there's something nifty or cool or cute, acknowledge compliment, call attention to it.
Oh, that's a, that's a good point.
And I really liked that.
I also think, so one of the things that you don't want to do in a code review is, 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, but, so what happens if you notice something and you're like, it's a little weird.
It does it.
I'd like to say something about it, but I don't know how to say that.
Um, his comment is to, to have, if you've got a minor thing that you want to comment on, go ahead and sort of tag it.
He, he recommends tagging it with knit in it or a nitpick or something.
Um, just to be clear that I'm, I don't know if I like the word knit, but, 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, just an interesting guideline.
And, I think it can just, I'm kind of, I've been on a kick lately of reading things about community and, 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 a formatting.
Yeah.
And if a lender can tell you, you know what?
There's something wrong with this.
It's just like, let the lender be the bad guy.
Yeah.
It was one of the guidelines that he brought up, which is interesting is, especially with CI and we're pushing a lot of things on black or, or linters that, to wait.
So wait a little bit.
So don't, don't like 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, that peeve of mine, don't comment on it right away.
I might, one of the things I do frequently is I'll create a, a PR, especially for, in a work setting, I'll create a PR.
And then I, 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.
Cause I might, 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, Thomas, how are you?
We're, about to head into controversy because there's been, there's been some discord.
Are you going to bash on something?
Come on.
You're going to bash it over the head with a, like a caveman.
Bash it with Python.
Uh, so partly inspired on the continuation of last week's discussion, you had about running subprocesses 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 bit of boilerplate on top of your bash.
Uh, 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 unset variables.
And if you add the pipe file option, errors won't pass between pipes.
Uh, a pipe will actually fail immediately if there's an error process.
Awesome.
Like it should.
Like it should indeed.
But the point is there's, bash is an old technology and there's a lot of problems here.
And let me add, although this article mostly aims at bash, 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 SSH runtime, at least on any given machine that you're going to be using.
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 about Python, which is so great at automation, it just baffles the mind.
That's a good point there.
You don't have to set up a compiler or any of that kind of business.
I'd say the same thing about Golang.
I mean, 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 of in the last week that you're just bad at bash.
Like if you were better at bash, you wouldn't be complaining about these things, which is not a great reason.
It's 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, especially if you're not on a Windows environment, bash isn't there automatically.
So, and a lot of the team members might not be familiar with it.
So, the thing that, I don't know if he addresses this, the thing that I was thinking about was, we all know Python, if we're programming Python, but we might not all know the automation parts of it.
The way to do like file manipulation or...
Right.
Yeah.
It's 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 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, you know, 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 de-budget 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.
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 pigsty, you've got to do it.
You know, 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, okay, 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, how do I do that?
And just go learn it.
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, you know, 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 off.
And it's like, yeah, look how clever this is.
But it's very hard to maintain.
You know, 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.
Yeah.
Shoes or toilet paper or, like, whatever.
Just because something used to be difficult doesn't mean it needs to be difficult forevermore, 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, you know, have those things for sure.
Yeah.
Funnily enough, we've got immediate feedback to that, which is the author of the original article mentions Shellshock,
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 linteres, 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 this article pointing out how, if you have to, to set up those flags to make it, you know, fail quicker.
Yeah.
Because that helps a lot.
So that's nice.
Yeah.
Yeah, for sure.
And also just to give the author massive amounts of credit, this isn't clickbait.
He didn't position this as never, ever use Bash.
In fact, he explicitly says that, 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...
Oh, yeah, definitely.
Switch to Python.
Absolutely.
Yeah.
And then another quick question, just a quick follow-up.
Have you considered Conch?
I've not even heard of Conch.
I never mind considered it.
So 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#.
Like kind of, but not really.
I suspect it's similar here.
But...
And I know it's supposed to be a pronounced Conch, but my brain says Zonch because it's funner to say.
Zonch.
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 Asgard going on for the logo.
That's nifty.
They do indeed.
All right.
Well, cool, Thomas.
That was a good conversation.
It was good.
So do we have any extras?
Michael, do you have any extras?
You know I got extras, right?
I also, first, real quick follow-up, a real-time follow-up from Henry Shiner in the audience,
that PEP663 was the PEP around Stringenum.
Oh, okay.
And he's not sure if removing the support for that PEP means removing Stringenum 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, right?
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.
No, 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.
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.
Okay.
Let's see here.
So I have been switching so much of my software stuff around.
I've started using Vivaldi.
Now I've been using Firefox for a long time, but I started using Vivaldi, which I think is a really neat take on a browser.
So switched over to Vivaldi and started using that.
There's a bunch of different things.
Like Mozilla laid off 250 people recently.
They're axing the 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 a tactic.
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.
Mike, you said it's a different take on a browser or like, 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 is 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 wanted to try some stuff out from Google Docs over to Zoho for other stuff and for like 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 tried that a while ago.
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'd try and like, ah, I might have to go to Google for this.
You know, several times a day.
No, I don't really.
If I get stuck here, usually I 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 telling a joke.
Thomas, you got anything extra you want to share throughout the area of the world?
Not particularly.
I'm looking forward to your joke.
Give a 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're doing so.
I don't want to shill too horribly.
So I try to keep that to the end.
That's our job.
We only shill.
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.
So, yeah.
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 cybersecurity and using notebooks to track threats and stuff.
Well, has he considered this?
That was in a James Bond movie, right?
It's been several.
It could have been.
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 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 good grip on it.
Yeah, exactly.
There's one zippy move with your arm and you give it a yank and all hundred come out.
This is exactly what.
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.
Like actually the entire 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.
Oh, yeah.
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 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.