Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 97, recorded September 26, 2018. I'm Michael Kennedy.
And I'm Brian Okken.
Hey, Brian. How are you doing today?
Hey, I'm doing great.
Awesome. Awesome. Me too. Lots of big news. So much news that I can't even keep up with it.
Yeah, it's a good thing that there's like this weekly podcast that keeps us up on Python news.
I know. Where's the one that we get to listen to?
Yeah.
That's what we need. We need a meta podcast.
No, that's okay. Other people don't do that.
Yeah, that's right.
So I also want to say thank you to Datadog for sponsoring this episode.
Really happy to have them on board. Check them out at pythonbytes.fm/datadog.
Cool t-shirt lives at that URL. More to say about that later.
PyPI just keeps getting better and better, doesn't it?
Yeah, PyPI keeps getting better and the tools around it.
And a recent release just a couple days ago of Twine.
So Twine has been updated.
And for people that don't know, Twine is the thing that pushes your code from your laptop or your computer or your server or wherever to PyPI.
And Twine has a check function now.
Actually, there's quite a few things in the new Twine upgrade.
But this one's neat because once you've packaged your distribution up and everything and your wheels and whatever, it usually shows up in a dist folder.
And then you say Twine check dist and then everything in it.
And it checks to make sure that one of the things it does, I think it does a lot of things, but at the very least, one of the things it does is make sure your readme is rendering properly, supposedly.
Yeah, that's really cool that it even checks that, right?
Because that's hard to test, right?
How do you know if your readme is not rendering properly?
Yeah, we're linking to an article that's from on the PyPI that is how to make a PyPI-friendly readme.
So there's actually, it's not really difficult, but it's one of those things that, it's one of the last things you do before you, well, it shouldn't be the last thing.
But when you're getting a package together and you're like, hey, I have this really cool idea, I want to push it up on PyPI, you got to make sure the readme works.
And this is one of those steps.
And there's just a little short article on how to do that right.
Yeah.
Although like magic, it's not difficult, but the stuff you have to put in your setup.py and everything.
Yeah, that's a good find.
Anyone who is either maintaining or thinking of creating a PyPI package should definitely check it out.
Yeah, and I think in your build toolchain or your talks toolchain to add a check step to make sure to go ahead and check before pushing it up, that would be a good thing to do.
That can be like a pre-commit hook or something.
Wow.
I don't know.
Definitely part of your continuous integration anyway.
Yeah, definitely part of your CI.
The first item I have is pretty interesting.
And when you think of the languages and technologies that you can use, most of the time we think of programming languages and their subsequent runtimes basically being free, right?
I mean, obviously Python.
Like you don't think, well, what does CPython cost?
But even from places where you might not necessarily expect it, right?
Like C++, it's free.
Go is free.
Microsoft.net is free.
Right?
All these things.
You know what's not free these days?
What?
Java.
Really?
So apparently, Sun has made the Java runtime for, you're going to have to just check out the article on the register to make sure I get this exactly right, but roughly, Java is making the runtime a subscription, and the subscription costs $25 per processor per month for commercial entities.
Wow.
Is that crazy?
Yeah.
There's definitely some cases, like as students and whatnot, where you can just use Java for free.
But a lot of commercial organizations that depend upon Java need to read this article and the subsequently linked 330-page document that describes this process over at Oracle.
Hmm.
So that's pretty interesting, right?
Yeah.
It's the run times even.
So you have to, like, if somebody else makes a Java application, it's not the person making it, it's the person running it.
Yeah.
So it says, Oracle's put a price on the Java SE and its subsequent support.
So $25 per processor per month plus a $2.50 per user per month on the desktop.
Okay.
Unless you buy a whole bunch.
Yeah.
So it looks like maybe $250.
Wow.
Yeah.
It's kind of all convoluted, but it's, yeah, it's quite interesting.
They say the older run times, you can still use them for free, but, like, who wants to use a run time that has no bug fixes, no security patches or things like that, right?
Yeah, I guess maybe they're trying to make everybody move to Python.
Yeah.
And that's exactly, that was my first thought.
It's like, yeah, Java's been pretty high in the language rankings.
Maybe it's going to plummet now.
I mean, seriously, this is pretty crazy.
So, yeah, it says, also, there's a little bit of a stick to go with the carrot.
Yeah.
Come January 2019, Java SE 8 on the desktop won't be updated anymore unless you buy a subscription.
And, yeah, the short version is every commercial enterprise needs to look at their Java standard edition usage to see if they have something to do with licensing now.
So this was sent in by one of our listeners, and I'm super sorry I didn't write down the name in the show notes, but thank you for sending it in.
This is interesting.
I know it's not directly a Python thing, but it's just, you know, here's the thing.
I kind of always sort of thought of Java as more or less open source, and I guess it's just, you know, that Oracle oversaw, but I guess that's not the case.
Yeah.
Weird.
Okay.
Yeah.
Anyway, there's that.
Yeah.
Well, this next topic is really, really important.
For importing.
Importing.
Yeah.
It's very, very importing.
Tell us about it.
Importing.
Yeah.
Absolute versus relative imports in Python.
This is an article on the real Python.
I think it's on real Python.
Realpython.com.
There's a lot of great articles there.
Yeah.
I like what they're doing.
Great job over there.
Me too.
The relative, and I lost my tab, but the most of your imports are going to be, the first part of the article is talking about normal kinds of imports.
Like just the, you know, you import a package, like the import statement.
Right.
You do from package import something or from package dot, some sub package.
There's a lot of, there's a lot of versions of that.
So it's covering that.
But there's, like for instance, there's relative imports, which includes dots.
So, like from dot, import something.
Or import dot something.
And I never, I kind of never remember how all that works.
So I'm glad that somebody wrote it up.
I know it could probably find its other places, but this is a nice write-up of what all this means.
So in general, people say the recommendation is don't do this.
Don't do relative imports.
But sometimes you have to, and there's a lot of good times.
So for instance, if you were a package maintainer or you're developing a package, the modules within the package should be able to use functions from other modules.
That's why you have them.
But how do you import that?
You don't just, and one of the ways is you, you know, from dot, neighbor module, import something.
And that's what the single dot is, is import a module from the same package you're already at relatively.
Yeah, that's cool.
You know, the other thing that bugs me about when you have a package and sub packages that all interact and you use the full or external import style, if you want to rename that package, you're like, oh, I kind of like would rather call it this.
All of a sudden, there's like lots of pain and suffering that happens.
Yeah.
Well, even within it, if you import it from the top, yeah, you have to go through and change it.
I don't know.
Yeah, exactly.
It's not something I see very much, but I think it's a great article to have it all written up.
Yeah, well, I use the dot, dot.
I guess it's a parent package thing.
I don't really use that.
But the single dot, I use all the time to just say the import something from the same package I'm in to keep.
That way, like you said, you don't have to, if you decide on a different name for your package, you don't need to change that.
Yeah, absolutely.
Very nice.
So this is a good write-up.
Yeah.
So before we get to the next one, which is kind of retro and fun, let me tell you quickly about Datadog.
If you're not familiar with them, you should check them out.
They're especially good for distributed systems, microservices, things like that.
So they're a monitoring platform that brings together metrics, logs, request traces, all in one place.
Datadog has a trace as search and analytics feature that lets you break down your Python app performance by user, by URL, all sorts of cool stuff like that.
So you can quickly, easily troubleshoot and optimize your Python app.
So try that out today with a free trial and Datadog will send you a free cool dog t-shirt.
It's very nice.
Check them out at pythonbytes.fm/Datadog to get started.
The user ID thing, searching on users is kind of cool.
You could maybe line that up if like a particular user had a complaint or something, you could maybe use that.
Exactly.
I get this all the time.
Like, oh, this thing is not working super well on your platform.
I'm like, seems to be working pretty well.
I just don't understand.
But if I could actually dig into it by user ID, that'd be awesome.
Yeah, that's cool.
Yeah.
So I promise to do something retro, right?
Yeah.
I love retro.
Quite retro.
Yeah.
So you should check out, if you feel like making a game, you know, a lot of people get into programming because they were interested in making games.
And that's why they got into programming.
That was not me, actually.
Like, I enjoyed playing games when I was younger.
I sometimes still do.
But I wasn't like, oh, I have to go into computers so I can make a game.
I know a lot of people did.
But the reality of make a game now is get 100 of your, you know, highly skilled developers and artists friends together and work for a year, which doesn't make a lot of sense, right?
Yeah.
So you might make like a cool 2D scroll or retro thing.
And this thing called Pyxel, P-Y-X-E-L, like pixel, Python, pixel sort of thing, is a retro game engine for Python.
How fun.
So the idea is you only get 16 colors.
You get four sounds that can be played at the same time.
It's a Python 3 run game platform.
It runs on all the major platforms, Windows, macOS, and Linux.
It even comes with a bunch of cool examples.
So if you pip install it, then you can just run install Pyxel examples.
And then you can go and explore them.
But what do you think?
Looking at some of the screenshots there.
It looks kind of fun.
I got to try to check this out.
Yeah.
You don't have to be like massively skilled to create the graphics because you only get like a few colors.
You only get like a certain size.
It's not, you know, you don't have to be crazy artistic game studio type place to make this.
Yeah.
These are the types of video games that I grew up on.
So yeah.
Yeah.
I think people might enjoy this.
And like I said, I think it makes it pretty accessible.
It's an interesting way to bring UI capabilities to Python for people who might want to, like if you are doing some sort of programming class or you're doing, you know, like a school club or an hour of code type of thing.
An hour of code is probably too short.
But, you know, those types of projects where you want to let, especially kids who are impatient and don't care that much for terminal apps and are not ready for web apps, like they could build a fun little thing if you gave them this as a foundation.
Yeah.
Each house.
So cool.
Yeah.
If people are into retro games, check this out.
You can create your own with Python.
What if I don't want to create a game?
I just want to create a command line interface.
You mean like most apps?
Yeah.
So that's, you could even make your game have command line interfaces.
Yeah.
So there's a couple of options, right?
You could use sys.argv.
That'd be pretty awesome.
That's pretty extensible.
You could also use higher level things like argparse or click, right?
Click.
Yeah.
What's up with click?
I know there's a lot of great options and sometimes you just reach for what you know.
And since I've written a few command line interfaces from the sys.args and not enjoyed it, I have enjoyed working with click.
And so click's been around for a while.
But the news, really, I wanted to highlight it because it's cool that the click version 7 was released recently.
And there's a huge list of, I mean, normally we don't just cover a version update of something just for the heck of it because things update all the time.
Except for click doesn't update all the time.
The last version of click was released January of 2017.
So that's neat that we have a new one.
So there's all sorts of fun stuff in here.
I don't know what I'm really excited about.
There's ZShell auto-completion support that was added.
That's kind of neat.
That is quite cool.
I use ohmyzsh, which I love.
And this is really exciting for me because it's based on ZShell.
One of the other things is click interfaces have, they include a help option.
You can do --help and it tells you what the options are for your command line interface and how to call it.
You have to build that sort of stuff in, but it's pretty easy to write up.
But one of the things they've added is that if you do it wrong, it doesn't tell you, it just says this is wrong or something.
It doesn't tell you, it doesn't point to the help.
But now it does.
So in this version, any usage errors will now hint at using the help option, which is cool.
Yeah, I like it.
And actually, there's pages and pages and pages of updates.
There's a lot of stuff that changed.
So good job, folks.
And I didn't realize it was part of the Palettes project, which is also Flask, the people that work on Flask.
Yeah, yeah, it's part of Palettes.
And you talked about how it hasn't been updated in a while and this is a major release.
Like Flask just went 1.0 and we talked about that a little while ago as well.
That's pretty awesome.
Yeah.
And I know that the Palettes people, they take donations for if you're utilizing this and want to help out.
They would love to have your money.
They would.
They have a special arrangement with the PSF.
So it's sort of a nonprofit thing as well somehow, I think.
Yeah.
And nice people too.
Yep, absolutely.
So this is cool.
I'm glad you highlighted it.
I want to understand the ZSH autocomplete a little bit more.
That's sweet.
So, Brian, do you use the cloud much?
I think so.
Well, we live in Oregon, so we get lots of clouds.
Oh, yeah.
We, like, definitely use the cloud at least half the year.
Yeah.
No, so.
That was a really bad joke.
It's a pretty good one.
Yeah, I liked it.
So one of the challenges of especially, like, platform as a service and things that are not infrastructure but other stuff, database as a service and other higher order things, is that you often pay, like, as you use them.
Right?
And, like, if I use a virtual machine, I turn on the virtual machine, I know what it costs.
Right?
Like, I go to DigitalOcean, fire that thing up.
I know, like, the server that runs Python Bytes plus the database server.
I think they cost $15 a month together.
Right?
I know it's $15 pretty much other than bandwidth, which is mostly covered.
If you use something like, say, Firebase or AWS Lambda or other things, like, you pay as you use it.
And generally that's to your advantage.
Right.
But the you isn't really you.
The you is your users are using it.
Right.
And you don't necessarily know how much your users are going to use it.
Right.
I mean, it's a good problem to have.
Like, I have lots of users.
They're using my app a lot.
So I'm using my cloud service a lot.
But it's super, super scaling.
And it turns out that if you program badly, you may have a higher bill than you otherwise expected.
Yeah.
So here's an example, which I think is just maybe a cautionary tale for everyone using clouds.
And it doesn't really too much depend on, like, what cloud you're using.
Anything that where the price depends upon user consumption.
I have a real world example for myself.
I'll tell you about it at the end.
But the article I want to cover here is the title is how we spent $30,000 in Firebase in less than three days.
Wow.
And Firebase is like a database as a service exposed over, like, HTTP endpoint for JavaScript type of thing.
Like, that's pretty much my understanding of it.
I don't really use it.
But it's like if I'm doing, say, an AngularJS or some kind of front-end JavaScript app, I can, like, just connect to Firebase straight from my client-side code.
And then we're good.
It can do the various things that it needs to do.
Right.
So there's this place called Vaki, something like that, in Columbia.
And it's, like, kind of like Kickstarter, but Colombian.
And they had just launched.
And it turned out that they had this project on there that became the largest crowdfunding campaign in Columbia by, like, collecting three times as much money as anyone ever had in the first two days.
So they collected tons and tons of money.
They had, like, 2 million sessions, like, 20 million page views, 15,000, like, backings or whatever you call that.
Sounds good, right?
Well, it turns out the site was running really slow.
And the folks who built it, they were somewhat new developers.
They were like, I don't know what to do to make this work.
I know what.
Let's just upgrade all the frameworks.
We're using Angular 4.
Let's upgrade to Angular 6 or something to this.
It wasn't Angular.
Maybe it's React.
I don't know.
Whatever framework they have, they're just like, we're going to upgrade these things.
Nope.
That didn't fix it.
Right?
So they spent, like, a day, like, poking around.
And it was still running slow.
And it kept slowing down more and more.
They couldn't figure out what's going on.
And they logged into their Firebase account.
And they saw their bill was, like, $30,000.
It was costing $600 an hour more every hour.
Oh, wow.
Yikes.
And they're like, what is going on?
So it was like, you know, like, Firebase, you pay on, like, the number of calls and type
of thing.
So it turned out that they have this little part of the site, just like in Kickstarter, in
the right, it says there's this many contributions.
And currently, this much money has been, like, pledged towards this account.
And I think what happened was their implementation of showing that number, it didn't, like, summit
in the database.
It, like, sucked down all the payments table.
And then, like, added it in JavaScript.
And it kept doing that to, like, keep it live or something.
Yeah, every time somebody goes and looks.
Ah, yeah.
Yeah, exactly.
They made, like, 40 billion requests, billion with a B, to their, like, database.
And that got them, like, a $30,000 bill.
Yikes.
So it's pretty interesting.
Worth checking out, this article.
The comments are super interesting.
Some of them are super supportive.
And others are kind of mean.
You probably wouldn't imagine this.
But there's a theme of testing.
They should have tested better before they rolled out the site.
Well, yeah.
But you can't test everything and foresee.
Yeah, you can't foresee everything.
That's true.
Right.
And I'm sure it seemed fine when you tested it with, like, the 10 purchases they had in
their little test project.
But you put, you know, 15,000.
All of a sudden, it starts to behave badly.
Yeah.
And I heard about somebody doing some things, like, similar, not a success story, really.
Just somebody saying that they would run kind of some abuse testing against a local database
or local mock service.
And then set it all up.
And they were going to just see how it did for abuse testing over the weekend.
Got back and realized that they were not testing abuse testing in the lab.
They were abuse testing the live service.
And, yeah, similar issue.
A big, huge AWS bill because of the test running all the time.
So auto skill is amazing.
It just takes care of all the traffic you have.
Yeah.
Wait.
What?
How much does this cost?
So I was thinking about this article, like, a few weeks ago.
I'm thinking we might cover it on this episode.
And I'm thought, ah, good thing this doesn't happen to me.
Never do this.
Today.
Remember, I don't know if I told the audience this, but I know I told you this when we were
hanging out at PyCon last year.
Like, for my courses, I set up a whole bunch of different video servers throughout the world.
So I've got, like, one in Mumbai, one in Tokyo, one in Sydney, one in Frankfurt, and so on.
Wow.
And I got tired of synchronizing the files.
Yeah.
So I wrote this system that would automatically sync them across the world to these different
locations.
Well, it turned out there's a small find and replace that has to be done to adjust the
location from the source to the destination servers.
And I logged into that thing today, and it was still synchronizing just continuously.
I'm like, oh, no.
This server has been continuously downloading and uploading to S3 as fast as it can for two
weeks.
Oh, no.
I'm like, what is my AWS bill?
And I logged in, and it wasn't so bad.
It was, like, $300 more than normal, which is okay.
But I'm just like, yeah, that pretty much is exactly just a less bad version of what
happened to these guys.
And it was because of bad, it was a bad file replacement.
Basically, sync, the word sync was being replaced in some circumstances.
And I have a new course called Async.
And it was taking out the sync part.
And so it just, it kept going, oh, the file's not there.
We've got to upload it.
File's not there.
We've got to upload it.
You know, because they just, they mismatched.
Yeah, that was bad news.
Oh, yeah.
Anyway, so it can happen to anyone.
It happened to me this morning.
I fixed it, by the way.
Well, yeah.
If you're paying for any of those services, check once in a while to make sure that.
Yeah.
And you know what?
I actually, I have, that's kind of one of the takeaways, both from the article and from
why I wanted to say that, is I have an alarm set at AWS.
And it says, if my bill goes over this amount, send me an email.
If my bill goes over this amount, send me an email.
And I woke up and I saw that alarm as well.
I'm like, oh, that's not good.
Yeah.
So anyway, it's all fine.
But check it out.
It's definitely worth thinking about if you do anything that is in the cloud that is based
on consumption by users.
Yeah, definitely.
All right.
Well, that's our main items.
I have a really exciting one.
I wanted to get in, but actually, I just learned about it 15 minutes before we started recording.
So I didn't have time to dig into it.
So news is, Dropbox, Dropbox is one of the biggest users of Python, as we know.
And they have been stuck on Python 2 for what seems like eternity, which is so ironic because
Gita Van Rossum works there.
And some of the other core developers that work there is like, yeah, Python 2 all day.
You know, got to love it.
Right.
So the big news is, as of yesterday, Dropbox is now upgraded to Python 3.
And they have like a nice article right up on it.
We'll cover it in more depth next week.
But I'm going to link to it now since it's timely and important.
That's so cool, though.
Yeah.
Very neat.
Yeah.
What about conferences?
Well, we just got an announcement.
I think I just saw this today that the call for proposals for the 2019 PyCon is now open.
Oh, really?
Yeah.
That's pretty awesome.
So you can get started on your proposals for next year.
Yeah.
I'm thinking about those for sure.
I definitely have some stuff I want to propose.
So thanks.
Yeah.
See, I learned about stuff right here on the show.
All I got to do is just sit here.
Yeah.
And the PyCascades is still open, too.
Yeah.
Until October.
Yeah.
So it's proposal time, I guess.
It's definitely proposal time.
Also, PyTennessee.
I can't go, but I know that they have their call for proposals open as well.
So there's lots of conferences.
You know, conferences are a spring-summer type thing a lot of times.
And so the call for proposals are, you know, sort of now.
Yeah.
I mean, you know, why not spend your holiday season coming up with things to...
Yeah.
That's what I'm doing on Thanksgiving for sure.
Maybe Halloween as well.
My kids will love it.
You know what's scary?
This talk's going to be scary.
No, Dad, I want to get candy.
This is even better than candy.
No, if you wait until Halloween, you'll miss the PyCascades.
You got to do that before.
That's true.
Yeah, that's true.
I can't do that.
All right.
Anyway.
No, I won't wait.
You got one more?
Worse?
I got one more.
So I just released, like, literally an hour and 15 minutes ago or so, released a new course
called Async Techniques and Examples in Python.
And this one is something I'm super excited about.
I've been wanting this course to exist ever since I started in Python.
And I've decided that I'm going to put in the time to create it.
And so I just launched a five-hour course on all the async things in Python.
Oh, that's very exciting.
Because I want to learn all the async things in Python.
So I'll have to check that out.
Well, I have a resource to recommend.
Yeah.
So I put the link in the show notes.
People can check it out at training.talkpython.fm.
Should be in the course list.
Nice.
Cool.
Yep, definitely.
All right, Brian.
Thanks for being here and sharing this with everyone.
Yeah, thank you.
You bet.
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.