« Return to show page
Transcript for Episode #134:
Python proves Mercury is the closest planet to Earth
00:00 KENNEDY: Hello, and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is Episode 134, recorded June 3rd, 2019. I'm Michael Kennedy.
00:11 OKKEN: And I'm Brian Okken.
00:12 KENNEDY: And this episode is brought to you by Digital Ocean. I feel like I've been lied to. I feel like the world is not as I expected it to be. I was taught about planets in school, and first I was told there were 9. And of course, I was told that Mercury was the closest to the sun, and then Venus, and then the Earth. And yet, you're telling me Python, here, may be disproving this. What's the story here?
00:33 OKKEN: So which planet is closest to Earth?
00:35 KENNEDY: Mercury. Wait no, Venus because it goes Mercury, and then Venus, and then Earth, and then Mars and so on.
00:41 OKKEN: And the orbits are farther out and if you look at it to scale, it looks like the orbit of Venus and the orbit of Earth are closer together.
00:49 KENNEDY: Yes.
00:50 OKKEN: And that is true. However, they spend as much time the closest, on average, if you take the average, of the exact locations, and the exact distance or exact-ish, actually all of the planets spend more time closer to the Sun than they do to each other. Because that's just how that works. And since Mercury is, is it Mercury? Is closest to the Sun, it is on average, closest to all the other planets. There's a nice video on this link. So I'm linking to an article called the... I even did it wrong... So three scientist published a paper proving that Mercury, not Venus is the closest planet to the Earth, using Python. It's a nice article about using the graph, they graph it all out. It's kind of neat that you just watch it. Oh yeah, well of course, as you watch these planets circle the Sun. Then you calculate the distance, and then you do an average. It's close, so the average, Mercury is closest to the Earth 43% of the time. Venus is closest to the Earth 37% of the time. So, Mercury wins.
00:00 KENNEDY: Wow. That's really wild. I guess that makes sense, right? Because all the planets are roughly, continuously, the same distance from the Sun, but their often out of phase with each other, right? They might be on opposite sides of the Sun, which puts them super far apart, even though their orbits could actually be close together.
00:00 OKKEN: Yeah, the orbits that are far away from the Sun, those take longer time, right? So they're spending more time really far from the Sun. And if you're really far, on the other side of the Sun, from another planet, you're... Yeah, it's just far.
00:00 KENNEDY: Yeah, you're super far away. Yeah, absolutely.
00:00 OKKEN: And they were linking the article and the video, used the library used PyEphem. I think, P-Y-E-P-H-E-M. Apparently, according to Andrew Dedrick, that contributed this for this show, has been largely been deprecated and replaced with another library called Skyfield. And I took a look at that, and it looks like a really fun library to easily get data about the Solar System and stuff.
00:00 KENNEDY: Yeah, that looks super cool. I got to say one of the area that sparks the most wonder and amazement, in the use of Python, is astronomy. For me personally.
00:00 OKKEN: Yep, it's neat to even have some of these little things, like an average person can go, "Well I don't think that's right." and just map it out using some Python. You can come up with these different conclusions. It's great.
04:20 OKKEN: Weird. That's cool.
04:21 KENNEDY: Isn't that cool? It's not something in terms of digging into it, that a lot of Python developers can be super excited about, because its written in Haskell. But you could also just use it as a command line tool for parsing, and analyzing and comparing source code across languages.
00:00 OKKEN: Oh, neat.
00:00 KENNEDY: It does some interesting stuff like, some of the things you can do with it or it has in it, a flow sensitive cashing interpreter for imperative languages. It has an abstract interpreter for generating scope graphs within given program text. So if you want to compare scope across different languages like compare two different functions that are trying to do the same thing, or something. In a strategic rewriting system for open syntax term. So not a whole lot of stuff that I feel like I'm going be doing day to day. But if you're in a computer science program, if you're trying to study languages, or make generalizations or maybe even tooling. I think this would be pretty interesting to check out.
05:19 OKKEN: Yeah is it written in Haskell?
05:20 KENNEDY: Yeah it's written in Haskell, yeah. And this one come from Orin Carmy, I want to say thanks for sending that over, we always appreciate getting those ones passed along. What do you have next?
05:30 OKKEN: Well we've talked about Black several time, and I like using Black. One of the things that bothers me a little bit is, having something change my code without me knowing about it. There's a flag called black --check, that will basically tell you, if you ran it, this is what it would do. I also use Flake8 to check stuff, like to lint my code, and help me understand what I'm... Actually I like it, Flake8 doesn't change your stuff it just tells you some information. So you can train yourself to write in a more consistent way. So this is contributed by Nathan Clayton, is a Flake8-Black plugin, that can just run Black-Check within Flake8 environment. And tell you, if you ran Black, it would change this stuff along with all your other Flake8 checks. I think that's pretty handy and ill try to include this into my work flow.
06:24 KENNEDY: Yeah that probably makes it pretty easy to plug in to continuous integration pipe lines, Flake8 may be already be apart of some continuous integration check, right?
06:32 OKKEN: A lot of people are hooking Black into a pre-commit hook which is great, you can also hook, if you're already hooking Flake8 up in a pre-commit hook, you could do this as well. You can still slip stuff in and merges might muck things up so this is cool.
06:46 KENNEDY: Yeah, yeah, super cool. And you know, you can't necessarily be sure everyone is running all the same tooling or whatever, right? So maybe they've changed it somehow. So this'll check it. Very cool, that's a good one. All right, now before we get to the next one, I want to tell you all about Digital Ocean, they're sponsoring this episode as they do many of them. And make this show certainly possible in someway, so thank you to them, they are doing all sorts of cool stuff. We use them for our infrastructure, they have great virtual machine support. One of the things they recently rolled out was managed Postgres servers as a service. So if you want to create something on Linux and get it up and running fast affordable, simply, but you don't want also to become a DBA, and manage your own database, your own backups and all that. You can just plug into their managed database service for Postgres over there. One less thing to own as a puppy or to have to babysit all the time, and patch and whatnot. Definitely recommend checking them out. They're doing cool stuff, so visit them over at pythonbytes.fm/digitalocean and you'll get a $50 credit for new users. Now back onto my theme here, for understanding languages. If you look at the popular editors these days Brian, we have PyCharm and we have VS Code as the two front runners I would say these days. If you want a big IDE that's going to do everything for you PyCharm. If you have a lighter weight preference, then maybe VS Code. Seems to be what a lot of folks are trending towards.
00:00 OKKEN: Yes.
00:00 KENNEDY: So there's this cool extension for VS Code called Python Preview. If you're a computer science student or if you're getting into Python and you want to have a good understanding of what's happening as you're writing code, I think using this extension is awesome. So click on the link there and look at the little picture that gets drawn if you scroll down to the second picture.
08:40 OKKEN: Okay, this is neat.
08:42 KENNEDY: So what happens is, you write some Python code, you maybe create a list and you're going to loop over it, you're going to change the variable or something like that and it will create a visualization of what the objects look like in memory, what the call stack looks like, the global frame is and all that. And it will actually, show all the pointer references between the variables and how they're changing, what type they are, all sorts of interesting stuff as it explains what your code is doing visually, if you were to run it.
09:10 OKKEN: This is really cool, I like it.
09:11 KENNEDY: Yeah, it's really cool, it's free because it's just part of VS Code so that's really nice. So, if you're either a student or trying to learn the language or if you're a teacher. This is exactly the kind stuff you're like "Well let's look at this code." and now I'm going to draw it out on the whiteboard or you could just let this thing draw it perfectly. Right, you know what I mean? I think this would be really good for a Intro Language course. If you do any teaching or something like that.
00:00 OKKEN: Yeah, I like it. It reminds me of Python Tutor.
09:41 KENNEDY: It should remind you Python Tutor because the... if you look at the GitHub repo for this extension it actually says "I would like to thank a couple of projects for at least conceptually inspiring me." I don't know if there's any code sharing or anything like that. And the first one was pythontutor.com site so...
10:01 OKKEN: Okay, well that makes sense.
10:02 KENNEDY: Yeah it definitely makes sense. If you've played with Python Tutor before, that's a place to go explore Python and you type it in there, what's cool about this, it just explores the code you have open in your editor in a similar way. You can't step through it I don't believe but yeah it's pretty cool.
00:00 OKKEN: Yeah. Neat.
00:00 KENNEDY: Awesome. All right, what's next? Something we haven't talked about before, huh? Packaging?
10:21 OKKEN: Hah, packaging. And Poetry. A nice article called Create and Publish a Python Package with Poetry by John Franey. There's been occasionally people saying poetry is more for projects or something. This is dealing with a Python package and it walks through creating new project and then customizing the pyproject.toml file, and then all the different setting within toml, what they mean and why you picked different ones. And then carries you through to, if it's something you were going to share with the rest of the world. One of the great things about all this, is that you don't have to share your code with the world you might just be sharing it with your team members or even just making modularizing your own stuff. But, if you do want to share it, they'll show you how to use the test server at PyPI to try everything out to make sure everything works. And then finally to publish directly to PyPI.
11:14 KENNEDY: Yeah it looks like a really nice little write up. Just typing poetry publish, that's not terrible.
11:22 OKKEN: Yeah it doesn't talk about testing, or integrating testing talks into a project and pytest of course, but maybe that's an extension. But this is the packaging part.
11:33 KENNEDY: Cool maybe a follow up article that would be great. Very nice one. So the last one that I want to cover, is a realpython.com article by Logan Jones. We got to hangout with him a little bit at PyCon, that was fun, but this one is, I think an interesting thought provoking one about python and the language. I think there's a lot to learn here for many folks, and its called Pointers in Python: What's the Point? First of all, the question is outside of C extensions and inside the C Python runtime, but in Python the language itself, does Python even have pointers? Right? What do you think? How would you answer that question, if somebody asked you that?
12:14 OKKEN: It's mostly hidden from users.
12:16 KENNEDY: Exactly, if someone asked me "Does Python have pointers?" I would say yeah, of course it has pointers. But it really hinges on whether or not you define that as I can put an ampersand in front and then plus plus it move along in a string, move along in an array. Can I do pointer arithmetic and can I actually work at that level or is it, I have variables that point out to things on the heap. Like pointers, right? Which of those has to pass the bar to be it's a pointer, right?
12:45 OKKEN: Yeah and generally a new person with Python and programming altogether wouldn't even notice them and say no but names are all pointing to stuff. So...
12:53 KENNEDY: Exactly, so what's really interesting is that could be a big misconception, right? If you think what you're passing around are values but you actually have pointers, anytime you change one of those things, you're changing it everywhere. You have pass by reference not a pass by value semantics. So if you think I can pass this over, that thing can change it and it doesn't affect me like a normal value would, whoops. That's a bit of a problem. We've seen weird edge cases, where the default value of an empty list in a function can be all sorts of badness for reasons like that. I don't know, it's pretty interesting. I think actually Python is more pointer heavy than most languages. More so than C#. More so than C++, right? Because in those languages you at least have the option to define stuff on the stack and to define value type like integers versus in pointers in C++. Python you really don't. Everything, even numbers and booleans and stuff are pointers, right?
13:49 OKKEN: I didn't know that but okay.
13:52 KENNEDY: Yeah so like True is a pointer, out on the heap. The number seven is a pointer, on the heap. So what it means is all sorts... it really helps you and the article goes through a lot of this if you look deeply at the memory structure of what you get each reference type, which I'll call them, thing in Python. Each object, so everything, has a reference count that has to keep track of. It has a type. So in the PyObject that actually gets allocated when you say the number one, or whatever, that has actually a field up there that says this is an integer, right now. This PyObject that it's pointing at it's supposed to be an integer and it has a value. So if you think of, I've got this simple piece of data like the number one, or the character C it's not just one byte or four bytes, its many of them 20, 25 , 28, I'm not sure exactly what the number is. But there's a lot of stuff coming along with that, what would otherwise look like a really simple little value.
00:00 OKKEN: Yeah okay. There's some nice drawing in there about that names are pointing to objects and objects have types and values and reference counts, this is good. Probably needed.
00:00 KENNEDY: I think people should read this, who haven't deeply thought about this whole reference type scenario and what that means. It's pretty cool. My take away is that, Python has pointers. All the variables in Python are pointers but there are these safe reference type, wrapper type things that you don't directly have to worry about, allocate or whatever, right? So pretty cool there's one interesting little thing that I saw in the article. That Logan talked about, that was about interning objects. So when I said earlier before, when I say the number one it actually allocates a PyObject on the heap. Sort of. There was a PyObject allocated on the heap, that corresponds to one, but the first 256, something like that, numbers are called interned, and so are certain strings. And that means, if you allocate a one over here, and allocate a one of there, those are actually re-using the same object. They pre-allocate the basic numbers and strings, and then you just change where your pointer points. That's just part of Python start up. Right, so that's called interning. And the interesting bit is that, you can manually intern things. Like I can go to the system and say this thing I want to intern it, so if someone else tries to create one of them,
00:00 OKKEN: Ah, really?
00:00 KENNEDY: Don't reallocate it, just share this global, one off thing I've created. So it says you can intern strings and this could be useful for the performance on dictionary look ups. Because if the strings, that are the keys of the dictionary are interned then a dictionary lookup is a pointer comparison versus a string comparison. Okay, isn't that cool? Basically it's an is versus a double equal. Right? And if you've got big dictionary, and you're going crazy on it. And the keys are kind of complicated, that could potentially make it quite a bit faster. Like much, much faster. It's like, are these two integers or longs the same? Versus I got to go through twenty characters and compare them.
17:10 OKKEN: So there must be some reason why we don't just intern everything.
17:12 KENNEDY: If you intern it, it won't expire, it won't be cleaned up. If you're not going to keep it around and share it you'd basically be doing manually memory management stuff. All right, so all that, is super interesting and worth people checking out. But now the question comes down can I have ampersand X? Can I get my actual pointer or star X? Can I do real pointer stuff in Python? And of course, Python has to interact with C, and C functions often take this type of pointer, that type of pointer. So how does that work, right?
17:45 OKKEN: I don't know.
17:46 KENNEDY: In C++ we have in-line assembly, you can drop down to lower bit. In C# you have unsafe mode, C# has reference types just like python but there's a way to say turn that off and let me actually do pointer arithmetic on it. The question is, can we have that in Python? And actually if you use Cython, you can, in Python code you can say this is a pointer and de-reference its address by saying ampersand and stuff like that, that's one way. You could also work with the C types library, so I can create and integer pointer by allocating a C type and pass it around and share it and stuff. So yes if you need to dig down or you need to truly simulate what pointers really, really are. You can actually do that in Python as well and there's two ways to do it there. One requires Cython, one is just like straight CPython. All right, have you had enough language lesson for today Brian?
18:41 OKKEN: Or you can just not worry about it so much, but...
18:45 KENNEDY: Exactly. I do think its worth thinking about this question and what it looks like in Python if you haven't thought about it before. The thing before, the Preview Python plugin or extension for VS Code, I think would also help with this. Yeah because it has a little lines that are really the references and so on.
00:00 OKKEN: Yep.
00:00 KENNEDY: So that's it for all of our topics for today's. Anything else? Any extra stuff you want to just throw out there real quick?
19:07 OKKEN: Well I was going to talk about the PSF fundraiser but you've got it on your list too.
19:12 KENNEDY: Yeah it looks like, in terms of writing it down, I beat you to it. I guess i'll say something about it. So the PSF is doing a fundraiser, I linked over to it you should definitely check it out. On the previous episode, we also sort of talk about that you can buy a PyCharm license and some of that money like 30% or something goes towards the PSF. Or you can just directly contribute to it, I've linked to the blog post that they just posted. The deadline was supposed to be June 1st, I believe, but they didn't raise enough money, which is mind blowing to me. They didn't raise enough money, so they extended it until June 30th so please click on the link, donate something and more importantly maybe, try to get your company to donate. If your company deeply depends on Python having a vibrant ecosystem, these are tax deductible if you pay taxes in the US. So definitely check it out.
20:03 OKKEN: People don't know the PSF money goes to help fund workshops and conferences and they help pay meet up fees around. So that a lot of the local Python meetups don't have to pay their own fees. They do a lot of sponsorship, and financial aid of different projects, that should be funded but aren't. Otherwise, it's a good thing, donate to it.
20:22 KENNEDY: Absolutely, all right. Think its time for a joke. Quick little one here at the end, this one comes from Jay Miller The question is, what did the developer name his newborn son?
20:34 OKKEN: Of course, JSON.
20:36 KENNEDY: JSON, that's right.
20:38 OKKEN: Oh dear.
20:39 KENNEDY: Oh, well. Yeah that's a good one, thank you for that Jay. And Brian, thanks for being here.
20:43 OKKEN: All right, thank you, bye.
20:45 KENNEDY: Yeah, see you.Thank you for listening to Python Bytes. Follow the show on Twitter via @PythonBytes, that's PythonBytes 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 and thank you for listening and sharing this podcast with friends and colleagues.