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.
And I'm Brian Ockin.
And this episode is brought to you by DigitalOcean.
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 first in school, and first I was told there were nine.
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?
So which planet is closest to Earth?
Mercury. Wait, no, Venus, because it goes Mercury, and then Venus, and then Earth, and then Mars, and so on.
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.
Yes.
And that is true. However, they spend as much time the closest.
On average, if you take the average, how 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 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, I even did it wrong.
So three scientists 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, and they graph it all out, and it's kind of neat that you just watch it, and you're like, 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.
Wow.
Yeah.
That's really wild.
I guess that makes sense, right?
Because all the planets are roughly, continuously the same distance from the sun, but they're 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.
Yeah, and also 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.
Yeah, you're super far away.
Yeah, absolutely.
And they were linking the article and the video used a library called PyEphem, I think, P-E-Y-E-P-H-E-M.
Apparently, according to Andrew Diedrich, that contributed this for this show, has been largely 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.
Yeah, that looks super cool.
I got to say, one of the areas that sparks the most wonder and amazement in the use of Python is astronomy, for me personally.
Yeah, it's neat to even have some of these little things of, like, an average person can go, wait, I don't think that's right, and just map it out using some Python.
Yeah.
And then you can come up with these different conclusions.
It's great.
Yeah, super cool.
Well, thanks for finding that one.
That's great.
Last week, I covered a couple of GitHub topics that I thought were really interesting, sponsors and Dependabot.
And I'm back this time, this week, with a slightly different theme that also intersects GitHub.
So I feel like I have a theme this week, and the theme is understanding languages, like the internals and the inner workings of languages better.
So the first thing I want to talk about is this library that was released called GitHub Semantics.
So GitHub, they have, as you know, many different programming languages and all sorts of cool analytics and reporting and whatnot.
So they built this library that will help them make comparisons across languages.
Like, if you wanted to ask the question of, what is the average psycholomatic complexity by language?
Studying the top 100 repos or whatever, something like that.
You could answer that across Python, TypeScript, JavaScript, Ruby, Go, and some other languages as well.
Weird.
That's cool.
Isn't that cool?
So it's not something in terms of, like, digging into it that a lot of Python developers are going to be super excited about because it's written in Haskell.
But you can also just use it as a command line tool for parsing and analyzing and comparing source code across languages.
Oh, neat.
It does some interesting stuff.
And, like, some of the things that you can do with it, or it has in it, I guess, is a flow-sensitive caching 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.
And then a strategic rewriting system for open syntax terms.
So not a whole lot of stuff that I feel like I'm going to 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.
Yeah.
Is it written in Haskell?
It is.
Yeah, it's written in Haskell.
Yeah.
Okay.
Cool.
Yep.
And this one comes from Oren Carmi.
So I just want to say thanks for sending that over.
We always appreciate getting those ones passed along.
What do you got next?
Well, we've talked about black, I think, several times.
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.
Yeah.
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 sort of lint my code and help me understand what I'm...
Actually, I like it that it doesn't...
Flake8 doesn't change your stuff.
It just tells you some information.
And so you can train yourself to write in a more consistent way.
So this is contributed by Nathan Clayton.
There's a flake8 black plugin that can just run black check within a flake8 environment and tell you if you ran black, it would change this stuff along with all your other flake8 checks.
I think this is pretty handy, and I'll try to include this into my workflow.
Yeah, and that probably makes it pretty easy to plug in to continuous integration pipelines,
because flake8 may already be part of some continuous integration check, right?
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 can do this as well.
But having it, you can still slip stuff in and merges might muck things up.
So yeah, this is cool.
Yeah, yeah.
Super cool.
And 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 will 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 DigitalOcean.
They're sponsoring this episode, as they do many of them, and make this show certainly possible in some way.
So thank you to them.
And they are doing all sorts of cool stuff.
You know, we use them for our infrastructure.
They have great virtual machine support.
But one of the things they recently rolled out was managed Postgres servers or 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 to also 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.
And that's one less thing to, you know, own as a puppy or to have to babysit all the time and patch and whatnot.
So definitely recommend checking them out.
They're doing cool stuff.
So visit them over at pythonbystat.fm slash 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, like, frontrunners, I would say, these days.
It's kind of like if you want a big ID that's going to do everything for you, PyCharm.
If you have a lighter weight preference, then maybe VS Code seems to be like what a lot of folks are trending towards.
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 just look at the little picture that gets drawn if you scroll down to the second picture or something like that there.
Okay.
This is neat.
So what happens is you write some Python code.
You maybe create a list, and then you're going to loop over it, and 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 and what type they are.
All sorts of interesting stuff as it just sort of, like, explains what your code is doing visually if you were to run it.
Oh, this is really cool.
I like it.
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, right, like, this is exactly the kind of stuff you're like, well, let's look at this code, and now I'm going to go over and draw it out on the whiteboard.
Like, oh, you could just let this thing draw it perfectly, right?
You know what I mean?
Yeah.
So I think this would actually be really good for an intro language course if you do any teaching or something like that.
Yeah.
I like it.
Yeah.
It reminds me of Python Tutor.
It should remind you of Python Tutor because 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 that there's any code sharing or anything like that.
And the first one is Philip Guo's pythontutor.com site.
Okay.
Well, that makes sense.
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.
And what's cool about this is, like, it just explores the code that 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.
Yeah.
Neat.
Awesome.
All right.
What's next?
Something we haven't talked about before, huh?
Packaging?
Packaging and poetry.
This is a nice article called Create and Publish a Python Package with Poetry by John Franey.
There's been, occasionally people will say poetry is more for projects or something.
But this is dealing with a Python package.
And it walks through creating a new project and then customizing the pyproject.toml file.
And then all the different settings within the toml and what do they mean and why you pick different ones.
And then carries you through to, if it's something you were going to share with the rest of the world.
I mean, one of the great things about all this is you don't have to share your code with the world.
You might be just sharing it with your team members or just even making modularizing your own stuff.
But if you do want to share it, it does show you how to use the test server at PyPI to try everything out and make sure it works.
And then finally to publish directly to PyPI.
Yeah.
It looks like a really nice little write-up.
And yeah, it's just typing poetry space publish.
That's not terrible.
Yeah.
It doesn't talk about testing or integrating testing and talks into a project, which, and pytest, of course.
But so that maybe that's an extension.
But yeah, this is the packaging part.
Yeah, cool.
Maybe a follow-up article.
That'd 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 hang out with him a little bit at PyCon.
That was fun.
But this one is, I think, an interesting sort of thought-provoking one about Python and the language.
So I think there's a lot to learn here for many folks.
And it's called Python Pointers or Pointers in Python, What's the Point?
So, I mean, first of all, like the question is like outside of C extensions and maybe like inside the CPython runtime.
But, you know, in Python, the language itself, does Python even have pointers, right?
Like, what do you think?
How would you answer that question if somebody asked you that?
It's mostly hidden from users.
Exactly.
Yeah.
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 like plus plus it and move in the, you know, move along in like a string or move along in an array.
Like, 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?
Like, which of those has to pass the bar to be like it's a pointer, right?
Yeah.
And generally, a new person to point Python and programming altogether wouldn't even notice them and would say no.
But, I mean, like names are all pointing to stuff.
Exactly.
So, what's really interesting is that could be a big misconception, right?
Because 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, right?
You have passed by reference, not passed by value semantics.
And 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, right?
Like, whoops, that's a bit of a problem, right?
We've seen like weird edge cases where like the default value of like an empty list in a function can be all sorts of badness for reasons like that.
So, 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 define value types like integers versus in pointers in C++, right?
In Python, you really don't.
Everything, even numbers and booleans and stuff are pointers, right?
I didn't know that, but okay.
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 like all sorts of, you know, it really helps you.
If you look, and the article goes through a lot of this.
If you look deeply at like the memory structure of what you get, you know, each reference type, which I'll call them, you know, thing in Python.
Each object, so everything, has a reference count it has to keep track of.
It has a type, like so, in the pi object 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 pi object that it's pointing at is supposed to be an integer, and it has a value.
So, if you think of, I've got this simple little piece of data, like the number one or the character C, it's not just one byte or four bytes or whatever.
It's many of those.
I don't know, 2025, 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.
Yeah, okay.
Okay.
There's some nice drawings in there about like that names are pointing to objects, and objects all have types and values and reference counts.
And yeah, this is good.
I probably need to.
Yeah, I think people should read this who haven't deeply thought about like this whole reference type scenario and what that means.
It's pretty cool.
My takeaway is like Python has pointers.
All the variables in Pythons are pointers, but they're like these safe reference type, wrapper type things that you don't directly have to worry about, allocate, whatever, right?
Yeah.
So, pretty cool.
There's one interesting little thing that I saw in the article that Logan talked about, and that was about interning objects.
So, when I said earlier before, when I say the number one, it actually allocates a Py object on the heap, sort of.
There was a Py object allocated on the heap that corresponds to one, but the first 256, something like that, numbers are what are called interned, and so are certain strings.
And that means like if you allocate a one over here and you allocate a one over there, those are actually reusing the same object, right?
So, they pre-allocate like the basic numbers and strings, and then you just change where your pointer points.
Like that's just part of like Python startup.
Okay.
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.
Oh, really?
Just, you know, don't reallocate it.
Just share this sort of global one-off thing I've created.
And so, it says you can intern strings, and this can be useful for the performance on dictionary lookedups.
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?
Yeah.
So, basically, it's an is versus a double equal, right?
Okay.
And if you've got a big dictionary and you're like 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 like 20 characters and compare them?
Well, so, there must be some reason why we don't just intern everything.
If you intern it, it won't expire.
It won't be cleaned up.
Oh, okay.
Yeah, yeah.
So, I mean, like if you're not going to keep it around and share it, you would basically be doing manually memory management stuff.
All right.
So, all of that is, I think, is super interesting and worth people checking out.
But now the question comes down like, can I have ampersand X?
Can I get my actual pointer or star X, right?
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?
So, in C++, we have like inline assembly.
You can kind of drop down to a lower bit.
In C#, you have unsafe mode because 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.
So, the question is, can we have that in Python?
And actually, if you use Cython, you can.
Like in Python code, you can say, this is a pointer, and you can dereference its address by saying ampersand and stuff like that.
That's one way.
And you can also work with the C types library.
So, I can create like an integer pointer by allocating a C type and then pass it around and share it and stuff.
Okay.
So, yes, if you need to dig down and you need to like 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.
Okay.
One requires Cython and one is just like straight CPython.
All right.
Have you had enough language lessons for today, Ryan?
Or you could just not worry about it so much.
But, okay.
Exactly.
I do think it's worth thinking about this question and like what it looks like in Python if you haven't thought about it before.
And I think the thing before, the preview Python plugin or extension for VS Code, I think would also help with this.
Yeah.
Yeah, because it has the little lines that are really the references and so on.
Yep.
So, that's it for all of our topics today.
Anything else?
Any extra stuff you want to just throw out there real quick?
Well, I was going to talk about the PSF fundraiser, but you've got it on your list too.
So.
Yeah, it looks like I, in terms of writing it down, I beat you to it.
So, I guess I'll say something about it.
So, the PSF is doing a fundraiser.
I'm linked over to it.
You should definitely check it out.
On the previous episode, we also sort of talked 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.
So, I've linked to the blog post that they just posted.
Now, the deadline was supposed to be June 1st, I believe, but they didn't raise enough money, which is mind-blowing to me.
But they didn't raise enough money, so they've extended it until June 30th.
So, please click on the link, donate something, and more importantly, maybe try to get your company to donate.
Right?
If your company deeply depends on Python having a vibrant ecosystem, these are tax-deductible if you pay taxes in the U.S., so definitely check it out.
People don't know the PSF money goes to help fund workshops and conferences, and they help pay meetup 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.
So, it's a good thing.
Donate to it.
Absolutely.
All right.
I think it's time for a joke.
Yeah.
Quick little one here at the end.
This one comes from Jay Miller.
And the question is, what did the developer name his newborn son?
Of course, Jason.
Jason.
That's right.
Oh, dear.
Oh, wow.
Yeah.
Yeah, that's a good one.
Thank you, Jay.
And Brian, thanks for being here.
All right.
Thank you.
Bye.
Yep.
See ya.
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.