Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 191, recorded July 14th, 2020.
I'm Michael Kennedy.
And I'm Brian Okken.
And welcome, special guest Ines.
Hi.
It's great to have you here.
So I want to kick this off with a cool IoT thing.
Now, IoT and Python, they've got a pretty special place.
Because when I think about Python, I think of it as not being something that sort of competes with assembly language and really, really low level type of programming for small devices.
But, you know, amazing people put together MicroPython, which is a reimplementation of Python that runs on little tiny devices.
And we're talking like $5 microchip type devices, right?
Have either of you all played with these?
No.
No, I haven't.
But I've been seeing a bit of this from my brother.
So he's pretty amazing.
Like, he's a bit younger than me.
He's an event technician.
And he recently taught himself programming and everything just so he can build stuff on these, like, tiny raspberry pies.
And, like, I don't know.
He's doing super advanced stuff.
It's been really interesting to see him learn to program.
And he's also, he's incredibly good.
He has, like, amazing instincts about programming, even though he's never done it before.
But, like, so I've been kind of watching this from afar.
And it made me really want to build stuff.
So I'm very curious.
Yeah, I've done the CircuitPython on some of the Adafruit stuff.
Exactly.
So I always just want to build these things.
I'm like, what could I think of that I could build with these cool little devices?
I just, in my world, I don't have it.
Maybe if I had a farm, I could, like, automate, you know, like, watering or monitoring the crops.
Or if I had a factory.
But I just don't live in a world that allows me to automate these things.
Do you have pets?
Maybe you can build something for pets.
We generally don't have pets.
But we are fostering kittens for the summer.
So I could put a little device onto one of the kittens, potentially.
GPS tracker.
Yeah.
So in general, you have to get these little devices, right?
You've got the US PyCon.
We got the Circuit Playground Express, which is that little circular thing.
It's got some 10 LEDs and a bunch of buttons and other really advanced things like motion sensors and temperature and so on.
Probably the earliest one of these that was a big hit was the BBC Microbit, where I think every seventh grader in the UK got it.
Some grade around that scale got one of these.
And it really made a difference in kids seeing themselves as a programmer.
And interestingly, especially women were more likely to see programming as something they might be interested in in that group where they went through that experience.
So I think there's a real value to work with these little devices.
But getting a hold of them can be a challenge, right?
You've got to physically get this device.
That means you have that idea of I want to do this thing and then I have to order it from Adafruit or somewhere else and then wait for it to come.
And my experience has been I'll go there and I'm like, oh, this is really cool.
I want one of these.
Oh, wait, no, it's sold out right now.
You can order it again in a month.
Right.
So getting is a challenge.
And also, if you're working in a group of, say, like you want to teach a high school class or a college class or something like that, and you want everyone to have access to these.
Well, then all of a sudden, the fact that maybe it costs $50 wasn't a big deal.
But if it's $50 times 20 or 100 kids, then all of a sudden, well, maybe not.
So I want to talk about this thing called Device Simulator Express.
So this is a plug in or extension or whatever the things that I think is extensions that VS Code calls them that makes VS Code do more stuff.
And it's a open source free device simulator.
So what you can do is you just go to the Visual Studio Code extensions thing and you type device probably is sufficient, but device simulator express.
And it'll let you install this extra thing inside of VS Code that is really quite legit.
So it gives you a simulated Circuit Playground Express, a simulated BBC Microbit.
And the most impressive to me is the clue from Adafruit, which actually has a screen that you can put graphics on.
So really, really cool way to get these little IoT devices with Circuit Playground, Circuit Python.
So Adafruit's fork of MicroPython on there.
What do you guys think?
See that picture?
Look how cool that is.
Yeah, so you can write Python in one tab and then just have the visualization in the other.
That's pretty cool.
Yeah.
Yeah, exactly.
And it's very similar to, say, what you might do with Xcode and iPhones, where you have an emulator that looks quite a bit like it or what you would do on the Android equivalent.
I actually think this is a little bit better than the device because it's actually larger, right?
Like the devices are really small, but here's like, you know, you could be like a huge thing on your 4K monitor with a little clue device.
So you can simulate Circuit Playground Express, BBC MicroBit, and the clue in here.
And we just say new project, and it'll actually write the boilerplate code for the main.py or code.py or whatever it's called that the various thing is going to run.
And like you said, Ines, on one half, it's got the code, and the other half, it has the device that you can interact with.
I was thinking that a couple of cases that would be great is, like you were saying, trying to get a hold of it.
But you might not even know if the concept that you're going to use is really going to work for the device you're thinking of.
So this would be a good way to try it out, to try out whether the thing you're thinking of trying for your house or whatever would actually work for this device.
The other thing was, yes, you brought up education and that it's big.
I was thinking about a couple of conferences where they tried to do the display and try to have a camera or something.
Yes.
Sometimes it works and sometimes it doesn't.
This way you could just do a tutorial or in a teaching scenario and everybody could see it because it's just going to be displayed on your monitor.
Right.
Your standard screen sharing would totally work here.
That's a good point as well.
And it doesn't have to be all or nothing.
Actually, what's really interesting is this thing isn't just an emulator, but you can do debugging.
You can set like a breakpoint and like step through it running on the device simulated or you can actually run it.
If you had a real device plugged in, you can run it on there as well and then do debugging and breakpoints and stuff on the actual device.
So it's like you tested here.
I always admire people who actually use like the proper debugging features.
I know VS Code has like so much of this and I'm always like I should use this more, but I'm like, okay, print.
Print, print.
Yeah.
There's some really cool libraries that will actually do that.
I can't remember what it's called, but Brian and I recently covered one that would actually like print out a little bit of your code and the variables as they change over time.
It was like the height of the print debugging world.
It was really, really cool.
I wish I could remember.
Do you remember, Brian?
No, we actually covered a couple of them.
I know.
That's a problem.
We cover thousands of things in here.
So another thing that's interesting is like, okay, so you see the device.
Some of them have buttons and they have lights and you can imagine maybe you could touch the button, but they also have things like temperature,
gyro meter type things or like you moving it or motion sensing or even like if you shake it,
this thing has little ways to simulate all that stuff.
So you can like have a temperature slider that freaks it out and says, hey, the temperature is actually this on your temperature sensor and so on.
So all the stuff that the devices simulate are available here.
Oh, that's cool.
Yeah.
So I actually had the team over on Talk Python not long ago.
So people can check that over at talkpython.fm.
And yeah, I'm also really excited about what you got coming here next, Brian.
What is that?
Yeah.
Well, speaking of, I guess, debugging versus test.
We didn't really talk about testing.
Anyway, I'm really excited.
We should have talked about testing.
Yeah.
So I was just, I was thinking it.
I was thinking that, that I hardly ever use a debugger for my source code, but I use a debugger all the time when I'm debugging my tests.
I don't know.
It's just something different about it.
But I've been running a lot of tests and debugging a lot of tests lately because pytest 6, the candidate release is out.
Now, by the time this episode airs, I don't know if the release candidate will be released or just the release candidate still.
But it's, you can install it, we'll have instructions in the show notes, but essentially you just have to say 6.0.0 RC1 and you'll get it.
So there's a whole bunch of stuff that I'm really excited about.
There's a lot of configuration that you used to be able to put in lots of places in your pytest Any or your setup config or tox any or something.
pytest 6 will support pyproject.toml now.
So if you jumped on the Toml bandwagon, you can stick your pytest configuration in there too.
There's a lot of people excited about the type annotations.
So the 6.0 is going to support type annotations.
So it actually was a lot of work.
There was a volunteer that went through and added type annotations to a bunch of it, especially the user facing API.
And why this is important is if you're type checking, you're running mypy or something over your source and everything, your project, why not include your tests?
But if pytest doesn't support types, it doesn't really help you much.
So it will now.
So that's really, really cool addition.
What this is basically the API of pytest itself is now annotated with types.
Yes.
And well, a lot of the internal code as well.
So they actually went through and did a lot.
There was a lot of work.
And if you look at the conversation chain, it went on for, it was a month, several month project.
Wow.
What does that mean for compatibility?
Does that make pytest like 3.6 only and above?
I think the modern versions of pytest really already are 3.6 and above.
I'm not sure about that.
Right.
So then the door was open to use that because otherwise it would cut.
I mean, it would be a weird move to like release a completely new version with Python 2 backwards compatibility.
Like that's like, you wouldn't do that.
Right.
I mean, it's, it's, I think, well, I think the message it sends, it's like not great.
I totally agree.
Totally agree.
There is a pinned version of pytest.
I don't remember which one it is.
That is still supports 2.7 if you're on it, but no new features are going in there.
The thing I'm really excited about is the, is a, is a little flag they've added called no header.
So don't use this.
Most people don't use this.
When you run pytest, it prints out some stuff like the version of Python, the version of pytest, all the plugins you're using, a bunch of information about it.
All this stuff is really important for logging.
If you're, if you're capturing the output to save somewhere or do a deep, a bug report or something, that information is great to help other people understand it.
What I don't like about that is that it, it's not helpful if you're writing tutorials or if you're writing code to put on a slide or something.
All that extra stuff just takes up space and it distracts.
Yeah.
Like I've had students say, like, I ran it, I think pytest in PyCharm and it has like some kind of output just stating where it is and what it's doing.
They're like, this didn't work for me.
I'm like, well, that was just random output from the tool.
You're not actually supposed to try to run that part.
You know what I mean?
But it's, it's, I mean, I saw why they saw that.
But at the same time, like the ability to just say like, these details don't matter in the longterm.
Yeah.
So I'm, I'm excited about that to trim it down.
There was a plugin called TLDR.
Too long.
Didn't read.
But it, it actually didn't take enough of the header off than I wanted.
So I had my own tool that would do this, but now I've got this, which is great.
So a lot of the configuration, there is a chance for human error if you type something wrong and you type a variable name wrong.
And so I really like this new, a new flag called strict config, which will throw an error.
If you have the pytest section of your configuration has something that it doesn't recognize.
And it probably is just, you've misspelled some variable or something.
Yeah, that's good to know.
And then not too, I can't remember the version, but it was, I think it was in pytest 5.
They added some code highlighting stuff that.
Yeah, that's super cool.
I discovered that just the other day.
I like just somehow updated all my dependencies in some environment and suddenly pytest output was colored.
And I was like, whoa, this is amazing.
Yeah.
The syntax highlighting.
I love it.
Nice.
But there's times where you don't want that, I guess.
Oh yeah, sure.
Yeah.
So there's a new flag to turn it off.
And then a little tiny detail that I really like is the diff comparisons on pytest are wonderful,
but apparently they didn't do recursive comparisons of data classes and adder classes, but now they do.
So that's neat.
There's a whole bunch of new features, there's fixes.
I ran through some of the features I really liked.
There are deprecations and it's a large list of breaking changes and deprecations.
That's why they went to a new number, pytest 6.
But I went through the whole list and I didn't see anything that was like, oh, that's going to stop me.
I'm going to have to change something.
Okay.
That's good to know.
Like, I mean, if you say, oh, there was nothing that like we're using, I feel confident that maybe there's nothing in my code either.
And I knew that somebody was going to ask, is my pytest book still valid?
Yes, it is.
I'm going through it right now.
I haven't gone through the whole thing yet to make sure.
The side that is not compatible is not the book.
The book's fine.
It's, I have a plugin that now is broken.
So pytest check still works.
But if you depend on X fail, pytest, this is a, wow, this is a corner case.
But if you depend on pytest check and the X fail feature of it, it doesn't work right now.
So I'll have to fix that.
So you would say X fail fails temporarily?
Yeah.
It actually marks everything as a pass.
So if you mark X fail.
Oh, wow.
That's like X fail-ception.
Yeah.
It's really bad.
Anyway, I'll have to get back to that.
Yeah.
This is really exciting that pytest 6 is out.
Super cool.
I know that there were some waves, some uncertainty in the ecosystem.
So it sounds like that got ironed out.
Things are going strong.
New versions coming out.
I even saw that Guido had tweeted the announcement, retweeted the announcement and said,
yay, type annotations coming in pytest.
Of course, he's been all about type annotations these days.
We'll come back to that later in the show, actually.
So Ines, I know you work a lot with text, but are you frustrated with it?
What's the story of this name here?
Oh, my point of the day.
Yeah.
Text attack.
What does text attack?
What else about it?
I thought I'd present something for my space, obviously.
Yeah.
Awesome.
Yeah.
There's this new framework that I came across and it's called text attack.
Yay.
And it's a framework for adversarial attacks and data augmentation for natural language processing.
So what are adversarial attacks?
You've probably, you might've actually seen a lot of examples of it.
For instance, an image classifier that predicts a cat or some other image, even though you show it complete noise and you somehow trick the model.
Or you might've seen people at protests wearing like funny shirts or masks to trick facial recognition technology.
So really to trick the model into, to like, you know, not recognize them.
Or the famous example of Google Translate suddenly hallucinating these crazy Bible texts.
If you just put in some complete gibberish, like just gah, gah, gah, gah.
And then it would go like, the Lord has spoken to like the people, stuff like that.
That's amazing.
I include a link to an article by a researcher who explains like why this happened and shows the example.
But it's, it's pretty fascinating, but I think it all comes down to like the fundamental problem of like, what, how do you understand a model that you train?
And what does it, you know, what does it mean to understand your model?
And how does it behave in situations when it suddenly gets to see something that it doesn't expect at all?
Like gah, gah, gah, what does it do?
And the thing with neural network models is you can't just look at the weights.
They're not linear.
They're like, you know, you can't just look at what your model is.
You have to actually run it.
And so the, that library takes the tack that lets you actually try out different types of attacks from the academic literature and different types of inputs that you can give a model to see whether it produces something that you're like not happy with.
Or that's like really weird and exposes some problems in your model.
And it also lets you then, because normally what's the goal?
The goal is, well, you do that and then you find out, oh damn, like if I suddenly feed it this complete nonsense or if I feed it Spanish text, it like goes completely in the wrong direction and suddenly predicts stuff that's not there.
And if you, you know, if you deployed that model into like a context where it's actually used, that would be pretty terrible.
And, you know, there are much worse things that can be happening.
So you can also create more robust training data by like replacing, replacing words with synonyms.
You can swap out characters and just, you know, see how the model does.
So I thought that was very cool.
And yeah, I thought in general, I think adversarial attacks, it's a pretty interesting topic.
And yeah.
Yeah, it's super interesting.
So the idea is basically you've trained up a model on some text and for what you've given it, it's probably working.
But if you give it something you weren't expecting, you want to try that to make sure that it doesn't go insane.
Yeah, exactly.
And it can do, it can expose very unexpected things like the Bible text, for example.
That sounds really bizarre when you like first hear it.
But one explanation for that would be that, well, especially it happens in low resource languages where, you know,
we don't have much text and especially not much text translated into other languages.
But there's one type of text that has a lot of translations available and that's the Bible.
And so they're parallel corpora where you have one text, one line in English, one line in Somali, for example.
And then people train their models on that.
But one thing that also is very specific about Bible text is that some Bible text has some words that like really only occur in a Bible text.
But it uses some really weird words.
So what your model might be learning is if I come across a super unexpected word that's really, really rare, that must be Bible.
And also, also the objective is you want your model to output a reasonable sentence.
So the model's like, well, okay, you know, if that's the rare word, then the next word needs to be something that matches.
And then you have like this bizarre sentence from the Bible, even though you typed in ga ga ga.
And that happens.
Yeah, how funny.
Yeah.
So it looks like they have actually a bunch of trained models already at the text attack model zoo, they call it, I guess.
Yeah.
Everything's called the model zoo.
Yeah.
And so you can just take these and run it against it, like the movie reviews from Rotten Tomatoes or IMDb or the news set or Yelp.
And just give it that kind of data and see how it comes out, right?
Exactly.
Yeah.
I think that's pretty cool.
And yeah, and then you can actually, you can also generate your own data or load in your data and generate data that maybe, you know, produces a better model or like covers things that your model previously couldn't handle at all.
So that's the data augmentation part.
Yeah, that's all very important.
And I think it's also very important to understand the models that we train and, you know, really try them out and think about like, what do they do and how are they going to behave in like a real world scenario that we care about?
Because, yeah, the consequences.
Right.
Because as soon as you're making decisions on this data, right?
Yes, of course.
On these models.
Yeah.
I guess as soon as a human is convinced that the model works and they start making decisions on it, right, that could go bad if the situation changes or the type of data.
And especially if the model is bad, like I'm always saying, like, well, people are always scared of these dystopian futures where like we have AI that can, I don't know, know anything about us and predict anything and works.
But the real dystopia is if we have models that kind of don't work and are really shit, but people believe that they work.
That's much more.
It's not even about whether they work.
It's about whether people believe it.
And then, you know, that's where it gets really bad.
And yeah.
Yeah.
And that's way more likely.
Yeah.
Yes.
It's a more difficult world to test this sort of stuff to figure out.
What does it mean for a model to be bad?
How do you tell if it's bad?
And models can be both working with some data sets and produce gibberish with or, yeah, I guess in this case, the reverse, not produce gibberish if you pass in gibberish.
Yeah.
Actually, yeah.
I just realized it ties in very well with the pie test point earlier and just like, yep.
Machine learning is quite special in a way that it's code plus data.
Code, you can test, you can have a function and you're like, yay, that comes in.
That's what I expect out.
Easy.
Write a test for it.
You know, it's not that easy.
Testing is hard, but like fundamentally, yeah.
It's somewhat deterministic.
Yeah.
Right.
And even if it's not, there's like something you can, you know, test around it and it's much harder with the model.
Yeah.
Yeah, for sure.
All right.
Before we get to the next item, just want to let you know this episode is brought to you all by us.
Over at Talk Python Training, we have a bunch of courses.
You can check them out.
And we're actually featured in the Humble Bundle that's running the Python Humble Bundle right now.
So if you go to talkpython.fm/humble2020, you can get $1,400 worth of Python training tools and whatnot for 25 bucks.
So that's a pretty decent deal.
And Brian, you mentioned your book before.
Tell people about your book real quick.
Yeah.
So Python Testing with pytest is a book I wrote and it's still very valid, even though it was written a few years ago.
The intent was the 80% of pytest that you will always need to know for any version of pytest.
And I've had a lot of feedback from people saying a weekend of skimming this makes it so that they understand how to test.
It's a weekend worthwhile.
Yeah, absolutely.
And Ines, you want to talk a little bit about Explosion just to let people know?
Yeah.
So, I mean, some of you who are listening to this might know me from my work on Spacey, which is an open source library for NLP and Python, which I'm one of the core developers of.
And yeah, that's all free open source.
And we're actually just working on the nightly version or the pre-release of Spacey 3, which is going to have a lot of exciting features.
I might also mention a few more things later on.
And yeah, so maybe that's already going to be out by the time this podcast officially comes out.
Maybe not.
I don't want to overpromise.
But yeah, you can definitely try that out.
And we also recently released a new version of our annotation tool, Prodigy, which comes with a lot of new features for annotating relations, audio, video.
And the idea here is, well, once you get serious about training your own models, you usually want to create your own data sets for your very specific problems that solve your problems.
But often the first idea you have might not be the best one.
It's a continuous process.
You want to develop your data.
And Prodigy was really designed as a developer tool that lets you create your own data sets with a web app, a Python backend.
You can script.
That's our commercial tool.
That's how we make money.
And it's very cool to see a growing community around this.
So yeah, that's what we're doing.
We have some more cool stuff planned for the future.
So stay tuned.
Yeah, people should check it out.
Actually, you and I talked on Talk Python 202 about building a software business and entrepreneurship.
You had a bunch of great advice.
So people might want to check that out as well.
Do you actually know these episode numbers by heart?
Or did you look that up before?
Some of them I know, but that one I used the search.
Okay.
I remember you were on there.
I remember what it was about, but not the number.
I just put together that I know two people from Explosion.
So that's interesting.
Yeah, it's Sebastian.
Sebastian.
Yeah, he was on your podcast recently, which I feel really bad.
I wanted to listen to this because he advertised it with like, it will tell the true story
behind his mustache, which I really wanted to know.
But then I was like, I'll need to listen to this on the weekend.
And I forgot.
So yeah, if he's listening, I'm sorry.
I will definitely, I need to know this.
So I will listen.
Excellent.
So don't spoil it.
Do a great work on FastAPI.
All right.
Speaking of people that have been on all the podcasts as well as Brett Cannon, he recently
wrote an interesting article called, What is the Core of the Python Programming Language?
And he's legitimately asking as a core developer, what is not the maybe lowest level, but what
is the essence, I guess, is maybe the way to think about it.
Oh, wow.
I only just got the core, core pun.
Like it did not occur to me when I first read the article.
I'm really, I feel really embarrassed now.
To be fair, English is not my first language, but still, it's not about that.
Anyway, sorry for interrupting.
When I first read it, I was thinking like, okay, we're going to talk about what is the
lowest level.
And yeah, okay, it's probably C and C eval.h, C eval.c and so on.
But really the thing is, Brett has been thinking a lot about WebAssembly.
And what does that mean for Python in the broad sense?
He and I talked about it on Talk Python.
I think at the very last PyCon event, we did a live conversation there about that.
And it's important because there's a few areas where Python is not the first choice, maybe
not the second choice, sometimes not even the 10th choice of what you might use to program
some very important things like maybe mobile, maybe the web, the front end part of the web,
importantly, I mean.
So there's a few really important parts of technology where Python doesn't have much reach, but all
of those areas support WebAssembly these days, right?
And if you have something in C, you can compile it to WebAssembly.
So there's some thought about like, well, what could we do potentially to make a WebAssembly
runtime for Python so that Python magically almost instantly gets access to what was just JavaScript
front end frameworks space and what is mobile, iOS and Android and all those things allow you
to directly run JavaScript as part of your app?
So how would we make that happen?
So it's pretty important, right?
If we could solve that problem, like Python is already so popular and its growth is so incredible.
Like what if we could say, oh, yeah, and now it's an important language on mobile and it's
an important front end language framework like that would just take it to the next level or
maybe a couple levels up if you do them both.
And WebAssembly seems to be one of the keys to kind of bridge that gap, right?
So Brett talks about in this article how for so long we've just had CPython is what we
think of when we have Python.
Sometimes people use PyPy, P-Y-P-Y, as a partially JIT compiled version, sometimes faster version
of Python, but not always because the way it interacts with C, libraries that you might be
using through packages and so on.
And really, it's a lot of Python's dynamic nature makes it hard to do outside of an interpreter
where, to be clear, WebAssembly is a compiled language, right?
So if you're going to put it over there, maybe it's going to require it to be compiled.
So this is a really interesting thing to go through and read and think about with Brett.
He talks about things like, well, how much of the Python language would you have to implement
and still consider it to be valid Python?
Like we talked about MicroPython and usually don't people look at, they don't look at that
and go, that's not Python.
That's fake, right?
No, like it's Python, but it's not as much Python, right?
You don't have the same, all the APIs on MicroPython as you do on regular Python.
So questions like, do you still need a REPL?
Could you live without locals, right?
The ability to ask what the local variables are and so on.
So he said he didn't really have a great bunch of, a great answer.
It's more of a philosophical, like we need to solve this.
But I do want to share some of my thoughts on this.
And I feel like maybe what we could do is we could come up with like a standard Python
language definition that is a subset of full Python, right?
Here's the essence.
Like, okay, we have to be able to create classes.
We have to be able to create functions.
You have to define strings.
Probably you want type annotations.
But do you need a vowel?
Maybe, maybe not.
Right?
So like that, if you could have a subset of the language that was smaller, as well as the standard library, because do you really need to like parse CSS hex colors?
Everywhere?
Probably not.
It's a very underused part of the library, but it's in there.
Right?
So if we could narrow it down, maybe it would be easier to think about how does it go to WebAssembly?
How does it go to like some kind of JavaScript runtime or something like that?
And if it sounds crazy, you know, the .NET people did this.
They have a .NET standard class library language.
They got it running on WebAssembly.
So it's, there's an example of it out there and something that's kind of sort of similar.
Right?
So I think this would just open stuff up if you could get Python in these places.
What do you guys think?
Initially, I was never so sold on WebAssembly until, and especially WebAssembly and Python until I watched Dave Beasley live code a compiler at PyCon India, I think it was.
And I was like, oh, this is kind of, this is kind of fun.
And I mean, it was just also fun to watch Dave Beasley live code a compiler.
Yeah, for sure.
Classic.
But so that did get me thinking.
I do think one question I think we should ask ourselves is like, well, do we really, do we really need Python to do all of the things in the browser?
Like, is this really, does this really have a benefit that like actually makes a difference?
A, B, there are a lot of things people use Python for that just wouldn't work in that way.
And that's also, I think, part of what makes Python so popular in the first place.
Like, for instance, you know, all the interactive computing environments.
That's why people want to use Python for data science.
Yeah, I Python, Jupyter Notebooks, that sort of stuff.
That's why, you know, Python as a dynamic language made so much sense to people.
And that's what made it popular.
And large scale processing, like a lot of the type of stuff we're working on.
It's like, yeah, there's stuff that you can run in the browser, but it's never going to be viable to run large scale information extraction in the browser because you want to run that on a machine for like a few hours.
But I think there are a lot of opportunities also in the machine learning space for privacy preserving technologies that already exist.
I think from what I understand, Mozilla is working on some features built into the browser, where, you know, you can have models predicting things without it being sent to someone's server.
And I think that's obviously very powerful.
That's an interesting idea.
Right.
Yeah.
Because if you could have a little bit of machine learning.
Yeah.
But you don't have to give up the data privacy aspect of it.
That's pretty cool.
Yeah.
So I think for that, there's a lot of potential here for running Python in a browser.
Yeah.
Well, we start getting used to saying what is Python is what is the CPython implementation.
And we got to remember CPython is the reference implementation for the language spec.
And I think, I guess we're kind of getting at maybe we need to split it up and have a, like a core language spec and an extended one or something.
I don't know.
The, where would you divide the line?
Because we've seen, like you said, we've seen things like CircuitPython and, and other things.
And we've actually talked about several smaller languages based on Python that just try to be the same syntax.
But at which point is it, when is it not Python anymore?
And there's at least some of the stuff.
Like I could totally see having a distribution of Python that doesn't have a REPL still count.
I could totally see not having idle, for instance.
If something doesn't ship with idle, is it still Python?
I think so.
And because of idle, then you need Tkinter and, or you need TK stuff in there.
And there's a lot of stuff that maybe I would be in like, you know, could you live without locals?
Most of the time, probably.
I actually think this would be since the web and since mobile is so, such a big part of our lives.
And it will be for a while.
This might be a decent dividing line to say whether or not it's for WebAssembly or not.
Maybe we should split the division at whatever we need to implement a WebAssembly version of Python.
And anything above that line is an extended version of Python or something.
Yeah.
Yeah, that's a good point.
All right.
I don't want to go too long at this section because I want to make sure we get the others.
But I do want to leave you with just some thoughts.
What if shipping Python was just shipping a single binary and a thing that ran it?
You could do that with WebAssembly.
Maybe two WebAssemblies, the runtime plus the code.
What if all the browsers had capability to plug in alternate runtimes through WebAssembly?
So right now you have a JavaScript engine.
But what if, like, say, Firefox and Edge and whatnot came up with a way to say, here's a WebAssembly API to plug in alternate runtimes, Python, Ruby, .NET, Java, you name it, and then shipped with the latest version of each of those runtimes.
So you just don't have to download.
Like, the big problem now is you can do it, but you've still got to download, like, 10 megs per page, which is not a good idea.
So anyway, I think there's a ton of interesting things that open up if this were possible.
So I'm glad Brett's still on this, and hopefully he keeps thinking about it.
Brian, I still need to learn Pathlib.
Really?
You got any ideas on how I do that?
Really?
You're not using Pathlib?
I'm just stuck in the OS.path world.
I just really need to get with the time.
Help me out here.
Okay.
So Pathlib is where...
I mean, I know the value.
Yeah, you're like some kind of animal, like OS.path.
So I have no offense to OS.path.
But, you know.
No, I really love Pathlib a lot.
But there is...
I got to tell you that the documentation for Pathlib doesn't cut it as an introduction.
You can find what you're looking for, but if you know what you're looking for.
But I agree with Chris May.
So Chris May wrote a post called Getting Started with Pathlib.
I guess it's kind of...
He's got a little PDF field guide that you can download, but he has a little bit of a blog
post introducing it.
But I downloaded it.
It's like nine or ten pages.
And it's actually a really good introduction to Pathlib.
So I really like it.
The big thing with OS.path versus Pathlib is Pathlib creates path objects.
So there's a class that represents a path that you have methods on.
And it makes it different for when you're dealing with this.
With OS.path, it's just strings.
So it's manipulating strings that represent paths.
So the object's different.
I like it.
Actually, I switched just for the ability to add buildup paths with just having the slash operator.
Yeah, it's really interesting how they've overridden division.
But I think it's a good example of where this makes sense.
It's a reasonable use case.
It looks good.
It's defensible.
There are other cases where you're like, oh, did you really have to overload these operators?
But they're fine.
I think that's very valid.
Yeah.
And things like how do you find parts of a path?
When you have to parse paths, that's where Pathlib really shines for me.
So if you want to find the parent of something or the parent of the second level parent,
there's ways to do that in Pathlib.
And in OS.path, you're stuck with trying to split things and stuff.
And it's gross.
I mean, there are operations to do it.
But it's very good to have this relative, I don't know, just all these operators, like parent.
And then one of the things that it took me a while to figure out was I was used to trying to find the absolute path of something.
And in Pathlib, finding the absolute path is the resolve method.
So you say resolve and it finds the absolute path for you.
You can find the current working directory.
You can go up and down folders.
You can use globs.
You can find parts of path names and stuff.
And it's just a really comfortable thing.
So I think you should give it a whirl.
And it's not like it's going to change your life a lot.
But the next time you come up with, when the next time you're programming, you're like, okay, I got to figure out, I got to have a base directory and some other directory.
Well, I'll reach for Pathlib instead of OS.path.
Yeah.
I guess it has been there since 3.4, so I should give it the times.
Yeah.
So, I mean, now, before I could see the objection of, like, oh, you have to backport it.
And also, I think what I like as well is a lot of integrations that, like, you know, automatically can perform checks where the path exists, stuff like that.
Or for me as a library author, you know, you're writing stuff for users and you want to give them feedback.
And, for instance, in a library like Click or Typer, which is the modern type hint version CLI interface, which was also built by my colleague, Sebastian, you can just say, hey, this argument is a path.
What you get back from the command line is a path.
It will check that a path exists via Pathlib.
So it does, like, you know, a whole bunch of magic there.
Yeah.
That is super cool.
Yeah.
Or you can say it can't be a directory.
And then you write your CLI, user passes in an invalid path, and you don't even have to do any error handling.
It will automatically, before it even runs your code, say, nope, that argument is bad.
So that's pretty cool.
That's awesome.
And you don't have to care about Unix versus Mac or PC or something like that.
Yeah.
I mean, Windows.
I mean, no offense to Windows, but it's always handling paths and Windows is always the classic story.
Also, as a library author, where you just, well, we're supporting all operating systems.
But, like, well, Windows just does it a bit differently.
And you cannot assume that a slash means a slash.
Yeah, for sure.
All right.
Well, the final item is yours, Ines.
And it's definitely interesting.
So if you're working in the machine learning data science side of things, it might not be enough to just back up your algorithms and your code, right?
Yeah.
You also have, yeah, machine learning is code and data.
So, yeah.
So this is something we discovered a while ago and that we're now using internally.
Internally, so we currently, as I mentioned before, we're working on version three of Spacey.
And one of the big features is going to be a completely new optimized way for training your custom models, managing the whole end-to-end workflows from pre-processing to training to packaging and also making the experiments more reproducible.
You want to train a cool model and then send it over to your colleague and your colleague should be able to run the same thing and get the same results.
Sounds really basic, but it's pretty hard in general in machine learning.
So our Spacey stuff will also integrate with a tool called DVC, which is short for data version control, which we've started using internally for our models.
And DVC is basically an open source tool for version control, specifically for machine learning and for data.
So, you know, you can't really, you can check your code into a Git repo as you're working on it, but you can't just check your data sets and models and artifacts into Git or your model weights.
Like that's, so it's very, very difficult normally to keep track of changes and your files.
You kind of, most people just end up with this directory of files somewhere and it can be very frustrating.
And so you can really, you can think of DVC as Git for data and the command line usage is actually pretty similar.
So like you type Git in it and DVC in it to initialize it.
And then you can do DVC add to start tracking your assets and add them.
So it's like, I think if, yeah, if you're familiar with Git as like abstract, it can be at times, you will also kind of find it easy to get into DVC.
And it basically lets you track any assets like data sets, models, whatever, by adding meta files to your repository.
So you always have like the checksum in there and you always have these checkpoints of the asset, even though you're not actually checking that file into your repo.
And that means you can always go back, fetch whatever it was from your cache and rerun your experiments.
And it also builds this really cool dependency graph.
So you can really have these complex pipelines with different steps.
And then you only have to rerun one step if some of the inputs to it have changed.
So, you know, in machine learning, you'd often have pipeline, like you start, you download your data, then you pre-process it.
Then you convert it to something, then you train, then you run an evaluation step.
And everything sort of depends on each other.
And that can make things like really hard.
And you never know, you usually have to run everything, you know, clean from scratch.
Because, yeah, if something changes, your whole results change.
So if you set up your pipelines with DVC, it can actually decide whether something needs to be rerun.
Or it can also know what needs to be rerun to reproduce exactly what you're trying to do.
So that's pretty cool.
Yeah, that could save you a ton of time and money if you're doing it in the cloud.
Yes, exactly.
Yeah.
And, you know, you can share it with other people.
It's like, it's, I think it definitely solves a problem that's very real.
And, yeah, the people making DVC, they've also recently released a new tool that I have not personally checked out yet.
But it looks very interesting.
It's called CML, which is short for Continuous Machine Learning.
And that's really more of the CI, which kind of is logically the next step, right?
You manage everything in your repo.
And then you obviously want to run automated tests and continuous integration.
So the previous looked really cool.
Like it showed kind of a GitHub action where you can submit a PR with like some changes to your code and your data.
And then you have the bot commenting on it and it shows like accuracy results and a little graph and how stuff changes.
So it's really like these code coverage bots that you've probably seen where like you change some lines and then it tells you, oh, coverage has gone up or down and, you know, the new view of your code.
So that's what it looks like.
So I think, yeah, I'm really excited about this.
And definitely it solves a problem.
It's already been solving a problem for us.
And yeah.
How does it store the large files?
I know it has this cache.
Is that a thing that you host?
Does it have a hosted thing that's kind of like GitHub?
I'm not sure if you could.
You probably connected to some cloud, but like normally you have that locally.
It also has a cool thing where you can actually download files via the tool.
And then depending on where you're fetching it from, if it's a Google storage bucket or S3 bucket or something, you can actually also tell if the file has changed and whether it needs to be redownloaded.
And so, for example, internally, what we're doing is we're mounting a Google storage, Google cloud storage bucket or however they call it locally as like, you know, so it's like kind of a drive you have access to locally.
And then you can just sort of type GS, blah, blah, blah, blah, and then the path and really work with it like a local file system.
And that's pretty nice.
So you can, you know, you can have, you can work with private assets because the thing is a lot of toy examples assume that, oh, you just download a public data set and then you train your model and then you upload it somewhere.
But that's not very realistic because most of the time the data you have can't just go in the cloud publicly.
So, yeah.
But yeah, I think I don't even know exactly how it works in detail, but like it can basically tell fetch, I think from the headers or something, it can tell whether the file you're downloading has changed and whether there's something new.
Yeah.
With a normal version control, one of the reasons we use it is to try to find what's different.
Can you do, do you do diffs on data or?
I don't know.
Maybe.
I mean, I'm not sure if there's, I think the main diff is more like around the results that you get because diff, I mean, diffing large data set, diffing weights, you kind of can't.
That's really where we are.
The other problem where like you need to run the model to find out what it does and then you're diffing accuracies rather than weights.
Okay.
I don't know if it does like actual diffing of the data sets, but often the thing that changes is really the models.
Like you have the, you know, you have your whole data and then you change things about your code.
Yeah.
And something changes and it's, you want to keep track of what it is or how it manifests.
Yeah.
It's really cool to see them working on this.
Yeah.
So, and also we'll be in, in Spacey 3.
We'll hopefully have a pretty neat integration where, you know, if you want, it's not like mandatory, but if you say, Hey, that's cool.
That's how I want to manage my assets.
You can just run that in your, in a Spacey project and then it just automatically tracks everything.
And it, you know, you can check that into Git and share it and other, other people can download it.
So that's, yeah, I'm pretty excited about that.
It works pretty well so far.
Yeah.
Everything you can do to make it a little easier to work with Spacey and just make it reproducible.
Yeah.
And it's just, the things are hard.
Like there is, I'm not a fan of these all one click, everything just magically works.
Like it looks, it looks nice and it's a nice demo, but like once you actually get down to like the real work, like things need to be a bit modular.
Things need to be customizable.
Otherwise you're always hitting edge cases or you have these leaky abstractions.
So yeah.
Yeah.
I think things should be easy to use, but you can't just magically cover everything by just providing one button.
That's just not going to work.
Yeah.
Cause when it doesn't work, it's not good anymore.
Yeah, exactly.
All right.
Yeah.
All right.
Well, that's our six items that we go in depth into, but at the end, we always just throw out a couple of really quick things that maybe we didn't have time to fit into the main section.
And I want to talk about two things that are pretty exciting.
One is if you care about podcasts as a catalog of a whole bunch of things, I don't know how many podcasts there are.
There's probably over a million podcasts these days.
One of our listeners, Anton Ziyanov wrote a cool Python package that will let you search the iTunes directory and query it.
And it's basically a Python API into iTunes podcasting directory.
You know, some people think that you've got to be part of the Apple ecosystem to care about iTunes, but really that's just the biggest like directory kind of Yahoo circa 1995 style of listing of podcasts.
So if you care about digging in and researching podcasts, check that out.
That's pretty cool.
And then, yeah.
And then I've also, I'm such a big fan of f-strings.
How about you too?
Yes.
F, yes, right?
Yeah.
I'm finally, I'm finally working in like Python three only.
I remember, I think last time I was on the podcast, I was basically, I was saying how like, oh, all these modern things, they're so nice.
I wish I could use them more, but we're still supporting Python two, but like, no, everything I write now, 3.6.
Yes.
And I've talked previously about a tool called Flint, F-L-Y-N-T, which lets you run against an old code base and convert all the various Python two and three styles of formatting magically into Python three.
I think that was actually really nice.
The episode I was.
Yeah.
You might've been right.
Like, I wish I could run this.
Right.
Yeah.
And yeah, I ran that against like 20,000 lines of Python.
I found like just a couple errors reported them.
They got fixed.
So that's nice.
But the thing that's bugged me endlessly about f-strings is I'll be halfway through writing the string and I'm like, oh yeah, I want to put data here.
So I got to go back to the front of the string, not necessarily back to the front of the line, but maybe back to like the string is being passed to a function.
So I go back to the first quote, put the F, go back forward and then start typing out the thing I actually wanted.
Right.
Or maybe I'll F string something.
And when I really, I, oh, I'm not going to put data.
Right.
So it's like you're halfway through and you want it to become an F string.
Well, PyCharm is coming with a new feature where if you start writing a regular string and pretend like it's an F string, it'll automatically upgrade to f-strings.
Yes.
Halfway through.
Yes.
Without leaving.
So you just say curly variable.
It's like, oh, okay.
That means that's an F string and the F appears at the front.
Yes.
Nice.
So that is pretty awesome.
Anyway, those are my two quick items.
Ines, I'm also excited about the one you got here.
Yeah.
This is awesome.
Yeah.
I had one, which is something coming to 3.9 or in 3.9, which is PEP 585.
And you can use, when you use type annotations, you can now use the built in types like list and dict as generic types.
So that means no more from typing import list with a capital L.
Yes.
So you just literally, I mean, when I first saw it, I'm like, that looks strange.
But like, yes, I'm so excited about this.
It probably, it'd be years until I can just like use it all across my code bases because.
True.
Yeah.
But like, yay.
That's in 3.9?
Yeah.
That's in 3.9.
I'm already using 3.9 and I didn't know that.
You can do this.
Yeah.
And Guido is one of the guys on the PEP making this happen.
Like I said, he's really into typing.
Oh, that's great.
So this is really cool because it was super annoying to say, oh, you have this new import
just because you want to use type annotations on a collection.
Right?
Now you don't have to.
And there's actually a bunch of the collection stuff and iterators and whatnot.
Like the, you know, the collections module, like that, a bunch of stuff in there is really
nice.
And they're compatible, like lowercase list of str is the same as capital list of str, I believe.
All right, Brian, what you got?
Oh, I just wanted to, I'll drop a link in the show notes.
Testing code 120 is where I interviewed Sebastian Ramirez from Explosion also.
And talking about FastAPI and Typer because I'm kind of in love with both of those.
They're really cool.
Yeah.
Absolutely.
All right.
Well, that's a cool one.
Definitely going to check that out.
And you can find out why he has the cool mustache.
That's right.
All right.
So we always end the show with a joke and I thought we could do two jokes today.
So I think, Ines, do you want to talk about this first one?
Oh, yeah.
I mean, I'm not even sure it counts as a joke per se, but like it's more of a humorous
situation, I guess.
Yeah.
It ties in.
Well, it's Sebastian again.
Like he had this very viral tweet the other day where he posted about some experience.
I can just read it out because I think it needs to kind of stand on its own.
So he's right.
I saw a job post the other day.
It required four plus years of experience in FastAPI.
I couldn't apply as I only have 1.5 plus years of experience since I created that thing.
And then he says, maybe it's time to reevaluate that years of experience equals skill level.
And this was like, it resonated with people so much.
I was actually surprised to see like everyone was like, oh, yeah, HR.
Like apparently this seems to be this huge issue, obviously, that like, well, not most job ads
not written by the people who actually work with the technologies and where you have.
Yeah.
Actually.
Yeah, this is awesome.
And this tweet actually just got covered on DTNS, the daily news tech show, daily tech news show.
I guess it is.
Alongside another posting that said you needed eight years of Kubernetes experience for another job.
But of course, Kubernetes has only been around for four years.
Yeah.
When you say this went viral, it had 46,000 retweets and 174,000 likes.
That's like, that's got some traction.
I feel like this might be a problem.
Yeah.
I was surprised that like so many people are like, yeah, that's a big deal.
And it's like, and I mean, it is true.
Like kind of tech hiring sort of seems to be broken.
And it's also, it's like, it's a bit different in my case, I guess.
But like, I don't qualify for most roles using the tech that I write.
And in some cases that's justified because I'm not a data scientist just because I write developer
tools for data scientists doesn't mean I can do the job.
But in other cases, I'm like, there's kind of a ridiculous amount of arbitrary stuff you're
asking for in this job ad.
Maybe that's needed.
Maybe not, but like it centers around like a piece of software that I happen to have
written and I do not qualify for your job ad at all.
Like the last time I wrote a job description, I intentionally left off the college degree
requirement because all of the other requirements I was listing in there, either they had it from
college plus experience or they had it just from experience.
So I was fine with that.
By the time it actually went live, somebody in HR had added a college degree requirement
to it.
I just couldn't get away with that list in that, I guess.
Yeah.
Master's degree in spacey is preferred.
In spacey preferred.
Yeah.
But I guess another problem there is, it's like, well, look, if you ask, if HR writes these
job ads with these bullshit requirements, then well, who applies?
Like it's either people who are like, yeah, whatever, or people who are full of shit.
And then that's the sort of culture you're fostering.
And it might not even be the engineer's fault who wrote a very honest job description, but
like, yep.
Who applies to that?
Like, yeah.
You're going to make me lie about my FastAPI experience.
Yeah.
People just apply to anything.
I'm like, yep, I have 10 years experience in everything.
Great.
And they're like, perfect.
That's what we're looking for.
You're hired.
And then you wonder like, why is our company culture so terrible?
Hmm.
Well, I actually did have somebody apply to a job and say they have multiple years of experience
in any new language coming up.
Nice.
All right, guys.
Well, it looks like we're just about out of time.
Let me give you one more joke for it.
Brian, will you describe this picture and then I'll read what it says?
There's a poorly drawn horse, I think.
Zebra, horse that has white on the back end and black on the front end.
And the text says, I defragged my zebra.
I don't even know if people defrag drives anymore.
So this is only going to resonate with the folks that have been around for a while.
I saw that there was this great video I came across on YouTube where you can actually watch
like a live defrag session.
Like, I don't know, Windows 95.
And it's like, I don't know, it takes a few hours.
And, you know, you can kind of bring back that nostalgia and just put it on your TV and
just sit there and you're like, yeah.
Oh, it's like the aquarium you would put on your TV.
Yeah.
Like, but for tech.
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.