Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 125, recorded April 10th. I'm Michael Kennedy.
And I'm Brian Huckin.
And this episode is brought to you by Datadog. Check them out at pythonbytes.fm.
We'll click the link in your show notes. We'll tell you more about them later.
Brian, first, I want to know how you're doing.
I'm doing really good. We just keep reading these numbers and 125, they just keep getting bigger.
I know. It's pretty incredible, the growth of the podcast.
And, you know, I just want to say thank you to everyone listening because, like, we keep doing it because people care.
They appreciate it. Sponsors are sponsoring the show because listeners are listening.
And it's just great. I love doing it with you. So it's cool that we're still going.
Me too.
For sure. For sure. Okay. Now, I feel like, didn't we just have an XKCD about, like, the whole packaging and dependency management thing?
Yeah. Yeah, actually.
And I feel like we've got, like, requirements.txt. We have piplock. We have piproject.toml.
Probably stuff I don't even know about yet, but listeners are going to tell me now because that's the magic of talking about this in the podcast is,
you mentioned these seven things, but did you know about these three others? Which is amazing.
But here we are again with some more packaging, right?
Yeah.
What's the story?
We've covered piproject.toml, and a lot of times we think about that going with, either going with flit or poetry for packaging.
But it does work with setup tools, too.
So Brian Skin is a friend of the show, and he wrote an article called My How and Why, Piproject.toml and the Source Project Structure.
So if you're using piproject.toml with flit, flit doesn't allow you to use, right now, unless you fork it or something, flit doesn't allow you to use a source directory to keep all of your source in.
But you can do setup tools, of course, and how do you get all of those pieces together?
And so I wanted to highlight this article mostly because Brian put together this article with setup tools and piproject.toml, how to get that working with a source directory.
And then also included how to put his black settings for black within and talks within a toml file as well.
And just all of the pieces, how to make sure, dot all the i's and cross the t's to make sure it works.
That's really cool.
Nice work, Brian.
And Brian Skin, that is.
And yeah, it brings together a lot of the cool stuff we've spoken about already on the show.
So happy to see that.
And so do you know, is piproject.toml, that's like the current new hotness that is like, where is that?
I mean, it's working with setup tools.
That's kind of a big deal, right?
The piproject.toml makes it so that you can, wheels can be specified.
And when you're pip installing stuff, so pip works with it so that when you're installing things, you can tell pip where everything is and how things work.
So that, the toml file is the standard.
Whether you use setup tools or flit or poetry to build the wheel, that's up to you.
Or you can make up your own.
But it's the standard interfaces at the toml interface.
All right, cool.
Thanks for that.
Are you ready to go on an adventure?
Yes.
A multi-threaded dungeon, if you will.
A parallel dungeon.
So as you and all the listeners probably know, I'm a big fan of async, await, parallelism, all that kind of stuff.
But there is the problem, not so much with async and await, but certainly with the threading and other forms of parallelism, of getting your application to a deadlock, having race conditions for things that look like they should be atomic, but they turn out to be multiple steps.
So you could have them interrupted by other threads like x plus equals one, something to that effect, right?
Yeah.
So I ran across this cool little website called The Deadlock Empire, and it's subtitled Slay Dragons Master Concurrency.
Oh, that's great.
So basically this is like a coding game in your browser that you go along and you go through these different challenges.
And so one of the challenges is to just like have two threads hit a lock at the same time.
So one is blocked, waiting for the other to go through, for example.
Another one is to like understand how things that look atomic, like x plus equals one, actually break into like multiple steps and have the threads get in there and like basically call x plus equals one.
But in the end, there's only one more, not two more in the value there.
Things like that.
So deadlocks are really bad news in programs.
They're super hard to debug.
They're not fun, but I think this looks like it could be a little bit of fun.
Yeah.
I'm looking forward to trying this.
And at the end, there's a boss battle at the end.
Boss battle?
That's so awesome.
I haven't made it to the end, so I haven't seen the boss yet.
But yeah, I mean, there's in the show notes, I laid out a simple little example of like how you might end up doing totally normal stuff that ends up with a deadlock in your application.
And, you know, sometimes when your app goes crazy, it's obvious like the CPU level pin 100%, at least on one core.
But in deadlocks, it's just like it looks like your app is not doing anything.
You're like, well, what is it doing?
I don't know.
It's like it's just waiting.
It's super frustrating and challenging.
So I like this little game to help people explore this idea.
If you're teaching concurrency, it seems like a really cool thing to show your students.
And it just seems fun.
Are you able to deadlock with async and await?
Well...
I guess you could if two things are waiting for each other.
The challenge with async and await, it's tricky, right?
Like normally you're doing threads.
You're actually doing parallelism.
I mean, you have the GIL.
But of course, if you do anything with a network, you can kind of split that up and still run into this problem.
But with async, by default, in Python, it all runs on a single thread.
Okay.
Right?
You have an async event loop.
You go to there.
You say create, get event loop.
And then you queue up work to run on there.
And then it interlaces in like coroutine style with the await keyword.
But it doesn't actually run at the same time in multiple threads.
So you wouldn't really run into it with like a re-entered lock.
But if you use the regular non-re-entered version, you could.
So not really.
But the problem that you can run into is you can still get into the challenge of where you have corrupted data.
And you need effectively some kind of lock.
So it gets to be pretty tricky, actually.
And I don't think it's really well addressed or well laid out in the async and await world.
Not in Python where it's on one thread.
But yeah, this is cool.
It's fun.
All right.
I don't even know how to transition to this next one.
You just take it.
What are we doing with cog here?
Well, Ned Batchelder of Coverage fame and others, great guy.
He just released an update to a little tool he's got called cog.
And so there's a cog 3.0.
And I'll just read what he says.
Cog, it's a small tool that finds snippets of Python within text files or within any, could be a Python file or another program file.
But within files, executes the Python snippets and then inserts the result back into the file.
It's kind of a bizarre little thing.
He says it's good for adding a little bit of computational support to an otherwise static file.
But it hadn't been supported for a few years.
I mean, it worked, but it hadn't had any updates.
But he just recently updated it, moved it from Bitbucket to GitHub, added Travis and AppVeer continuous integration, a bunch of other changes.
One of the things that's kind of fun is you added mutt-mutt mutation testing.
I've never heard of mutt-mutt.
I've heard of hypothesis.
Well, yeah, it's completely different.
So mutation, well, we should cover it another time.
But briefly, mutation testing is running your test suite and then randomly changing something about your source code and then running your test suite again and making sure that it fails.
So if you can randomly change your code and your test suite still passes, well, then there's problems with your test suite.
It doesn't cover enough.
Right, right.
Because changing your code should have some sort of outcome.
Yeah, especially things like switching the like a less than operator to a greater than operator or something.
Right, right, right.
So one of the things that he commented on, which I've still been thinking about how to, a place to use this because it's a neat little tool.
But he said as a part of the sentence was, now I use it for making all my presentations.
So if you had your presentations in Markdown and you had a little Python snippet, you can have the output of the snippet put somewhere else in the same presentation.
That's very cool.
Yeah, that's quite cool.
Yeah, anyway.
Yeah, you know what it reminds me of?
The sort of like Jupyter Notebooks for static files before Jupyter Notebooks or something like that.
Yeah.
Without all the dependency of like a proper notebook, right?
It can just be like, you said like a Markdown file or a text file.
But, you know, the output can kind of like appear under the code listings live.
And there's people doing wacky things like generating test functions with it or sticking it in C code to generate headers for things and all sorts of stuff that is going on with this tool.
Oh, yeah.
How interesting.
It's like almost a code gen, right?
Because if it can change static files, it can change source files.
Yeah.
Cool.
All right.
Well, that's very cool.
Thanks for sharing that.
Let me share a little bit about Datadog before we get to the next one, which is a doozy.
So this episode, as many of them are, brought to you by Datadog.
And so thank you to Datadog for keeping us going strong.
Datadog is a monitoring and analytics service that takes all of your metrics and logs and distributed traces and puts them in one place.
So it auto instruments things like async libraries like async.io and frameworks like Django and Tornado and helps you visualize your app performance even across boundaries.
So if you have like microservices and database stuff and all that going on, which a lot of us do, you can like get a view of a single request across all that, which is pretty awesome.
So get started for free with a 14-day trial at pythonbytes.fm/Datadog and get a cool t-shirt as well.
So definitely recommend them.
And they're a big support of the show.
So thanks to that.
Yeah.
Thank you very much.
Are you a developer?
I am a developer.
I've been surveyed.
Have you been surveyed?
Yes.
I always take the Stack Overflow.
Wait, I don't know if I do this.
Yeah.
Stack Overflow survey.
I usually do the Python.
Is that the same one?
This is a different one.
Okay.
But they're both good and they both have good things to say about Python.
They just have a different focus a little bit.
So I am a huge fan of the Stack Overflow developer survey.
I do kind of like voting.
I see it as like my civic duty in the community to go and fill this thing out when it comes out.
Because it really is the best view, I think, of the state of developers and technology that's out there, that I've seen anyway.
So the big news is the survey was a while ago, but the results and the analysis are out.
And would you be surprised, Brian, to hear there's good news for Python in here?
Well, I'm hoping.
Is there?
Yeah.
There definitely is.
So there's a lot of good news.
Last year, we spoke about the incredible growth of Python, which is a data science report done by Stack Overflow,
talking about how it's shooting towards the top and just blow past all the other languages.
Well, that is now moving forward.
We're one year into that trend, and it's definitely looking like it.
So we've already seen a popular language fall victim to Python in a sense of it's not as popular.
So I guess a couple things that call out about this that are interesting.
One is there's a lot of gender and equity focus in this report, like much more than there has been in the past.
I would say, especially at the beginning, they talk a lot about that.
And there's a lot of analysis you can read into.
I'll have a few comments on it, but not too much.
Let's start with, I have about like six or seven little topics I pulled out that I think are worth covering in this format.
So one is they ask people, do you contribute to open source?
And they learned that about 65% of professional developers on Stack Overflow contribute to open source projects at least once a year.
That's pretty good, right?
Yeah.
Yeah, higher than I was expecting.
Yeah.
I mean, you would say like, of course, well, everyone should.
But, you know, everyone's busy.
Maybe they don't have a project they're skilled in, right?
They work at a place they're not allowed to.
So 65%, that's over half.
That's pretty good.
They also broke it out by language that said developers who work with Rust, WebAssembly, and Elixir contribute to open source at the highest rate,
while those who work with VBA, C#, and SQL do so at the lowest rate.
Sorry.
So take that to mean what you want.
Yeah.
I haven't seen a lot of VBA open source projects lately.
Oh, yeah.
That killer macro.
It's out there.
That macro framework.
All right.
Yeah.
I mean, some of it just doesn't really lend itself so much.
So this one has to do kind of with that equity thing, which you spoke about this before when you talked about getting a job or growing in your career,
which was a really interesting thing you covered on the show.
And this one was under the title of competence and experience.
And they have a graph that basically graphs imposter syndrome year over year broken out by gender.
Oh, wow.
Which is pretty interesting.
Okay.
Yeah.
So we talked about resumes before and how men are more likely to apply when they're half qualified.
They're like, I don't really have all these things, but hey, I know this part of it really well and I'll learn the rest.
So forget it.
I'm applying to this job.
And women more, you know, statistically speaking, are more likely to wait until they have all the requirements met before they'll jump in and throw their name in the hat.
Right.
Yeah.
Kind of the same thing here in this graph.
So the idea is how experienced do you judge yourself to be?
So do you feel like you're a very qualified developer?
You're still kind of a newbie, whatever, things like that.
So they found that the curve for qualified self-assessment of men is much higher, especially white guys, I think, much higher than for women.
So regardless of the years, like if they have the same amount of experience and stuff, which I think is also just kind of like touching on the same difference, right, for better or worse.
So I think that's pretty interesting.
But on the tech side, we've got the programming and scripting and markup languages.
And I told you that another language falls victim to Python.
Well, Python is ranked fourth as the most popular programming language, but it doesn't really count because two of those are HTML and like SQL,
which nobody can go write a whole app in HTML or a whole app in SQL.
Like it's a complementary thing you use alongside like real languages.
So if you factor those out, there's JavaScript, Python and Java.
And it used to be JavaScript, Java, Python.
So that switch where Python now edges out Java as the second most popular actual programming language.
So that's pretty cool, right?
Yeah.
It'll be great when Java is just gone.
So we don't have this confusion of Java, JavaScript.
You know, what's so ironic is you're talking about like this language.
That was developed in like 10 days to throw a little scripting onto a web browser.
Netscape, I think.
And then only grab the JavaScript name because Java was hot at the time.
Displacing Java, right?
That's kind of rough.
But no, it's true.
It's totally true.
But funny.
All right.
So databases, if you talk about popular ones, it was MySQL, Postgres, Microsoft SQL Server, SQLite, and MongoDB were in the top five.
And then I love the dreaded and loved and wanted things, right?
What language is dreaded?
What database is loved and so on?
So for languages, we have the most loved is Rust and Python.
The most wanted is Python and JavaScript.
And the most dreaded, ties in our opening statement, VPA and Objective-C.
So what do you think?
Does that sound right to you?
Yeah, definitely.
Right on.
People programming Objective-C because they have to.
Yeah, I mean, even if you're doing iOS stuff, Swift at least.
At least.
There's other options as well, but Objective-C is a funky one.
All right.
In terms of loved databases and wanted, so the most loved is Postgres.
Most wanted is MongoDB.
Development environments, they have a graph of like who's using what.
Oh, my gosh.
Visual Studio Code is crushing it.
It's like 50% and then everything else.
Wow.
Which Visual Studio Code is only a couple years old.
So that's a pretty big deal.
And then finally, one thing I want to point you at.
I want to point people at is this thing that says how technologies are connected.
So there's a really cool graph there.
And if you go there and you find Python and you follow the graph out, it seems like it makes a lot of sense to me.
It seems like, yeah, these other technologies are often used together with Python.
And it's pretty cool.
All right.
Well, that's the survey.
I'm linking to the whole survey and people can go check it out because there's a lot to it.
And these are just some of the interesting bits I decided to pull out for us.
Yeah, I'm definitely going to check this out.
Looks neat.
Yeah, it's a cool one.
All right.
Earlier, you mentioned mutt-mutt and mutation testing and changing your code.
And the fact that if you can change your code, especially things like less than to greater than on some kind of test, that should make a difference.
And the problem was you didn't have potentially code coverage.
Well, this next one that you found is going to help us with that, right?
Right.
So actually, I've been using the coverage.py and usually with pytest a lot lately, actually, to make sure.
I kind of mostly do it to find out where there's absolutely no coverage, which files have no, like nothing on them.
So I can make sure I can make sure I can do it.
I think I'm covering an API to definitely make sure that I really am.
But a lot of the visualization, so I, the visualization coverage itself will output, you can tell it to output an HTML file.
And that's what I often use to go look, look at things.
But some people, and sometimes it's me, like the command line a lot.
So this is, we're going to cover a tool called, it's C-U-V apostrophe N-E-R.
Is it like Covner?
I think it's, I would say Covner, yeah.
Covner.
Covner, kind of like a, like governor with an accent or something.
Like a southern governor.
Yeah.
So it's pretty cool.
It like does these graphic visualizations of your coverage, but in a terminal window.
And for better or worse, I'm still trying to learn how to interpret them.
But at the very least, it's pretty cool.
It's worth trying out.
But it also does more than just the coverage graphs.
It'll also highlight, you can do diffs, coverage diffs, to figure out where you have problems with your, which lines of code need changed or need more coverage.
So it'll be fun to try to play with it and work it into a workflow to be able to avoid popping up in the web browser for the coverage report.
Yeah, it's cool.
It has a nice, it's like basically a nice visualization in ANSI terminal graphics, right?
And with little like histograms of what's covered and what's not covered and so on for your code.
I like it.
Yeah.
You know, I definitely, as people know, a fan of PyCharm and the tools for visualizing stuff in there is really great.
But if you were for some reason like logging into some kind of continuous integration or some reason you run it where you don't have it, this seems like a cool tool to bring into play.
Yeah.
Or if also some people like me go through days where I try to avoid using the mouse at all.
That's a good goal.
This next one is something that a couple of people have asked for.
And I did have this as just an extra item I was going to throw out there.
But I thought it might be fun to dig into it because some listeners have asked for it.
So big news is I had just launched a set of mobile apps for my training site.
That's so cool.
Yeah, thanks.
So you can go into your Android tablet or your phone or whatever and go to the Play Store and find the app, download it, run it.
It's a truly native app.
It works really well.
But they've asked like, hey, could you tell us a little bit about this app?
Like, how did you build it?
Like, show me how you did that in Python.
Well, sadly, it's not in Python.
I wish it were in Python.
We talk all the time about wouldn't it be better if we had better GUIs in Python?
But it's not.
So the story is basically I built this app along with another developer named Georgie.
Did a great job.
Did most of the work on the mobile side of things in C# and Xamarin, which I guess takes me back to some stuff I did long ago.
But, you know, I looked around.
I tried so many different things.
Ionic frameworks.
I could do it in JavaScript.
I looked at some of the Python options, and they just didn't seem like they were going to cut it for, like, truly mobile native stuff.
So I built all the mobile apps in C# and Xamarin, and all the back end stuff is Pyramid, MongoDB, Python, of course.
So that's pretty cool.
What's also cool is we have about 90% code share between the iOS and the Android version.
So make a change in one almost always applies to the other platform, which is pretty cool.
Yeah.
Because they both compile down to native apps, which is pretty fun.
So, yeah, I thought it was a pretty good experience in the end.
And, yeah, I wish I could have built it all in Python, but, you know, that's just the way it goes sometimes.
Can't do it all in Python, I guess.
Not yet.
I'm actually okay with having a multi-language environment.
I'm too.
I just would rather be able to stick to one.
I mean, I guess I can understand the appeal of the Node.js folks wanting to just have JavaScript everywhere except for that it's JavaScript.
But it's all right.
So, yeah, it came out pretty good.
And I definitely, you know, if people are thinking about mobile apps, recommend it.
It seems pretty well.
I built everything on my Mac except for the prototype.
So I guess the way it worked is I built out a prototype on Windows as a Windows app.
Then used that to develop all the back-end APIs that are in Python and Pyramid and get that all just working fine.
And then I went to a place called TopTal, and they help you find developers, which is pretty cool.
So I found Georgie there.
I'll tell you more about that in a sec.
But I found Georgie and gave him my C# code and a bunch of specs, and he turned that into a couple of mobile apps with a little tiny bit of help from me.
So almost all the work went to him on that.
But it was a pretty good workflow to build out with some technology I know and give it to someone else.
It really helped that to drive the back-end services and stuff.
So it was like maybe five weeks from start to finish, which is pretty short for a real app, I think.
Yeah, cool that you had the demo or kind of a Windows prototype already done.
Yeah, exactly.
Because it was C#.
It factored it, you know, just copied over to the Xamarin project, and it just kept going.
So anyway, I had a pretty good experience with TopTal.
If people want to check it out, I have put a referral link in there.
That will give me a little bit of credit if you actually sign up.
So you could sign up as somebody who wants some work or somebody who wants to hire somebody.
If you use that link, it'll help support a new feature for my app.
Redirect that money, that credit back into more development.
It should be cool.
So try the apps out at training.talkpython.fm/apps, and you get two free courses.
They're free on the site, but they surface specifically in the app.
We don't have the iOS version out, but we'll have it out soon.
And I guess one more comment is, man, people who work on devices and app developers, you have my sympathy.
Right?
And there are so many wires and so many devices on my desktop here, or on my desk, like my actual desk.
It is upsetting.
Did you try all the app on a whole bunch of devices?
Yeah.
I had to go.
I was only doing iOS stuff, right?
I had my iPad and whatnot, but we did a lot of work on Android.
So I had to go buy all these Android devices, and now they're everywhere.
And then the whole interaction with the app store.
Oh my gosh.
If anyone works at Google and has, say, over the app store approval process, it was downright, I don't know what's the right word here.
It was very disrespectful and very, very bad.
For example, like the app description says something to like, take the great courses at Talk Python training.
It's one of the best ways to learn Python online.
Something to that effect, right?
Yeah.
The app was immediately rejected because they said, you're trying to impersonate an app called LearnPython.
Okay, so maybe an automated system did.
It's fine.
I'll talk to the people.
No, it was days of conversation to convince them, no, I'm not impersonating an app called LearnPython.
Python is knowledge that can be learned.
It is not a thing.
It is a activity that you can also do here.
I mean, and it was like eight days of stuff like this.
It was really, really, it was bad.
So anyway, finally got through that, got able to launch it.
Super fun.
So, you know, some people ask, like, give them the background of how the apps were created and whatnot.
So that's the story.
Okay, cool.
Cool.
Yeah, well, that's it for all our main items, even the one that got promoted app from the extras.
But what else you got to talk about?
You got a cool little project you finished up for us, right?
Yeah.
I mean, this is actually a long while ago.
Both of us have Patreon pages set up so people can help sponsor the show and promote it for both Talk Python and TestingCode.
And we've had people ask us for that for Python Bytes.
So it is now up.
We were just being lazy and not putting it up, and now it's up.
There's a link in the show notes, but essentially it's patreon.com slash Python Bytes with just all one word.
Yeah, that's cool.
Thanks for putting that together.
Yeah, you know, we have had these Patreons both for our individual, personal, private podcasts or single-person podcasts.
But I think it's cool to have one for Python Bytes.
If people want to support it, they can go there.
You know, even a dollar a week, it doesn't seem like very much.
But in the end, you know, it totally adds up.
On our personal or solo efforts, we have them both set up on a per episode.
This one, I think I've set it up as a per month.
So you can do as little as a buck a month.
It'll help out.
Yeah.
Yeah, that's super cool.
Also, there's a link in the episode pages now to that as well.
I updated the site today.
Sweet.
Cool.
So speaking of sweet, every year I'm always super excited to go to PyCon.
So much fun.
Going back to Cleveland.
Yes.
You're going to be there, of course, yeah?
Yep.
Ohio.
Yeah.
So this year we're doing a special booth.
We had a booth last year and we had our own little booth.
But we're trying something different this year.
We'll see how it goes.
I think it's going to go well.
We're doing a partnership with JetBrains and you and me and a bunch of other folks who are doing really cool stuff.
Dan Bader from RealPython.
The PyBytes guys.
Some other creators.
And trying to do like a sort of Python community creator thing in this big booth.
So we'll be at the booth every now and then.
We're going to have a theater at the booth.
So we'll have little mini presentations during the expo times.
We'll have like some desks where we can do like little private office hours and get togethers, little tables.
So be sure to check us out somewhere around the JetBrains booth.
We won't be there all the time, but much of the time.
Yep.
It'll be fun.
Yeah.
I've already got some cool presentations in mind for that little theater thing.
So hopefully, hopefully that works well.
Yeah.
So we opened this whole show with XKCD, right?
Let's round it out with it as well.
Okay.
So there's a cool thing.
This is a blog post by Jake Vanderplass.
And then some examples from somewhere else, which came to us on recommendation from Tim Harrison.
So thanks, Tim.
And it's XKCD plots in Matlib.
Have you seen this?
In Matplotlib, brother?
Yeah.
I think it's totally fun.
It's so fun.
It's like, yeah, it's really, really cool.
So if you were going to create graphs and plots like in the style of XKCD, well, now you just go into Matplotlib and you can just tell it to do that.
But where is the setting?
Yeah.
I don't know.
I don't see exactly where to set it real quick.
But anyway, you just go in there and you say, you know, plot this.
And it literally looks like this cartoony style, which seems like fun and silly.
But also, I think sometimes when you're trying to not be overly scientific, you're trying to just make a rough point.
Sometimes that style can be really helpful.
Yeah.
And it has that look like you just wrote it with a pen or something like that.
Yeah.
I love it.
I'm going to use it for serious stuff because I'm that kind of a person.
That's awesome.
You totally should do all your weekly reports and XKCD plots.
We have like graphs for our like defect reports and pass fail test results and stuff like that.
I totally want to get that in XKCD form.
Yeah.
Awesome.
So another quick one, the Euro SciPy 2019 conference was announced.
It'll be September 2nd to 6th in Bilbao, Spain.
That's pretty awesome.
I would definitely go if I were nearby.
I don't know.
Maybe I'll still go, but no plans at the moment.
But anyway, if you're anywhere near there and you want to go, that I'm sure is going to be a great conference.
And then the last thing, a friend of mine, Llewellyn Falco, actually turned me on to this, you know, this summer.
I wasn't, I don't know, it's this winter actually.
This thing called font ligatures for coding.
Have you heard or seen these things?
Yeah.
I don't like them, but tell me more.
All right, I'll tell you and you can tell me why you don't like them.
So basically there are certain fonts and the one that I'm linking to and the one that I've been using the last couple of months called Fira Code, F-I-R-A Code, is the font.
And it supports what are called font ligatures.
And these are off by default in your editor.
Probably even if you select the font, it probably won't show these.
But you can turn it on.
You can turn on PyCharm.
You can turn it on in Visual Studio Code, things like that.
And it will take the actual characters you type and reinterpret them as what you would think of them as.
So for example, if you say exclamation mark equals, it replaces that with an equal sign with a slash through it, like not equals from math.
Okay.
And if you say double equals, it has like just a regular equal sign, a little bit longer.
But if you say triple equals, like from JavaScript, where you do an equality test, it'll actually put three vertical lines, like exactly the same for math.
And arrows connect.
And greater than is like the greater than sign you learned in elementary school, where it's like a greater than, and then like a little slanty equal thing at the bottom.
Oh, yeah.
For greater than equal.
Yeah.
So it takes a little bit to get used to.
It doesn't actually change the code at all.
There's a cool little comparison at the bottom where it says Fira Code and Fira Mono, right, side by side.
And it shows you all the different things that it does and whatnot.
So it doesn't actually change your code file to double equal slash.
It just shows you a different view of it.
So if you hit backslash on a double, you know, like a double equal or, you know, not equals, it'll just turn into the not sign, like the exclamation mark.
So anyway, it's pretty fun.
People can try that out.
And I actually have grown to really like it.
Okay.
But you don't like it?
No, it's not my code.
That's not what I type.
It's what you meant, though.
It's what you meant.
Only if I spent that much time in math.
Yeah, that's probably true.
Yeah.
Okay.
Yeah, it's pretty funny.
But the thing that I think is cool is it doesn't actually change the source file.
So you don't have to like impose it on your team.
You can just impose it on yourself.
Yeah, right.
Or as a good joke on somebody who was left their computer foolishly unlocked.
But I will try it.
I like it.
It takes it to get used to, but I like it now.
Yeah, cool.
I feel like we should, as usual, like round this out with a good joke.
Or at least a joke.
Okay.
We can't promise it's good.
No, that's subjective.
But we can promise it's something that we perceive to be a joke.
Okay.
All right.
Hit me.
First one.
When your hammer is C++, everything begins to look like a thumb.
Your thumb, mostly.
Yeah.
That's awesome.
I love it.
And this is one of my favorites.
I don't know if we've covered it already.
Why don't jokes work in octal?
I don't know.
Because 7, 10, 11.
Okay.
If that one just totally passed by you, I'm going to make it even less funny by explaining it.
So it's from the joke of why is 6 afraid of 7?
Because 7, 8, 9.
But 8 and 9 in octal is 10 and 11.
Okay.
Yeah, that's good.
But whenever we tell us the 7, 8, 9 joke, my youngest daughter always follows that up with,
well, why did 7, 8, 9?
Because he was trying to eat three square meals a day.
Perfect.
Anyway.
How about you?
I love it.
All right.
I got one real quick one here, which I feel like actually.
See?
You're already laughing, right?
It's good.
Yeah, yeah.
It's good.
So because you're a Vim user.
A lot of people are Vim users.
But Vim is like voodoo black magic keyboard stuff that happens.
And it's really cool when you know it.
But every now and then you're like, why can't I select that word or whatever?
So the joke is, I've been using Vim for a long time now.
Mainly because I can't figure out how to exit.
It's perfect.
All right.
Well, let's leave it there.
Thanks, everyone, for listening, as always.
Yeah, thank you.
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.