Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 187, recorded June 17th, 2020. I'm Michael Kennedy. And I am Brian Okken. And this episode is brought to you by us. There's a couple of things that we're offering that I think are going to be great for you. We'll talk more about that later. Right now, I want you to bring us back to our youth, Brian. Did you ever do the Lego Mindstorm thing?
No, no. Lego was just bricks when I was a kid. Yeah, well, yeah. Okay. I love Legos. And I'm actually, I've got like three kits halfway done right now. One of them I've been working on for a long time. I should finish those. Anyway, because there's a new one I want to buy. It's not out yet, but Lego announced Mindstorm Robot Inventor. They've had different Mindstorm kits in the past for robotics, and they started in 2006,
or at least on the Mindstorm series. NXT was in 2006. They did an NXT 2.0 in 2009. And then the EV3 was in 2013, and I was actually kind of disappointed with the EV3 because it was weird. It was like a post-apocalyptic thing going on. It was like punk rock robots or something. I don't know. Anyway, so I think we've got an NXT somewhere in the house. But the new Mindstorm Robot Inventor, they finally figured out that people are using these things to try to teach in STEM
education and stuff. And so the new one, this is awesome. Drum roll. It supports Scratch and Python. So that is super awesome. It has instructions for five different robots that do lots of different kind of cool things like a car-like robot and an upright-like robot. And there's a bunch of sensors. The module that it has connects to six different input-output ports for sensors and motors.
There's even a six-axis gyro and accelerometer, a 5x5 LED matrix. 5x5 is not much, but we can probably figure out. We can hack more. Color sensor and distance sensor, of course, and Python. So one of the other neat things about it is the other one, I'm not sure about the older ones, but they were programmable, of course, with Windows or Mac. But this one also is going to have the ability to program it via
an Android or iOS tablet or smartphone and even some Fire OS. So like the Amazon Kindles, some of them might be able to be used, which is pretty awesome because even though this robot inventor is pretty expensive, if a school's helping to support it or something and a kid has a $50 tablet at home, hopefully that'll work. So that's neat. Yeah, this is really cool. And I think being able to program with a real programming language instead of a blocky type of programming language goes a long
ways. I think people underestimate how much kids can do with some simple text versus, you know, like, well, it's got to be drag and dropy, so don't ever make syntax errors. And, you know, if you look at things like codecombat.com, kids go through these dungeons and they solve, like, challenges to open the door, make it across the bridge or whatever with code, but it's all typing Python. But the editor is so insanely aggressive, in a good way, aggressive with autocomplete. Like,
if you type A, it'll try to autocomplete hero.attack and suggest arguments. I mean, it's like ridiculous. And in those sorts of scenarios, I feel like, you know, don't pull the punches. Like, give the kids a real experience. They'll adapt pretty quickly. I think people underestimate with the right tooling, what kids can do with a text language like Python.
Yeah. And I, so I really hope, I think so too. And so it's exciting to have it. I know you can't, there were ways to put control of the EV3 with Python, but it was extra hacky ways and not obvious for people. And so hopefully having this supported. And I really hope that we get more of these sorts of robot inventor things coming out from Lego. Not every seven years. Could we update maybe every couple of years? That'd be awesome. Yeah, for sure. Technology changes fast.
Yeah. And on a related note, I didn't do this as a full story, but I wanted to note, I also saw a project called Microscopy or Microscope Pi, maybe. It's an IBM open source project to build your own modular microscope using Raspberry Pis and Lego bricks and a little bit of 3D printing. And you can control it or like a motorized microscope, which is pretty awesome. So that's neat too. Yeah. Yeah. That's really cool. All right. Well, I have a theme that will become clear as I go through
my items this week. I first somehow, somehow it just landed, lined up with all the items I picked in the same general area. So I want to start off by talking about this article from Kevin Markham from dataschool.io. And he put together, he's been putting together lots of cool steps and guides to help people get into stuff. His area is mostly data science, but obviously in the Python side. So he created this thing called a step-by-step guide to contributing to GitHub.
Nice. Yeah. So if you're new and you haven't actually yet contributed to an open source project, it's like, here are the 17 steps in order. And some of them are obvious, like you have to have a GitHub account, you have to fork the project. Others are not as obvious. Like I always, whenever I fork something and I'm like, Oh, you know, I really want to get the changes from the thing I forked merged, you know,
sort of synchronize my fork with the remote fork. I'm always like, what is that command again about like remote origins and for upstream, I got a set, you know what I'm like? And so having that stuff all laid out in a nice little, do this, then this, then this guide is helpful even just for a couple of those steps, if you've done it before. So, I'll just run you through the steps really quick. People can go and see the pictures and the graphics and the explanation. But,
so I want to contribute to something. I think he contributed something back to scikit learn, but it could be any project, right? So you start by figuring out what project you want to contribute to. You fork it to your GitHub account and then you check it out. You clone it locally and load it up, make some changes. And then you make sure you have your origin remote pointed back to the thing on GitHub. And then the part I was just talking about, you can add an upstream remote, which allows you to
say, give me the changes from the source repository to my forked version. You always want to get those, like maybe forked it a while ago, but now you want to make a change. So you want to grab the changes from the upstream, the original repository and bring it over, create a new branch, a feature branch for
your changes. Cause you're going to use that for a PR, make changes, commit your changes, push it to your fork, create a PR by clicking the green create PR button, review the PR, have conversations around it, maybe make some more commits to your pull request. So it talks about like, if you submit a PR and they're like, that's great, but you need unit tests. How could you forget the unit tests? Please add those as well. How to do that. Right.
It's a common story. I'm sure discuss it. And then once it's merged or I guess closed, even you could delete the branch, but especially if it's merged, you don't need it anymore. So delete your branch, synchronize again, your fork with the original project repository through the upstream link, because once they've accepted your changes, your main branch will be out of sync with there. So you want to do that. And then also as a nice little tips for contributing code section as well, with just
some advice on how it goes. So the pictures and like here, type this for the step. I think this is pretty handy for a lot of folks. Yeah. People just need to do it. It seems overwhelming when you start because it seems like, oh my gosh, this seems like so over the top. And actually, so at work, when we switched from a different version control system to, to get, we started out with this sort of a model.
This is not an uncommon model, even within not just open source, but other projects. Originally, I thought this is a lot of overkill. We don't really need forks and branches, but there's a lot of benefits to doing both. And you can just kind of get used to it. And it's not, it ends up being not that big of a deal. Yeah. One of the advantages for what you're talking about, like inside your company, obviously it's important for open source, probably mostly because you don't
have commit rights. So you make changes to your thing and you say, accept my changes, right? But inside a company, everyone has commit rights for the most part to their project they're working on. But it bundles it up in documents. Like these are the changes to add this feature. These are the conversations around it. And here's how it got accepted, right? It's like a nice way to go beyond just like, here's a commit or a series of commits I did this week. I think some of them have to do with
this scrum thing I said I would do. Yeah. One of the main reasons we kept the fork model in place is so that we can, if somebody accidentally pushes up a large executable or something that they shouldn't have committed in the first place, it's easier to kill a fork off than a branch of a project. I see. It's like a layer of insulation of mistakes. Yep. Yep. Definitely. Yeah. Cool. Well, before we get on to a new language, Python inspired language, I just wanted to talk about
a couple of things you can do to support the show. Obviously, Brian and I are both doing things outside the podcast that we think contribute back to the community that if you want to support what we're doing, it would be great if you could check them out and consider them as you're learning Python things. So I have courses over at Talk Python Training. We have, I think, 170 hours of Python courses and probably a couple hundred hours
of exercises for people to do over there. So if you're looking for courses or to learn stuff with Python in general, check out Talk Python Training. And Brian, you have some kind of book, I think. Yeah. So I think that anybody that wants to learn how to test better should pick up a copy of Python
Testing with pytest. So the book that I wrote about pytest, it's not just, it kind of walks through all the different sorts of things you can do in the, with pytest, but also around testing a package project. And I think a lot of these carry over, even like switching databases and stuff, these things carry over for all sorts of types of projects. And I've gotten a lot of great feedback and I think it's a good thing for people to read.
Yeah. Awesome. It's a great book. And both of those things are linked at the top of the show notes. So you all can just check it out in your podcast players. So I'm always fascinated with embedded Python Python and things like MicroPython and CircuitPython. And you've got something along these lines, right? Yes. I ran across this, a language called SNEK or SNEK, I think. SNEK. So it's at SNEK.org. And it's a Python inspired language for embedded devices. But my first SNEK.
reaction is probably going to be yours is also, don't we already have that? Don't we already have MicroPython and- We already have two. I'm confused why we have two. Yes. And CircuitPython. Well, actually, yeah, we've got lots. MicroPython and CircuitPython are the ones that we think about a lot. CircuitPython, of course, is focused around Adafruit, but also runs on lots of different other boards as well. But what about really small things? Even those,
they run on these small chips, but there's smaller chips that you might want also. So if you only have a few kilobytes of Flash and RAM and you still want to run something, can you run Python? And that's where SNEK comes in. So it's, I mean, it really runs on small processors. Even one of the things it supports is the Lego EV3. So if you don't want to wait for the new robot inventor, you can run SNEK
on your current EV3. So that's neat. But the smallness, its goal is it's not Python. So most SNEK programs will run in Python, but not the other way around. You can't run most Python in it. So it's got a limited language. But part of that is an educational purpose. So a smaller language footprint, as Python's adding more and more new features, it may be overwhelming for some people when they're
just starting out. So having a smaller language is kind of a neat thing. But all of that learning can go towards your, if you're learning SNEK, you will can transfer that to Python projects later. Right. It's easy to level up to Python because it's, it's like going from C to C++. There's stuff to learn, but it'll kind of work. Yeah. Yep. There's even like a dedicated, a new board called the SNEK board that you can, that is available. It was through a crowdfunding process, but it runs both
CircuitPython and SNEK. So yeah, one more thing to be able to run little small chips with Python-like language. So this is neat. Yeah. It's really cool. And the very, very small devices, I think it's going to mean, you know, Python can appear in more places, right? On incredibly small IoT things and whatnot. Like even if you have larger though, I like the idea of people saying Python is just kind of a great
syntax. If we strip some of the things out that full Python has, it's still a usable language with a lot
of it stripped out. So I think it's a good thing. Well, that whole idea, I mean that we could go on and on about that, but the whole idea is pretty interesting because as we see things like Python moving to web assembly and running on the front end and talking about maybe having a Python on mobile, as well as the traditional CPython that we know and Python on chips, like having this concept of a
smaller focused subset of Python that is universal. That's pretty interesting anyway. And it sounds like that's a little bit of the philosophy here. Yeah. It is interesting. What are the things we see like this coming up in the future? That's right. So we spoke about Git before and forks and using forks as insulation, but have you ever made a mistake with Git? Like every day? Yeah. Yeah. You're like, why did it, that thing get checked in? I told it to ignore it and now it's in there,
right? Yeah. Stuff like that. So Andrew Simon sent over a link and recommended a zine, a little small book. A zine. A zine. Yeah. A zine by Julia Evans. She has a bunch in the programming and DevOps space. And she created one called, Oh Shit, Git. And it's like, I'm learning Git and oh my gosh, something's gone wrong. What have I done? It's cool, right? This is great. Yeah. So I want to be clear. This is a paid thing.
It costs $10. We have no affiliation with it, but I just liked the idea of it. So I thought I would feature it. So basically it's this really short little zine book thing that explains Git fundamentals, like what's a Shaw and why don't you call it an SHA? I don't know. Stuff like that. Right. And then it
goes into a bunch of how do I fix common mistakes? Like I committed to the wrong branch and other fundamental problems or I have a merge conflict or I committed the wrong file or I ignored a file, you know, and going back in time, right? Like we wrote the wrong code. The server is down. Everyone is yelling at me. I know it worked yesterday. How do I get the server or something to go back and say,
just go back to the way it was. And we'll deal with it in a minute when things calm down. So like all those kinds of stuff. So I thought this was kind of a cool one. And people who are like getting started with Git, but they're, you know, they run into these things and it's a big deal. It's like, oh no, it's a merge conflict. Now what? I'm stuck. Right. Or like I said, committed to the wrong file or to the wrong branch or whatnot. I think this would be pretty helpful for folks.
I love that the titles of the different sections are the thing that went wrong. Like I committed to the wrong branch. Exactly. Yeah. I tried to run a diff and nothing happened. I've emerged conflict. I want to split my commit into two commits. I want to undo something, five commits. And so on. I got to make sure that this isn't a violation of my human resources things to buy this for all of my employees, because I think everybody needs this. These things are great.
Yeah. Just put a little bit of black electrical tape on top of that middle word and then you can hand it out. It's a PDF. Maybe I, you know, get by five licenses and printed it five times. Yeah, no, it's pretty good. It's like, I did something terribly wrong. Does Git have a time machine? Yeah. So, it sounds interesting. Thanks Andrew for recommending it and Julia. Cool work on the creative way to address Git issues. Yeah, definitely.
So, what's the story with versioning? You guys got a beef with it? Well, you know, I've kind of always had a beef with it, but I didn't really think about it. So Brett Cannon actually asked a question on, it was interesting. He wrote an article that I read recently called, why I don't like Semver anymore. Semver being semantic versioning. That's the 2.1.0 style. Yeah. And like, like, as opposed to calendar versioning or, or, or what we
were, we talked about this earlier of zero ver. Zero ver is like a, a, even more negative version of Semver. Yeah. So the interesting question is it's not straightforward as to what, so there's often, it's like the first digit, like if we say X dot Y dot Z X is some major thing. So like some crazy new feature, it's either a crazy new feature or it's a incompatibility with the old one. Like we're going
to change the interface. Right. When Django went from one dot something to two dot O they dropped support for Python two, for example. And that was indicated partly there. Yeah, exactly. So what constitutes an interface break? And that's what a lot of people think about. Well, what about if you add a deprecation warning to something that you're planning on taking out in the next version?
Is that adding an extra warning? Is that a major thing or a bug fix or a minor thing? And that's part of the discussion of most of us, I think would think that the, maybe that's a, either that's just a bug fix or a minor thing. That's not a major thing. Right. And to me, it makes, it makes like no different, there's no new functionality. Nothing stopped working. That seems like a super minor, like it should change the very last number because it doesn't even add or change a functionality.
But it is adding a warning. So if I have come, if I'm, I'm running Python with, with the flag that turns all warnings into errors, or if I'm running my tests such that, that, and that's like normal with running tests is you turn all your warnings into failures so that you find them. Now you've, you really did change the interface because I, to get rid of that warning, I have to go and either I need to
change to not, I need to not look at that warning or I need to change my use of that thing. So it is kind of an interface break. Yeah, for sure. So that's part of his discussion is that it's not really straightforward to say that what is a major, minor, or micro change, what that really is. It's a gray area. There's discussion. And then also really what the observation that the, the three digits kind of makes
sense if you are maintaining three or more branches. So if you're maintaining a current branch, plus the features you're working on the next one, that's a, another branch, plus you're doing bug fixes to the current production one. So you've got like development going on in one branch and fixes in the other one. And then, you know, minor things going on, you might have like even more branches that you're
maintaining at once for a large project with lots of people on it. That totally makes sense for small projects and side projects and things where you're really, you're not maintaining a bunch of stuff. You're it's one branch and you fix bugs. You're not planning on adding new features or if you are,
you know, well, I don't know. It's so infrequent that doesn't matter. Maybe two digits is enough, just X dot Y, or maybe just one digit, because there's a whole, one of the reasons why a whole bunch of people are at zero for is they're trying to not be backwards incompatible and they're, and they're not going to add any major new features. It's a simple tool or something. The other thing Brett brings up is basically you shouldn't depend on this stuff because it's nebulous
and wishy-washy. You shouldn't depend on the numbering semantic versioning to see whether or not what versions of a new of a dependent project you're using. You should rely on continuous integration and testing. So do a minimum version for the project you're using, but don't do a max and use your testing to find out if there's any problems. Always do the latest one in that the version doesn't
really matter. You're going to keep ahead. And if your CI breaks, then you might have to pin your dependency to earlier one. But also you should always pin your dependencies to specific versions and just use your CI and testing system to see if you can move forward. Yeah, absolutely. And if you use something like depend a bot or pi up or something like that, it'll automatically look at your repository, increment those versions, run some CI if you have it set up,
and you'll know if it's acceptable or not. So you can get the system to tell you, hey, you should update this pinned version and click here to allow it. Yeah, I love systems like that. And it totally makes it so you can review it and go, yeah, that's good. Often those just show up as a merge request that you just accept, right? That's right. Yeah, very nice. Yeah. So a good discussion about thinking about whether semantic versioning really is appropriate for your project.
Yeah. So do you remember what the recommendation was? I scanned it and I didn't see like a super clear like do this instead. No, the end, there's a kind of a summary that I kind of like cribbed and put in our show notes. Essentially, it's the try to pin the lowest version or pin your versions, of course, but have a low end, but don't have an upper end and just test. As for using dependencies for your own version,
it really was, it should match your branching strategy really. So if you're really not supporting three branches, three digit semantic versioning doesn't make sense. You can do two digit or one digit versioning. Yeah. Yeah. Pretty cool. All right. Carrying on with my theme, you want to talk about Git? Oh, we haven't covered Git for a while, so that'd be good. Yeah, for sure. So there's famous, like, you know, rock star famous, Julie Roberts movie star famous.
There's like maybe a step down, but still pretty cool. There's geek famous, right? Like on the regular street, nobody would recognize you, but at a conference, you're kind of cool. I think probably Gita Van Rossum definitely fits geek famous, right? Yeah. And then apparently there's Git famous. Oh, is that, is that when you have like your pixelated face as your Git history? It's really complicated, but if you time it just right, you can, yeah. No. So there's this project,
Bjorn Olson sent this over and said, Hey, you should check this out. It's, it's quick and fun and kind of useful. If you want to go to a project and answer the question, who kind of created this or who mostly worked on this? And I have this all the time. When I go look at these projects that we're researching and covering, maybe I want to talk to the person about a question or something. I'm like, all right, well, if I can go to the contribution thing and GitHub, maybe it'll show me, but that's
more of an over time and who's recently worked on it and stuff. So it's not super good. And if you're not on GitHub, then obviously it doesn't help. So there's a thing called get fame, which is a Python library. And the idea is you pip install get fame and then associate it with get, you have a new command. You say, get space fame and it will go through and it'll like, look at all the commits and all the people and how many lines of code were changes, changed and files and whatnot by everyone.
And then it'll give you a ranking of these are all the people who've contributed and here's how many files they've changed, how many lines of code they've changed and so on. It's pretty cool. And it sorts them by most popular, most largest contribution downward. That's cool. Yeah. And it's super easy. It's super easy. Like pip install, get fame, get config and set an alias to fame to run the Python command. And they just type
get fame and it just goes and it uses the TQDM. I think that might be the right order. Progress bar, you know, to show you its progress. I ran it on a somewhat large, somewhat large project, small to medium project, I guess, in terms of regular software. And it found 596 commits and it took seven seconds to do that. And it processed 76 files a second. That's pretty good. Yeah. I totally like the idea, especially around a very useful for us when we want to talk to one of
the people that's really involved with it. Yeah, exactly. Yeah. And like you said, often some of the most recent ones are valued, of course, but not major changes to the library or something. Right. Exactly. So it's a little bit hard to know. So this kind of gives you the historical view of who's really contributed to this project and how many lines of code have they changed and so on, which is not always a great measure, but you know, it's still
interesting. Yeah. I totally missed the, my guess. I, my guess was it was an alias to rewrite get blame because blame is so, I don't know why they named it that. I know. credit, maybe get credit. It should be called credit. There's positive and negative credit, right? Yeah. Yeah. So it basically runs get blame over and over and over on each file and then analyzes the file, the result of get blame, and then builds out this, this history based on that. That's pretty cool. Yeah. Yeah. Pretty cool.
super easy to use if you're into it. And, that wraps up all of our items, Brian, got any extras you want to share with folks? I wanted to thank everybody that's supporting the show through Patreon because I went in and took a peek today and we have 26 supporters. And if you want to, we have links in the show notes and also links on our site, if you want to help out the show through Patreon, but you can also go to patreon.com slash Python bites and many people donate a dollar a
month. And that is awesome. Thank you. And if you go above and beyond and contribute a little bit more, so I wanted to do a special shout out to those that are contributing more than a buck. So thank you, Brent Kintzer, Brian Cochran, Bert Raymakers, Richard Stonehouse, and Jeff Kiefer all donating more than a dollar. So thank you very much. Awesome. Yeah. Thank you guys. That really does help support cover,
things like editing and transcripts and all that kind of stuff. Now I have a quick follow-up for, last time we spoke about dunder py packages and things like that to where you could set up, uh, I think it was pyflow we were speaking of, where if you interact with Python through pyflow, basically it will use this node JS like behavior that is really still coming hopefully in PEP 5.8.2.
So after that, someone, it was Paul Everett who sent over a message and said, Hey, did you know Kushal Das, who is one of the folks core developers working on this whole idea has a little Python example, just a single Python file that you can use to basically implement this. And it says, this would probably be really great for like trainers and students and teachers and stuff like that to kind of sidestep the whole virtual environment story. Okay. That's cool. I got to try this out.
Yeah. So a quick little link to a working version. That's not just a whole overhaul like pyflow, but a simpler thing. All right. Now this last one, Brian, this joke here, you know, wrap it up with a joke as always, you've got to open it up because it's an animated GIF. Okay. First, let me ask you what shell to use on your Mac. Bash. Bash. Okay. So I'm a, oh my Z shell kind of guy because I love like the history and
it keeps a really good track of all the stuff I've done. And sometimes I'll type like one or two letters. I'll try to go back and I'm like, no, no, that's not, instead of just typing out the stupid thing, I'll just go back and back. And so here's like this clear, like super bearded guy. Who's some kind of sysad man, Linux exaggerated person, I guess you would say. And it's an animated GIF, right? The guy's
just clicking his finger, clicking his finger up, up, up, up, up, up, up, up, up. Shows him doing that, doing it some more. Now he's got a drink. He's clicking on, he's drinking his drink, clicking up. And then finally, he's so excited. Oh, finally. What does he say? I knew I had that some, that LS somewhere in my history. And eventually it just says, yeah, LS, right? He's up arrowed until like forever to just soon enough to type LS. Oh man. Have you ever been there?
No. Cause I, what kind of key binding? Do you use VI key bindings? No. Okay. Do you like a backward search or something like that? Yeah. You can just search through your history to find the, find them. But then you have to press more than just the up arrow. Anyway, people, this has got a cool, a cool little animation cartoon thing. So I just linked over to comicstrip.com where, where the title is definitely not lazy.
Yeah, definitely. You know, I was thinking about it. I don't even remember the key sequence to do the searching. I would have to do it. I just, it's one of those built in muscle memory things now. So that's right. Yeah. I was trying to remember it today and I couldn't remember it. I'm like, whatever, up arrow, up arrow, up arrow. So yeah, pretty funny. All right. Well, thanks for bringing all these items and sharing with everyone. Great to chat with you as always. Thank you. 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.