Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 145, recorded August 28th, 2019.
I'm Michael Kennedy, and Brian is away on vacation.
Yeah, I was on vacation last week, now Brian's gone.
But don't despair, we have two special guests.
We have Matt Harrison.
Hello.
Welcome, Matt.
And Anthony Sotili.
Welcome.
First time here on the show.
Nice to have you here.
Nice to be on the show.
Yeah, it's great to have you.
I'm looking forward to talking about all these things with you.
Now, before we get on to our topics, let me just say real quickly, the show is brought to you by Datadog.
Check them out at pythonbytes.fm/Datadog.
More on that later.
But I want to focus first on something that's going to help people learning Python or teaching people who are learning Python.
And that's this project called Friendly Traceback.
Matt, you do a lot of teaching.
What is your experience with folks, you know, one of their first programming experiences running into like a traceback crash?
Like, is it really clear for them?
Most of my training is with experienced technologists to understand what a traceback is.
So I do do some with kids in elementary school, that sort of thing.
But my issue is I like the idea here.
But in my courses, I teach explicitly have them hit errors and teach them how to read the traceback and recover them.
How to recover, yeah.
So I like the idea.
The other thing that I have sort of an issue with is that you have to install it, right?
So having someone who's a beginner install something, I don't know.
What do you think about that?
That's an interesting question because you – well, let me tell folks what it is real quick.
So this one comes to us from Jose Carlos Garcia, I think, because his Twitter name is in Elite Speak.
So that's my attempt to understand it back into English.
So thank you, Carlos, for sending that in.
And the idea is it's really aimed at beginners, as you kind of hinted at, Matt.
And let me just give folks a sense of what it is.
So normal traceback will have, like, in reverse order, the call stack.
And then maybe the line of code.
And then the error message, like the error type.
And then possibly the error message, right?
Well, what this does instead is it will catch the exception type, like an index error.
And then it has a little help message and an example, right?
So it says, oh, this is a Python exception.
You got an index error.
That means the list index is out of range in this case.
And this error occurs under these circumstances.
Here's usually what happened.
Here's usually the cause.
And then one thing I really like about it is it first shows the line of code where it happened.
And then it actually shows the local variables.
So like in the example there, it has a function called get last item, and you're passing a list.
And it says the list that was passed was 1, 2, 3.
And then here is actually like three or four lines of code where this error is happening and what the index value was and all that.
So you could actually diagnose this without even stepping into a debugger.
You could just say, oh, I see.
The index is 3, but actually it's 0, 1, 2 by just looking at the output on the screen here.
And that I think is pretty cool.
Yeah.
I think it's definitely useful.
I looked over the documentation.
I thought, this is really cool.
My issue with beginners is how to walk them through something.
And installing is always a pain when they're beginners.
I also, the other thing that's really cool about it is it looks like it has some hooks.
So you can define your own exceptions.
You can customize how you handle those.
So I think that that looks kind of cool as well.
I mean, I can imagine maybe if you're in a environment at work where you have support people.
And they might have to look at your code or look at your servers and take problems and resolve them.
This might be something that could aid them.
Right.
The fact that it catches the local variables in production would be kind of nice.
Yeah.
I think it really comes down to, are you using any external packages?
If there's a pip install or a condo install, right?
You could wrap this up to include friendly traceback, right?
But if you're using none of that, then all of a sudden, yeah, this is like another burden, right?
Yeah.
This actually looks a lot like the pytest tracebacks.
And I sometimes find that those are useful and sometimes not so useful.
Yeah, exactly.
I think it depends.
Like they said that there's a lot of tools to make exceptions better for advanced developers.
This is not that.
This is something else.
One of the things I thought that was cool about this is there's three ways to like integrate
it into your app.
You can install it as an exception hook.
So all exceptions in the application are caught, which is cool because I mean, I knew that that
was possible, but I didn't really, I've never really played.
I'm like, oh, look how easy it is.
You just take a function and assign it to this callback globally and any error will go through
it.
That's cool.
So you can do that at the top of like your startup or your app.
You can actually in a try except block, you know, say, explain friendly traceback explain,
and it'll do that on demand.
But both of those require you changing your code.
You can also use it from the outside.
When you run an app, you can say dash M friendly traceback, then the script file.
And it'll, that way you can run it on code.
That's not modified to be like friendly, I guess.
Unfriendly code.
I don't know.
Anthony, let's wrap this up.
What are your thoughts on this thing?
Looks good.
I'm actually teaching my brother how to program right now.
And he was pretty overwhelmed by the first stack trace that he saw.
And I think if he would have saw something like this, it would have changed his perception
about errors and maybe taught him something more than I had to teach him after the fact.
Exactly.
I mean, yeah, I totally, I think it's awesome.
I really, really liked the idea.
I do take Matt's point as valid as like, it's now a step preceding actually writing code
that they've got to go through.
So depending on how much control you have over their environment, if you can like get this
in place for them, then maybe it's no big deal.
But yeah.
Anyway, worth considering.
Matt, what do you got next for us?
So recently the Pandas developers released the Pandas user survey from 2019.
So this came out last week.
They had a call on Twitter and they had about 1200 responses.
Yeah, that's cool.
I was surprised they got so many folks to participate.
That's really, those are really solid numbers for statistics.
Yeah.
I think we've got a link to the survey there, but some of the things that stood out to me
is that more than half of the people who responded have been using Pandas for less than two years.
Pandas has been out for quite a while now, but it seems to be one of, from what I see,
it's one of the key drivers of growth.
It's just sort of a central component of sort of the data analysis, data science space.
And it looks like they're getting a lot of new users there.
Yeah.
And so, you know, we talked about the incredible growth of Python before,
and a lot of that has to do with this big inflection point where Python was largely adopted,
moved to by data scientists.
Do you think this is like an indicator of that?
Like there's all these new folks coming into the Python ecosystem,
and they're often coming into the data science space.
And so, hence, they haven't been here for many, many years?
Yeah, I think so.
I mean, that's the sexy thing right now, data science.
And it kind of didn't exist before.
So there's a big push for AI, ML, that sort of thing.
But if you look at, you know, the number one tool that data scientists use,
it's often called Python.
And I would say that Pandas is probably the number one tool of those people who are using data science.
Cool.
What else is in the survey?
That was really interesting is they have the numbers of the operating system.
So I sort of geek out on that sort of thing.
But this isn't what I thought I would have thought at all,
because some definitions of data scientists are they're a statistician who uses a MacBook in San Francisco.
Yeah, you definitely do better data science if like the back of your laptop glows.
An Alienware, maybe, but certainly an Apple.
No, I'm just kidding.
Yeah, so the numbers, actually, they have about 60% of their users use both Linux, 60% use Windows and 42 Mac.
So I wouldn't have thought that.
I mean, obviously, those don't add to 100.
So I imagine you've got a lot of deployments on Linux, that sort of thing.
But people tend to forget that Linux sort of rules the enterprise world.
And I think this might be, you know, further indication that Pandas adoption or Python's adoption
is not limited to just startups and people hacking around on their MacBook.
I'm always super surprised by the percentage of Windows users when you consider Python.
And I guess it makes sense because it's really easy to get started with Python on Windows.
But it's the number just blows me away every time.
Yeah, absolutely.
Steve Dower did a great talk at PyCon called Python is OK on Windows, actually, or something like that.
And he had some really interesting...
Yeah, it was really good.
And it had some interesting statistics.
I feel like the Windows Python developers are somewhat in this realm of like the dark matter developers
in that you know they're using it because it keeps showing up in these surveys.
But you go to PyCon and there's many more MacBooks toting around and whatnot.
But yeah, it's definitely a good thing to remember.
And, you know, honestly, Matt, the thing that surprised me most here
is how high Linux is in this group.
Yeah, I imagine that's deployments.
But the other interesting number here is Python 3 percentage.
And Python 3 percentage is 93%.
So legacy Python goodbye there, I guess.
The data scientists move on to the latest and greatest.
Yeah, the data scientists are leading the way with ditching legacy Python.
I mean, the whole Python 3 statement came out of that space, which is pretty cool.
I think that also has to do with less legacy code, as well as the models and the technology are changing so fast.
You don't keep building on the same code.
You're like, forget that.
We're going to go to TensorFlow because this whole thing is slow and wrong, right?
Mm-hmm.
Yeah, like you said, I think they're leading the way.
Well, speaking of Python 3, I think Anthony has something around that as well.
Yeah.
I do indeed.
Yeah.
Let's talk about the Y2K problem that I kind of stumbled upon recently.
The YP3 problem?
Yeah.
Yeah, okay, what is this?
Python 3.8, close to release, and Python 3.9, right around the corner.
There's the question that comes up, which is, what is going to come after?
And we really have two main choices, which would be like Python 3.10 or Python 4.0.
But both of these present problems just because of their version number.
So there's a significant amount of code out there that's using the sys.version and sys.version info variables in the sys module.
Right, and trying to just take that string and go, is there a Python 3 or 2 in here or something like that, right?
Yeah, there's a lot of slicing or checking the first character of that string, and it presents a number of different problems.
The most common one that I've seen is when you access sys.version and look at the first three characters, and that works fine.
It's like 2.7 or 3.6 or whatever.
But as soon as the second minor version of Python becomes 10, you're suddenly reporting Python 3.1 again.
All right, sorry, this doesn't support Python 3.1.
You need at least version 3.5.
You're like, no, it is 3.5.
There's an even worse situation where if you check, even if you're doing it correctly and using sys.version info,
if you only check the first number and only check a quality, so like say sys.version info 0 equals equals 3,
that's a perfectly fine check if you're checking if it's exactly Python 3.
But as soon as Python 4 happens, that condition is going to be false.
And guess what?
You're going to run Python 2 again.
Yeah, some of the maintainability libraries like 6 have this in there, right?
Yep.
Yeah, 6 is broken if you change the version to 4, which is a little scary,
given it's one of the most installed libraries, as we'll see later.
Yeah, well, you know, I guess that makes sense because 6 is not divisible by 4, so it's probably fine.
No, actually, this is really tricky.
You know, it reminds me of Windows 10, right?
Like, if you look at the Windows operating system numbers, we had Windows 7, which was XP,
Windows 8, which was Vista, and then Windows 10.
And the reason they don't have a Windows 9 is exactly this.
Like, so many people were doing substring searches for Windows space 9 for looking for 95 or 98.
And so if they had a 9 that was beyond, you know, Vista or whatever.
Yeah, even Oracle Java had that problem.
Yeah, it's, so they just said, you don't forget it, we're going to 10.
But it doesn't sound like skipping to 4 is going to make this better, probably worse.
I don't know, which do you think is the worst way to go?
I think skipping to 4 is going to be worse.
Most of the things with the 3.10 release will just be, like, slightly broken.
But trying to run Python 2 code in Python 3 is way more broken.
Yeah, for sure.
So I haven't followed this, but I recall, and maybe my memory is just fading me,
that there was talk that there would never be a Python 4.
So has that changed?
As far as I know, that hasn't changed.
I think the jury's still kind of out on that one.
Like, from what I understand, there was talks of, like, Python 4 just being the next version of Python 3.
But I don't think anyone has definitively chosen whether it'll be 3.10 or 4.0 next.
Yeah.
I mean, we're at this crossroads, right?
Guido has expressed a dislike of double-digit second version numbers.
But everyone is tired of this two versus three debate.
We don't want to kick it up a notch, right?
So where do you go from there, right?
We'll just release 3.9.9.9.9.9 forever.
That's right.
Yeah, it'll be fine.
But yeah, this actually is coming up pretty quickly.
So 3.9 will reach beta.
According to the PEP, we'll reach beta sometime in 2020.
And usually when the next version releases on beta, they start developing the version afterwards.
And so we'll start seeing 3.10 in the wild.
But I made a couple easy ways that you can start fixing these problems before they're a problem, I guess.
One of them, I pre-built a version of Python 3.10.
Well, it's actually 3.8, but with a fake version number.
And you can run that directly on Ubuntu today.
And I made a Flake 8 plugin which checks for these common issues called Flake 8 2020.
Nice.
Yeah, that's really cool.
Yeah, it makes it into your...
So does that suggest that you use version info instead?
Yeah, it makes the proper suggestion when it detects which thing that you're using incorrectly.
Cool.
Yeah, super.
And that's great.
Now, before we get to the next one, let me just tell you all quickly about Datadog.
They're a long-term supporter of the show.
And Datadog is a modern cloud-scale monitoring platform that brings all your metrics and logs and distributed traces together.
So basically, it will auto-instrument all the popular frameworks, Django, Flask, Postgres, whatnot.
And you can actually trace your requests and your performance across different service boundaries.
So not just what is your Python code doing or what is your database doing, but like all together in one coherent thing, which is cool.
If you go to a free trial with them, you'll get a cool Datadog t-shirt.
Just visit pythonbytes.fm/Datadog to get started.
Now, Anthony, you had hinted that we may come back to popular packages.
And some folks out of the – I think they're associated with the University of Michigan, but they also have their own consulting project, these two folks.
They did some interesting research on the current state of PyPI.
Now, sometimes people use BigQuery.
You can ask interesting questions like, well, what are the most common user agents downloading from PyPI?
Or what are the most common packages or whatever?
These folks went all in and they downloaded all of the packages from what I can tell.
Like all of them.
And then they started analyzing all sorts of stuff about them.
So they started saying, look, we downloaded 178,592 packages, which has roughly 1.7 million releases and 77,000 contributors.
And they also analyzed something that was pretty interesting is the connections or the interconnectivity or dependency graphs of these various things.
And they found there's 157 million import statements within these packages.
And then, yeah, they just did a bunch of analysis.
This is basically like an academic research paper.
So the thing I'm linking to is actually a PDF.
So, you know, look for a download you're going to get rather than a website they set up.
But, yeah, it's pretty interesting what these guys put together.
What do you see that caught your attention going through this?
I went to their what I read the paper and then I looked at they actually have a GitHub project.
And I wanted to actually pull the data from the GitHub.
But sadly, the data is not there.
It says coming soon because I wanted to do some analysis on it.
Ah, bummer.
So my question is, what do you think is the most common third-party library?
And it wasn't what I thought it would be.
I mean, my guess was just going to be like six because you see that everywhere.
Okay.
All sorts of projects.
Yeah, it's super, super low level.
Yeah, I would have guessed requests.
Yeah, that would have been my guess as well, I think.
But the most common was NumPy, which surprised me.
Those data scientists, they're really dominating.
I don't know.
They definitely are.
Wow.
How interesting.
So certainly, so many of these libraries that are in the data science space do seem to all focus in on NumPy as the foundation, don't they?
Yeah, sort of built around that as well.
Yeah, I wonder how much more commonality there is, like more shared foundation there is in the data science space rather than, say, the web space.
Where you've got Flask, Django, Pyramid, Bottle, Molten, whatever.
And they all kind of have their own foundation.
So that breaks up their potential high radius.
Yeah, yeah, yeah.
That was definitely interesting, NumPy.
I wouldn't have guessed that, but I guess it does make sense.
So some interesting things that I saw was within PyPI, they said they find that the growth of PyPI itself, all the packages, has been robust under all measures.
With an annual compound growth of 47% year over year for the number of active packages.
And 39% for new authors.
And 61% for new import statements.
So I guess that means Python packages are becoming more dependent on each other.
Yeah, that doesn't make sense.
Again, when I'm doing a training, I will go to PyPI, the Python package index.
And I point them at that number.
And I'm at it right now.
And it says 193,830 projects right now.
And I think that's pretty mind-blowing.
But also, like you said, you've got 47% growth in there.
39% for new authors, right?
Yeah, that's incredible.
Apparently, it's somewhat straightforward for someone to come into Python, make a package, and start contributing and sharing it with the community.
Yeah.
I think the new authors is the most impressive stat from there.
Like, it means that people are coming into the community and, like, building stuff for other people, which is great.
That's a really good point.
Yeah, absolutely.
That's a super positive number.
That's really high growth when you're talking about you already have 77,000 authors, right?
Yeah.
Some other real quick stats I thought was interesting.
They have the number of active packages, which is a much smaller number than the total packages.
But in 2005, you could go to PyPI, and you could literally just kind of browse all the active packages.
There were 96.
Yeah.
So in the early days, it was useful to have it, but it was not quite as amazing as almost 200,000 now.
Before PyPI, there's this cheese shop, which I think was the predecessor of that.
And it was sort of a single web page, and it had, like, here are the categories, right?
And so on that web page was the list of packages.
But yeah, this is crazy.
Yeah.
So the cheese shop, you're telling me, is kind of like Yahoo for packaging.
Yeah.
All right.
Final stat from this analysis.
The most popular license for packages in the Python space is MIT.
They've got all the lists, all of them listed there.
That's pretty cool.
All right, Matt, what's this next one?
Speaking of data scientists, you got another one for us.
Yeah.
So speaking of data scientists and sort of, I guess, the proliferation of, Michael mentioned proliferation of web frameworks,
I came across a new project that I hadn't seen before recently called DAPI, D-A-P-I.
DAPI.
And it sort of labels itself as pandas for humans.
And so I just think this is interesting now.
We're going to be able to do that.
And I recall, you know, when Django came out, at that time, there was another popular web framework called Turbo Gears.
And there is sort of a faction in the Python community of like, are you a Turbo Gears person or you're a Django person, right?
And they both sort of had their pluses and minuses, right?
But I think, and Turbo Gears has sort of morphed into what we see as pyramid these days.
But I see that there's been benefit.
I think in general competition is good.
And there's been benefit from that.
This is an interesting library.
It looks like it's sort of is pandas-esque.
It's got portions of pandas in it, but it also has scikit-learn in it, yellow brick, which is a visualization tool for machine learning,
and NumPy as well.
And it says explicitly on there that it's designed for data analysis, not for coders,
which I think that's trying to say that maybe pandas is a little too complicated
and that data analysts maybe need something a little bit more simple than that.
But I think it's interesting that there's now a proliferation and people are using Python.
And maybe they're saying, oh, this, we want to use Python, but we want to use maybe something simpler.
And there's a proliferation there.
Yeah, I think it's super interesting.
One of the things it seems to do is also leverage the simpler startup idea, kind of like you talked about before.
Like a lot of folks say, well, you get started by setting up a Jupyter server and installing, you know, pandas and NumPy and all that stuff.
And one of the things you can do with this is you can have one of these data sheets and you can say show and it will like print out an ASCII representation of the table and stuff like that.
Yeah.
In general, with most software, like a good five minute out of the box experience is really good for bringing someone on.
Right.
It'll be interesting to see what happens to this moving forward, because what I'm also seeing is a lot of new projects are taking the interface from pandas and replicating that.
I mean, you've talked to people who are doing similar things, right?
But like Dask, for example, and stuff like that.
Like Dask.
I was just playing the other day with a library called CUDF.
I don't know how you pronounce that, but basically it's a pandas on top of CUDA.
So you can leverage your GPU to do pandas like operations.
So it'll be interesting to see where that goes.
It looks like in general that the data science community is sort of honing in or adopting the pandas interface as sort of a standard interface.
But, you know, is there room for improvement, room for something more for humans?
I guess that remains to be seen there.
Yeah.
It definitely seems like a lot of flowers are blooming.
Yeah.
Which I think in general is good.
Competition is good.
And, you know, if you only have one tool, you have to use that tool.
Right.
But if there are multiple tools and some are better at certain things, then I think it pushes everyone to be better.
So appreciate the competition there.
For sure.
How do you think a programming library that's not for coders works out?
Yeah.
I'm not sure how to interpret that.
You start by installing friendly traceback and then you go from there.
Yeah.
Good one.
I mean, I also consider Excel a programming environment.
Right.
I think Excel is the most common programming environment in the world.
And lots of people use it.
They won't admit that they're programming.
But, I mean, if you do a VLOOKUP or something like that, you're programming using Excel.
And Google Sheets is a great database.
Yeah.
At some point, I think you have to bite the bullet and learn some syntax.
And so I'm not quite sure how to interpret that statement there.
But friendly interface, Pandas has gotten some slack for some things that might not be super intuitive or not Pythonic in that way.
So whether this is an improvement on that.
Maybe it's a way to graduate to Pandas.
Yeah.
This is your training wills.
Yeah.
Potentially.
Now, I started off this whole conversation by saying we could use this friendly traceback to possibly gather information about crashes on the server because it captures local.
But, Anthony, this next one you've got might take it up a notch, right?
Yeah.
So I'm actually going to talk about Python Remote PDB.
This is intended to be a small over-the-network remote debugger.
It's a very, very thin wrapper around PDB that ships in a single file.
It's really easy to kind of drop into an existing environment and just, like, add it to your path using Python Path.
Or you can pip install if that's easier for you.
It doesn't have all that many features.
There's a bunch of other remote debuggers that are much more powerful.
Things like PUDB or RPDB or PyCharm's debugger or Visual Studio Code's debugger or, like, any of the other things that are brought to the table.
But I found this.
It was pretty simple.
It solved my use case and worked pretty well.
That's cool.
So it integrates with Python's new breakpoint feature, which lets you plug in a new debugger, right?
Yep.
Yeah.
You just set some environment variables.
And any time you call breakpoint in your code, the runtime knows how to import the right module and call the right stuff to call your debugger.
So if you wanted to call remote PDB, you would just set Python breakpoint equals remote PDB dot set trace, and it would just do the right thing.
Yeah.
That's pretty cool.
Yeah.
And the access for this tool is you generally just use, like, Telnet or Netcat or SocketCat or anything that can talk to a socket and basically gives you a PDB session remotely.
I'm actually working on creating my own text editor just so I can learn curses.
And it was really useful to be able to debug a curses application because you can't really enter PDB while it's trying to paint your screen.
Yeah.
That's interesting.
So, I mean, even though it sets up a little server, you don't have to have it be on a different machine, right?
Yep.
Yeah.
I was just developing it in one tab, and I had a debugger in my other tab.
Yeah.
So, in general, anything that's printing to – if you've got something that's printing to the screen or maybe doing input from the screen, that might be a case where this would be more appropriate than the built-in debugging tools of Python.
Yeah.
Another use case might be if you're, like, using a web server, although, like, Flask has nice tools for using a debugger, and Pyramid does as well, and I'm sure the others do also.
But it's a potential tool.
Yeah, that's cool.
Yeah, more tools are good.
Tell folks really quick what curses is.
Curses is a library which allows you to paint kind of graphical user interfaces, but in a terminal.
It's kind of how text editors like Vim or Nano or Emacs draw out their UI.
Or if I wanted to create a game for, like, a BBS.
Oh, yeah.
You can make games with it, too.
I've seen some really good curses games.
Yeah, that's pretty cool.
All right.
Well, that's definitely a good one, and I hadn't heard of it.
So, yeah, thanks for sharing that.
And that's it for our main topics, but I do have a few quick extras I know we all do that I want to share.
I just want to share a story that just made me laugh.
I really love it.
So, there was this – the press calls them a hacker.
I don't really know what this person would be classified as because this is like a pretty low-level hack.
But a person was trying to avoid getting parking tickets, and they assumed that if what they could insert into the field that contains the number for the license plate was null,
the systems like at, you know, the county or whatever is going to give you a ticket, say, oh, there's no address or there's no license plate here, so we can't send them a ticket.
But in fact, quite the opposite is the case.
So, there's this person who got a custom license plate, which you can do in the U.S. and have like words on it, and they got the word null, N-U-L-L, all capital.
And then all of a sudden, all the other places where there actually were nulls in the database started directing to this license plate,
and they got $12,000 in parking tickets without even parking illegally because they started to receive all the failure cases of the database for the parking.
Ah, guess he hacked himself.
Exactly.
I don't know, hackers would take kindly to the naming there, but I don't think it worked out how he wanted it to.
It was definitely a backfire.
Anyway, I'll link into that.
That's pretty funny.
And then just really quick, PyCon 2020 has been sort of officially announced.
It's going to be earlier this year.
I'm trying to figure out exactly.
Yeah, yeah.
It's going to be April 15 to 23 in Pittsburgh, and the website is already up.
So go check it out.
Sign up.
Maybe you can submit a talk.
I'm not entirely sure, but the website at least is already up.
So I'll link to that, and people can check that out.
Matt, what do you got?
I recently released a course on Pluralsight on the XGBoost library.
So XGBoost, if you're not familiar with it, is a library that a lot of people are using with great success in like Kaggle competitions for analyzing structured data and making predictive models around that.
So if you're interested in an in-depth course on XGBoost, not only how to use it, but how to tune it, how to understand what the model is predicting when it comes out, check that out.
I've got a bit.ly link, bit.ly slash PSXGB, Pluralsight XGBoost.
So PSXGB if you're interested in that.
Nice.
Yeah, we'll put the links to the show notes.
Congrats on the new course.
You and I have both written a fair number of online courses, and that's a lot of work.
Yeah, thank you.
Yeah, I'm excited about it.
I think it's a great course for anyone interested in XGBoost.
Yeah, awesome.
Anthony?
Cool.
I've got one quick little library.
This is on the same line as the Curses work above.
I found a tool called Ekate.
I don't know how to pronounce it.
It labels itself as a Selenium web driver, but for the terminal.
And it's kind of a cool library that allows you to control a process in the background and make assertions about it as a testing library.
So are you sending Curses commands, or is that like expect?
So the way it works is it runs a TMux server in the background and then uses the TMux commands to interact with it.
So it'll sound like up arrow or like control X.
Like sends keys, kind of.
Yep, pretty much.
Ah, that's cool.
I can see utility in that for like driving demos and that sort of thing as well.
That's cool.
Oh, yeah, that would be cool.
Yeah, you sit there and it looks like you're typing and you're just flying through it.
And you just get up.
You say, let me show you some over here and it just keeps going.
Feel like.
Yeah.
Yeah, and you could make it understand Emacs.
It could even control Emacs.
Awesome.
Yeah.
Yeah, it works great for Emacs too.
Sweet.
All right.
We always sit in the show with a joke or two.
And this one is not like a laugh out loud sort of joke.
But Matt, you're here.
You do a lot of data science.
I thought I'd bring some sort of scientific-esque humor here.
And I just, this one just really is deeply satisfying to me.
So I'll just, it's a little story.
I'll get you all a reaction in a minute.
So there are two mathematicians sitting at a table in a pub having an argument about the
level of math education among the general public.
Like one of them is defending overall math knowledge.
And he gets up and goes to the restroom.
And on his way back, he wants to prove his point, right?
So he encounters the waitress and says, hey, I'll give you an extra $10 on your tip if you
can answer a question for me.
It doesn't matter what I ask.
Just say the words X squared.
X squared, okay?
She's like, yeah, sure.
No problem.
So a few minutes later, the guy sits back down with his buddy.
He says, I'll bet you $20 that even our waitress can tell us the integral of 2X.
And the cynic's like, yeah, I'll take that bet, buddy.
No problem.
So he beckons her over to the table, asks the question to which she replies, X squared.
And this mathematician begins to go and demand is winning.
And she says, plus a constant.
I don't know why I like that one.
At least she knows.
Yeah, I don't know why I like that one, but it's just satisfying to me.
So yeah.
So on that, brief aside, there was a poll on Twitter the other day whether they should
teach statistics or calculus in high school.
That's an interesting question.
And I said, the only times I've used calculus since high school, even though I much enjoyed
the class, was tutoring other people in calculus.
That's a good career path, by the way.
Just, you know, when you're young.
That's right.
No, I hear you.
But I honestly, if you're going to throw up a math class in high school for the first sacrifice,
geometry.
It's got to be geometry.
Replace that with some computer programming.
Serve as the same purpose.
Logical thinking.
Let's do it.
Awesome.
But yeah, I definitely take your point.
All right.
Anthony, do you have another joke or you want to, should we wrap it up?
I had a Golang joke prepared, but then I panicked.
Whoa.
I would cut that too.
No, no.
Don't worry about it.
It's all good, man.
Thank you, Matt Harrison, Anthony Sotile.
Thank you both for being here.
It's been really great to have you, Matt, back on the show and Anthony here for the first
time.
Yeah.
Thanks for having me.
Yeah.
Thanks guys.
Bye.
Okay.
Bye.
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.