Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 94, recorded September 5th, 2018. I'm Michael Kennedy.
And I'm Brian Okken.
Hey, Brian. How are you doing?
I'm doing really good. Yeah.
Excellent. Doing very well. The sun is shining. Summer has not left us yet.
It's not that great for productivity, but it's definitely good for keeping the spirits up.
You know what else is keeping my spirits up is my DigitalOcean servers, the ones running this site and many others.
They've been working perfectly. So they've been going really, really strong.
And we'll tell you more about them later.
But in the meantime, if you want to check them out, pythonbytes.fm/DigitalOcean, get $100 credit for new users.
Brian, when I was in the C++ world, the C# world, design patterns were like this massive thing.
And you had to know all the design patterns.
And there was like dependency injection and IOC containers and all this stuff.
And I feel like Python doesn't have as much rigor around it because you don't have to jump through so many hoops to make certain things happen, I guess.
What do you think?
Yeah, I think so.
And it's actually something that's interesting because I came from the C++ world.
So patterns were a thing in C# also?
Oh, yeah.
Okay.
Well, I don't even know who the gang of four are.
But there were four authors that wrote the design patterns book.
Let's see.
Eric Gamma, Richard Helm, Ralph Johnson, and I'm not going to try to pronounce that last one.
John something.
Anyway, gosh, in the 90s, if you were in C++ or C#, apparently you read this book or others around design patterns.
And then when I got into Python, I was a little curious whether that was a thing in Python or not.
But I haven't really heard much other than I haven't really needed it.
A lot of this stuff isn't really needed.
What I think is interesting is there's those patterns that you see from the gang of four and the sort of derivative ones, derivative books and thinking.
And a lot of it, like you say, is not needed.
But there are other patterns that are really useful and come in.
Like, for example, meta classes, for example, or decorators.
Or there's other stuff, right?
Generator methods.
All sorts of stuff that is in here that don't appear in the gang of four because C++ or Smalltalk just didn't do that.
They were highly based on Smalltalk, actually.
Their patterns.
Right.
Well, one of the things that caught my attention today was a tweet by, gosh, who's this guy?
Brandon Rhodes.
Brandon Rhodes, yep.
And he's doing, he's got a site called pythonpatterns.guide.
And it has, he's sort of going through a lot of different, I think he's going through the gang of four book.
But he might be also doing other, pulling together other design pattern things that he's talked.
Yeah, he's pulling together information from talks and writing.
And I think he's creating more information, too.
But there are a whole bunch of these, trying to apply some of these patterns to Python.
And kind of sometimes different ways to do it.
So you can do things in different ways.
And so far, he's got abstract factory pattern, the builder pattern, factory method, composite, decorator.
Yeah, we definitely have decorators.
And then things like monkey patches and iterators, things like that.
And how that applies, I'm glad that somebody that knows what they're talking about is trying to figure out, how does this all apply in Python?
And I haven't really dug too much into this.
I just think it's a neat resource to try to read about some of these.
Yeah, I definitely think it's a really neat resource.
And Brandon has some interesting thinking on design patterns and architectures.
He gave a super counterintuitive talk called Clean Architecture.
I think it was at Pi Ohio a couple years ago.
And when I first started watching it, I was like, I just disagree with everything you're saying.
This just seems so wrong.
And then after 10 minutes, I'm like, but wait a minute.
I think it's right.
I think I've been thinking about this all wrong.
And it really caught my attention because I didn't agree with it so much.
But then I'm like, wow, this is really compelling what you're telling me.
So maybe I need to rethink what I'm thinking.
And whenever I have that feeling, I'm like, whoa, I need to pay attention because I might learn something really good here.
Yeah, so that's a good point.
I'm not necessarily saying, since I haven't really dug through this too much, I'm not sure.
I mean, I respect Brandon as a smart guy.
I expect that there's some really great stuff in here, but you may not agree with all of it.
So we'll try to dig up a link to that Clean Architecture too because that sounds interesting.
It's super interesting.
Yeah, yeah.
It's definitely a good one.
Cool.
Well, thanks for bringing this up.
I love these Python patterns.
And I love sort of the how would these traditional, more formalized patterns actually look in our language.
And there's a lot of interesting examples there.
Yeah.
What do we got next?
Well, we got this thing called Arctic.
Arctic.
Arctic is an API framework over top of MongoDB and Pandas.
And the idea is this is a thing that's been around since around 2012.
And its sole purpose is analyzing time series data super fast.
So one of their headline is basically Arctic millions of rows per second of time data in Python.
So that is really quite impressive.
I can tell you a lot of the ODMs and ORMs and stuff.
They don't do millions of records per second.
So the idea is that it basically bakes in pandas and numpies and all those kinds of things.
And it has an underlying data store that's backed by MongoDB.
And it actually uses the binary low-level communication.
So instead of trying to store all the data and then bringing it back and deserializing each row,
I think what it does is it actually just stores the binary data of pandas.
And it'll pickle numpy arrays and stuff like that.
And just exchanges the memory structure and just pulls it straight back and go,
yep, here it is.
Let's look at it.
And it's pretty cool.
Yeah.
Yeah, definitely.
I mean, there's a lot of applications that use just huge amounts of time series data.
Yeah.
So they say the two big areas they think it's useful is IoT, little tiny IoT devices that maybe Python is running on,
and financial analysis.
So it's sort of been extracted out of the work that this financial company called MAN, AHL,
I've never heard of them, but I think they're mostly an Asian company, but also in the U.S.,
around investment and so on.
So they've been working on this.
And they actually have some numbers on how this thing performs relative to other types of projects that they pursued or other things that were available.
So they talk about the different kinds of data that they store and analyze for stock trading and analysis.
And they say, look, we have this sort of data that's for one day, a whole bunch of it, maybe 10,000 rows.
And they can work with those 10,000 rows in four milliseconds.
And they say, compare that to what we were getting out of SQL Server, which was 2.2 seconds.
So, you know, 500 times slower, which is pretty incredible.
And they have this other tick data, like, you know, the stock ticker type of data.
They can say in one second they can process 3.5 megs worth of that data in Python or 15 megs in Java.
And there was some other project that they were trying to improve over called OtherTick, which took like 40 seconds versus one.
So really, really interesting, high-performance, database-backed time series.
Neat.
Yeah.
So if you're into Pandas, NumPy, and you've got to store and query a bunch of time series, whatever the reason, this is probably worth checking out.
And it's also tested with pytest, which is pretty cool, right?
Well, of course.
Any real project is tested with pytest.
That's right.
Of course.
So one of the things I really like about the Python community is the fact that there's so much sharing of information out of conferences and meetups and things like that.
So we have another thing you found here for PyCon, right?
Yeah.
So the PyCon – I don't remember when it was, but PyCon Australia wasn't too long ago.
And they've already got all the videos up.
And we have a link to the PyCon Australia videos.
And I've got quite a few of them queued up that I'd like to listen to and watch.
I'm kind of bad about videos, actually.
I often just listen to them and then go back and look at the slide parts of information that I wanted to capture.
But I like listening to talks as well.
But there's one from Mark Smith, which he always amuses me because his Twitter handle is Judy2K.
And he won't tell me why.
But his talk is how to publish a package on PyPI.
And that's the one I've watched so far.
There's a lot of great talks there, though.
But I think this one's a great one that it – the end punchline is use cookie cutter.
But he blasts through not using cookie cutter, all this sort of stuff you have to do to get up.
And, you know, it's – every little piece makes sense and it's not difficult.
But there are a lot of different little pieces.
But he goes through this entire thing in like less than half an hour.
And so that's pretty impressive to watch him talk about all the different pieces and why they're there and what they're used for.
So that's a good one to sort of understand what's going on in the packaging world in a very short amount of time.
Oh, that's really cool.
Yeah, there's a bunch of cool ones here.
A couple in MicroPython, actually.
So one writing fast and efficient MicroPython code.
And the other is async.io in MicroPython.
Both of those are pretty cool.
Kind of tie into what we were just talking about previously.
Yeah, and then there's like – gosh, there's solid APIs and there's – it looks like a lot of good stuff.
And I know that Australia is – since it's a big travel burden to other places, other PyCons, you'll see some speakers there that you're not going to see other places.
So that's cool.
Yeah, absolutely.
And they have 88 videos.
So that's pretty solid.
Yeah.
Quite cool.
That's a good one.
So before we move on, I'll tell you about another cool thing, DigitalOcean.
All right, so I'm a big fan.
And so one of the things that they've released – we talked about this just a couple of times, not very much – is this idea of projects.
So when you go into your name, your cloud provider, you might have a bunch of servers, a bunch of ESP storage type things, virtual storage blocks, load balancers, all sorts of stuff.
And it's really hard to know what goes with what.
Do you have a staging environment, a production environment, all that kind of stuff, right?
So how do you organize that?
So DigitalOcean has come up with this feature called projects that lets you group things like your droplets, that's virtual machines, and floating IPs, and back storage-like spaces into these different use cases.
So you know, yeah, actually, we're done with this project.
So we can turn that server off and destroy it and not like the fear of, I don't think we're using this one, but I'm not going to destroy it.
I'm not going to delete it because what if I'm wrong, right?
So a very cool feature you can take advantage of for all of their stuff.
Check them out at pythonbytes.fm/DigitalOcean, and they'll give you $100 credit for new users.
That's awesome.
Hey, let's talk about another cloud provider.
I'll write it on the back of that.
So one of the ways that you can run your code on the internet is like I just described with DigitalOcean, like I do for our stuff, is to create some virtual machines and various other pieces and sort of use it as so-called infrastructure as a service, right?
IaaS.
But you might also use platform as a service, like here's my code, run it.
So Google App Engine, Heroku, those types of things.
Okay.
So Google App Engine has a pretty interesting announcement, and it's interesting for both it's good now and like, oh my gosh, I can't believe it was like that.
So the announcement is that Google App Engine has released their second generation runtimes, which the Python one is now based on Python 3.7.
That's pretty awesome, right?
It is.
You want to run some code.
Boom.
Here's my Python 3.7.
So that's really good.
You might think, oh, Michael, what was the previous one?
3.6?
3.5?
No, I believe the previous one was 2.7.
Oh, no.
Until now.
Like if you were using Google App Engine, I believe you had to use a legacy Python, period.
Until that was like mid-2018 that I just said that.
That wasn't like a statement around 2012 or something.
That was just now.
But let bygones be bygones.
And now it's Python 3.7, which is pretty awesome.
So apparently it's a pretty big upgrade.
You get a bunch of new things.
Like, for example, it's based on their new sandbox container, sort of Docker-like things.
It removes a bunch of restrictions.
Like, in addition to only running on the old Python, legacy Python, you could only use a white-labeled set of packages.
And now in the new Google App Engine, you can use arbitrary packages.
Just put them in a requirements file, which is pretty sweet.
That's a big change.
It is a pretty big change.
Yeah.
So a lot of cool things like autoscaling and things that are a little bit easier as well.
So anyway, if you're interested in Google App Engine's platform as a service for Python, it just got many, many times better.
Yeah.
Neat.
Yeah.
So, Brian, I typically write my code in Python files, not really in notebooks per se.
How about you?
Yeah, mostly in files.
But I'm trying to learn Jupyter Notebooks some and utilize them.
They're kind of fun, especially in data science-y realms or looking at plotting data and stuff.
Notebooks are fun.
Yeah.
But there was a person named Joel Gruse that says he does not like notebooks.
And Joel is notable because he's not like a random dude on the internet.
But Joel Gruse has written a book called Data Science from Scratch.
He's done a lot of work in data science, things like that.
I've even had him on Talk Python many moons ago.
Yeah.
And this wasn't just like a one-off comment.
He gave this talk at JupyterCon.
And that's kind of hilarious.
But the video for that is not available yet as far as I couldn't find it.
So because that was just recently or still going on, I'm not sure.
But the slides are up.
He put the slides up.
And for one, it puts me to shame.
You know, this presentation has got so many animations and pictures and stuff.
Plus, it's like I haven't even got through it yet.
It's like 100 pages long or more.
But it's really good.
But it's a serious discussion about some of the issues with the problems with notebooks that people new to notebooks don't quite get.
And people old to notebooks just sort of know it and don't really think about it anymore.
And one of the big ones is that there's hidden state.
And so, essentially, we think of files as, like you said, we normally work in files.
So they get run from top to bottom, except for, you know, functions don't get run.
They get interpreted as functions.
And then when they are run, they run top to bottom, essentially.
And notebooks are not like that.
You can jump around and execute different bits of code in different orders if you feel like it.
And that stateness can lead to weird, confusing things.
So it's just like a gotcha to know about.
And then he goes on to talk about some of the issues where if you start learning how to code with notebooks, you may end up, you know, developing some bad habits like importing notebooks instead of just trying to.
I mean, like, that's a thing apparently you can do is you can define some functions in a notebook and then import them into another notebook.
Well, I mean, wouldn't it be better to just put them in a different library, in a package or a library?
Use the package, use the library.
Exactly.
Yeah.
So some of those, and, you know, I'm highlighting this not because I think notebooks are evil, but because I think it's important to start to listen to people saying, you know, listen to a voice that says they aren't a silver bullet.
They have their issues also.
And we just need to be careful and talk and make sure you don't fall into those traps.
Yeah, these are really interesting.
And these are certainly issues to look out for.
And while this is a funny presentation, I cannot wait to watch this video.
Joel, if you're listening, please let us know when it's out or if someone else sees it come out, shoot us a note, either email or Twitter, because this is fantastic.
Yeah.
Plus, also, like, I can't even imagine how long it took to put together this presentation because it's, yeah, there's a lot of animations in there and it's quite a riot.
It is quite a riot.
Yeah.
Anyway, there's that.
Just the other side of maybe notebooks aren't awesome.
Yeah.
It's pretty, pretty, pretty interesting.
So we've had a couple of conversations around the various peps and stuff that have been maybe causing some kerfuffle in the community.
Obviously, the biggest one was a PEP 572 about the in-place assignments.
And that was the thing with all the stress around it that Guido said, hey, after this, I'm, this is my last one.
I've given my all.
I'm out of here.
You guys, it's up to you.
We actually had Brett Cannon and Carol Willing on episode 87 to talk all about that.
Right.
And one of the things that we talked about was what comes next.
Right.
If, if it's not down to Guido to make the final decisions, which is how it has worked, how will the Python community decide, you know, what it's up to?
So, yeah.
So Barry Warsaw has published five peps at least around this.
And I don't think this is a decision.
It's sort of a structure to further the conversation and make a decision.
So he just published not too long ago, PEP 8000, which is Python language government proposal overview.
And I don't know if this is common in peps.
I haven't seen it that much, but it's like a gathering of other peps that are specific details.
So there's PEP 8,001, 8,002, 8,10, and 8,11.
The first two are about voting and ways in which this government might work.
And then the higher ones, the 8,10s are actual proposed models.
And there's a third one in 8,12 that I forgot to put in the notes.
And so there's for the government styles, government styles, we have the BDFL governance model is one of the proposed options,
which is to elect a new person who is the final decider.
Right.
Basically, GEDO step down, who is going to take that place to now participate in that way?
We also have the council governance model, which we talked about interesting things like should there be an even or odd number of people in the council?
And then the last one, I think, let me pull that up.
I think it is community.
Yeah, the community governance model.
And that one's a little more free form.
So these are all different ways of possibly arranging and solving that problem.
And there's a lot of examples like, let's see how Rust did it.
Let's see how OpenStack manages their organization and so on.
So there's a lot of concrete stuff there.
Anyway, that's pretty cool.
Yeah, that's interesting.
If you have a strong thought on this and you want to participate, get in there, make comments, let people know what you're thinking.
Because it's still open.
It's not anything decided.
Right?
It's still up in the air.
So if you want to have a say, now is the time to make statements.
Wow.
It's like government working in our own community.
What?
Incredible.
Yeah.
So this is pretty cool.
I don't know where it's going to go, but I like that it's all laid out like this.
My guess is it's going to go down the council model, maybe with, I don't know.
I think it's going to go down the council model, but we'll see.
Yeah.
I think that whatever they do, they need, they should, if there's a council, they should have to meet together to make decisions and pass around like a talking stick or something.
Yes.
I love it.
Oh, we could come up with something weird that they have to follow.
How about the Python staff of power that you were carrying around?
Yeah.
But then, you know, should it be the blue and yellow one or should it be the green and yellow one?
I don't know.
That is a big question.
Yeah.
I don't know.
So, sorry, green and gold.
So people in Australia say it's gold, not yellow, but it looks yellow to me.
Yeah.
I definitely, I thought that stick was a big hit.
I don't know if people don't know what you're talking about.
What should they Google to find the stick?
I think it's Pythonic staff of enlightenment.
I don't know.
Is that right?
That's got to do it.
How many hits on Google can there be for that?
I don't know.
Awesome.
So, yeah, they should have to pass that thing around.
All right.
Well, that's it for our items this week.
You got anything extra you want to share with folks?
I don't, actually.
Just trudging along.
We got a couple more testing codes out.
Yeah.
Very nice.
How about you?
I've got, of course, some TalkPilot stuff queued up to be released shortly.
I have been recording some courses, which are going to be awesome.
And I'm very excited about them, doing a bunch of stuff in parallel.
So I'll let you know when that's sort of further along.
But I do have two things I want to talk about this week really quickly.
One is we got a message on Twitter.
And I don't have the name of who sent us.
This was John, actually.
Thanks, John.
Who sent us this heads up that Brian Granger, one of the guys behind iPython and Jupyter and
all that stuff from the very early days, is giving a free webcast.
And it's an ACM-sponsored thing.
So it's Project Jupyter from computational notebooks to large-scale data science with sensitive data.
So if that sounds interesting to you, I put the link in there.
It's this Friday.
This episode probably will come out on Thursday.
So you've got to take action right away if you're listening.
There's probably a recording or something afterwards.
You can check that out.
The other thing is, you know, we talk sometimes about the popularity of Python.
Yeah.
So I don't want to beat this one to death too much.
It's not really worth its own item.
But Python continues to climb yet another ranking.
So the TOB index is one of the more well-respected, more long-running ways of ranking programming languages.
And I think when we started this podcast, Python was either fifth or sixth.
I think it was sixth on this list.
It is now third.
Probably because of the podcast.
Certainly partly because of it.
Yeah.
But that may be a very small part or more maybe it's meaningful.
But what's really interesting is it's now above C++, C#, JavaScript.
It's way above JavaScript.
And JavaScript's going down.
It's above Ruby.
It's above many, many things.
What it's not above is it is not above Java or C.
And not only is it not above them, but it's like half.
So it's like 7.6% to C is 15.4%.
It's going to be a long time, if ever, until it gets to a 2 or a 1.
But it's definitely doing quite well.
Yeah.
So, yeah.
What is the TOB index?
Anyway.
I'll have to look into that.
Yeah.
If you look into it, they talk about their philosophy and where they measure stuff from and so on.
It's been a long time since I read it, so I don't remember the details.
But they do lay out where the ranking comes from.
Okay.
Cool.
Yeah.
All right.
Well, that's it for this week.
Thanks for chatting with me, Brian.
Thank you.
Bye.
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.