Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 60, recorded January 10th, 2018.
I'm Michael Kennedy.
And I'm Brian Okken.
And we've got a bunch of stuff lined up for you, as always.
Before we get to it, I want to say thank you to Datadog.
Datadog is sponsoring the show at pythonbytes.fm/datadog.
More to say about that later.
Brian, I want to know who's at nine.
Who's at nine?
Yes, who is at nine?
Wouldn't it be awesome if you could actually just utter this question into the air and have it automatically answered for you?
Yeah, well, that's the promise of Alexa and Google Home and all these home assistants, right?
That's right.
This came up, what was it?
Episode 33 of Python Bytes, actually.
We talked about you brought up building an Alexa skill.
And then somebody saw that.
And we have a link to a Twitter thread.
Yeah, it was Greg Quinlan who posted that on Twitter.
That's cool.
Okay, well, he ran with it.
And he looked into programming both skills for Alexa and Google Home.
And he came up with this who's at nine video that we have a link to.
And it's just, I think it's hilarious.
It's basically the old who's on first routine, but done with an Alexa and a Google Home together.
It's funny.
Yeah, so he's got like a little dot and a Google Home.
And he activates them both and they talk to each other, right?
It cracked me up.
It's good.
We should have like had a clip for it or something for the show.
Yeah, we should just play it.
Yeah, that'd be fun.
One of the things that strikes me, first of all, nice work, Greg.
That's awesome.
Flask Ask is really pretty interesting to work with.
And the Flask Assistant is the Google Assistant equivalent of Flask Ask.
It's like just ported to that API.
But what's really interesting to me is the API here effectively is Flask.
And I'm noticing this in lots and lots of places.
Like someone just sent us something that was almost a web API for the command line.
But I'm noticing Flask being like the de facto API for so many things these days.
Yeah, it must just be that people are just having it's easier to set up a Flask, a small Flask application for something.
I guess.
I mean, pay attention to number four on our picks as well.
We'll come back to this.
There's something coming up related to the Who's at Nine that's on Talk Python, right?
Yeah.
So I have three guys, a panel discussion, who are all involved in building Echo Assistant type things.
Some of the people behind Flask Ask and some of the people behind Flask Assistant.
Those are sometimes the same people on Talk Python this week.
So it should come out just about the same time this episode comes out, which is pretty awesome.
So if you really like this and you want to dig into it, check out talkpython.fm/146.
There should be a whole lot there.
That's cool.
Yeah.
I'll check that out.
Sounds good.
Yeah.
So I came across an article that I think it's pretty interesting because you and I have been
singing the praises of Python, how it's really, really popular.
It's becoming quite the important language in so many ways, right?
We talked about the incredible growth of Python, things like that.
But I guess this struck a chord with me because I feel like one of the places where Python really
falls down is this sort of the intersection of packaging for delivering an application to
non-developers or non-servers or packaging, and especially in that area around UIs, like
native UIs.
Yeah, definitely.
We don't have that really.
It's not as obvious what to do.
It's not obvious.
There's a few like half solutions.
They sometimes work, except for when they don't.
And, you know, it's the thing that I ran across that made me sort of bring this up again.
And it's not that I think Python completely sucks because it doesn't have it.
Obviously, I don't think that.
But I see it as a major weakness.
And if we could solve this challenge, I feel like it would just make Python even stronger
and reach even deeper into like big enterprises that have to have desktop UIs and things like
that.
So the article I found is called Retiring Python as a Teaching Language.
So this is by James Higg.
And basically he said, for the last 10 years, my advice for someone getting started programming
is to say, guys, start with Python.
That's awesome.
But then he wrote this article to say, actually, that's not my belief anymore.
That's kind of sad, right?
It is.
And it seems, okay, so his big beef really is part of this not being able to do the user
interfaces like desktop applications easily with it.
Yeah, absolutely.
And mobile as well.
I mean, these kind of are sort of cousins.
It says, it's all great.
People work with Python when they're getting started and so on.
But then one day the student will innocently ask, instead of running a poker simulator on
the command line, can I just put it on a window with like a button and some cards?
Yeah.
Okay.
So what do you do then, right?
Yeah.
Well, there's TK Enter, but I don't know.
That looks like it's from the early 90s, late 80s.
It definitely doesn't look fresh and exciting like modern applications do.
We have Pygame, but that's only if you want a game, right?
What if I want like an app that I want to...
So suppose I work at like, say, a stock trading place and I want an app that is like across
three monitors and it's showing me the status of all my trades running real time, maybe like
a web socket back to some server as fast as it can be to like completely show the traders
what's going on.
Like, what's the answer for Python there?
Yeah.
Well, I don't want to diss Pygame too much because I know some people have done some
non-game things with it, but I don't really have an answer to that either.
I think that's a big shortcoming.
And if we had a really good answers for that, like some of the other frameworks, like even
JavaScript has really good answers for that, which is kind of bizarre, but like Visual Studio
Code, Atom, those are all Node.js plus JavaScript front-end apps, right?
That's Electron.js.
I would like to see a modern sort of thing for Python.
And I think this is just worth considering.
You know, actually the Twitter thread that we'll link to the Twitter thread, it's pretty
interesting.
If you open up my initial sort of tweet, I don't know if you want to call it a complaint or
warning to the community, but if you open that, you can scroll down and you can see all the
conversations.
And even Guido gets in there a little bit to talk about some of the history, which is pretty
interesting.
And thanks for that.
So I think it's, you know, I just, I don't know that there's a great answer right now,
but I'm trying to inspire people.
I want to play devil's advocate here though, a little bit.
I know that you've said that you have written a lot of desktop applications, but to be honest,
I have not.
I've written a couple little tiny things that I've needed for utilities at work.
There's a whole bunch of programming that is not writing desktop applications.
Oh, absolutely.
And a lot of it services, a lot of it's on the web, or it's just command line utilities,
like you said.
But here's where I think the actual, this is why I think we're underestimating the importance
of this.
If you could open up your editor and it was just, you know, here's a few of the widgets.
I could just drop them in here and I could just put a .app or a .exe somewhere.
And my entire company could just pick it up and run it locally.
How often have you not even can entertain that idea because you're just like, well, that doesn't
exist.
So why would I even consider this weird idea?
Right?
Like we'd probably also see a lot less.
I mean, there's a lot of internal projects that are, they're set up as web applications, internal
web applications that could definitely be desktop applications with a shared database backend
that we don't do it that way because it's not easy to do that.
Exactly.
It's super hard.
But it would be really nice to have some sort of ability to take advantage of the local
application, a local OS.
And maybe you talk to a web service for shared data.
Maybe you just use SQLite locally.
That might be interesting.
But I don't think we do this because it's just like, it's so not working that it's just
like, even if you got the UI working, it's like, okay, well now what do we do for packaging?
Right?
I know there are answers, but they're always kind of tricky.
Right?
So if that was like entirely obvious, the tooling was just like, yeah, of course you do this.
Like how many stores in the, how many apps in the Mac app store would be Python apps?
Right now I bet it's like 0%, you know, like basically, right?
Once you round it, then round it down to the significant digits, right?
They don't exist.
And these things could just open up, right?
If we could somehow as a community get like a really nice cross-platform UI set up.
I agree.
I think some of the stumbling blocks on that are that little thing that you throw in that's
cross-platform.
I know that that's cool, but I don't know if it's necessarily a requirement.
That's true.
Actually, I would say if you had a killer way to build macOS apps, stop.
That would be a huge benefit for Python.
If you had a killer way to build Windows apps, there's still like the majority of, you know,
business people sit down and log in on a Windows machine.
Like if you could do that, that would be an amazing advancement for Python.
So you're right.
It doesn't necessarily have to be.
I mean, one model is what the people at Xamarin are doing.
They basically have cross-platform stuff, but every platform has its own UI bit, but they
have these kind of designer things that help with that.
So I don't know.
I just wanted to put that out there and let people know about this conversation and think
about it.
I think we're having an open session at PyCon on it.
Oh, that would be good.
Yeah.
I think I'm glad we're bringing it up because we do need to hammer on this until it's fixed.
If I look across all of Python, this is like really the place where there's still a weakness
and it would be nice to just like fortify that wall and make it like a perfect place to be.
Definitely.
And like I said, SQLite as a little database, you don't even need a server.
That might be a good choice, right?
Yeah, definitely.
So I came across, well, this is an older interview, but somebody recommended to us that we go back
and listen to episode 201 of the Change Log.
It's another podcast, but there's an interview with the, now I should have looked all these
names up, but the dude that wrote?
Richard Hipp.
Yeah.
Okay.
You're awesome for looking that up.
He started at, he calls it SQLite, which I've never heard it pronounced that way.
SQLite, as in like a meteorite or something.
Yeah.
Or is that mineral?
Yes.
A very interesting way of pronunciation.
None of which I would have guessed.
Right.
So the rest of us know this is SQLite, I think.
That's how I know it.
That's what I'm calling it.
I didn't quite realize that.
So this, this is the database.
If you just say what SQLite three import in Python, you, you get a little single file database.
This is beautiful because it's built into Python.
Every instance, every buddy who has Python has this, so you can just count on it being there
and it runs in process.
So there's no configuration, right?
Yeah, definitely.
And I didn't realize how dang cool the thing is until I listened to this episode that this change log episode.
One of the comments from the interviewers were, was they just assumed it was a starter database that you always eventually have to move over to something else.
And that's not true.
There's as long as your application is not like a web application with extreme client server concurrency, you probably can get away with like a lot of desktop applications are small or the like, if you have a client side part of your application, that could just be a SQLite database and it'll be fine.
Yeah, that'd be awesome.
Yeah.
So if you had like some sort of client side thing that you periodically wanted to sync with a real database, you could store it all in, in SQLite locally and just synchronize that data across some kind of service with your real data.
And that would be a real nice way to take the load off the server, to have a local offline version, all sorts of stuff.
Some things I didn't know about SQLite before I listened to this was that it started its life as a TCL application.
Yeah.
Which is bizarre.
It's very bizarre, but that's what happened.
Well, I guess that's where like TK started, right?
In the TCL world.
But the, also that one of the things that you got to watch out for is that it's not as type safe, it's type flexible.
Yeah, that's what he called it.
When you are changing over to another database and your other database might be a little pickier than SQLite.
So be careful of that.
So an example, you might have a column, which is in the DDL designated as an integer.
And if you passed, if you tried to assign quote seven to it, it would just convert that to seven.
Things like that.
So it's very funky in that regard.
It's kind of scripty like that.
He comes from a background of interpreted languages.
So it makes, and, and weekly typed.
So that makes sense.
It's kind of cool.
Yeah.
I thought that, that interview was really interesting.
Definitely a lot of respect for what he's doing.
He's got some very different opinions and perspectives on open source, on say version control and editors.
I mean, I'm not sure I agree with all of them, but they're certainly interesting to think about.
A couple more things.
The SQL, how there's a page of how SQLite is tested.
And I think it's really cool that they put that out there of like what their checklist is for testing it.
The amount of tests are huge, right?
Yeah.
And then also that the, I didn't realize it was in everything.
Like every Android phone has a, is using it and things like that.
I think iOS as well.
Yeah.
So it's quite ubiquitous.
It's definitely ubiquitous and it's very cool.
And I, I think it's definitely a good place to start.
And a lot of, a lot of times you might not need more than, than that, which is one fewer server to configure one fewer things to patch one fewer thing to make sure the firewalls are all right.
It's really nice to just have that simple thing.
Nice.
So speaking of servers, let's talk about data dog real quick.
So data dog is a monitoring solution that provides deep visibility inside of not just your app, but the infrastructure.
Your app works with.
So within a couple of minutes, you could investigate like say a bottleneck in your code by checking out some flame graphs and dashboards.
You can visualize your Python performance.
And if you go and do their free trial, you'll get a free data dog t-shirt, which has got a cool little dog on it.
So check it out for yourself at pythonbytes.fm/data dog and let them know.
Thanks for sponsoring the show.
Yeah.
Thank you.
So I told you about Flask being this sort of like API that is standing in for all these other, other places.
So the next thing I wanted to cover is serverless programming.
So there was this joke, which I actually don't agree with.
I kind of slightly disagree with it philosophically, but the sort of making fun of cloud computing saying, well, that's just another person's computer.
There is no cloud.
It's just another person's computer, right?
That you're borrowing.
Isn't that true?
It's technically true, but my disagreement is like the cloud computing stuff really has to do with a hardware that you can basically create and control through programming.
So if there's an API that you can say instantly, I want a machine.
I want to scale my machine.
I want to replicate my machine.
That's not the same as just like co-location or like a rented server.
Because you can't just go and like rent a server and then hit an API and have like another server.
So anyway, that's my disagreement a little bit.
But to some degree, that's true, right?
Well, we've moved beyond that joke to a farther world of potential ridiculousness where we have server-based programs that have no servers, right?
This whole AWS Lambda, Azure Functions, serverless programming.
It's kind of funny, right?
Yes.
So basically, the idea with this serverless programming, whether it's AWS Lambda or Azure Functions, is you write a single function, preferably in Python, but often they support JavaScript, C#, things like that.
And that single function is the entry point into some piece of functionality.
And you're going to host that function on the cloud.
And it's up to the infrastructure to figure out like what Docker container to create, run that on, make that happen, scale it, etc.
You just say, here's literally a Python function and its dependencies run that.
So that's pretty interesting.
And the main reason here that people go for this, one, is there's no server at all to maintain, not even a virtual one.
And the scalability is basically infinite.
And the price is like insanely cheap.
Because you only pay while your function's literally executing.
Okay.
But I mean, there's still servers.
You just don't have to set it up.
Yeah.
And your code is not stuck to one of them, right?
Like every function call basically, I think, is a new Docker container.
I'm not entirely sure about the internals.
But basically, every call is like an isolated execution.
And then it goes away.
That's part of the appeal also is that you don't really have to care about that.
Yeah, it's totally the appeal.
The infrastructure just deals with it.
Yeah, you do pay for a small latency on every request because it's got to like spin up this bit.
But that's still for a lot of things that are not super performance critical, at least in the latency, it totally would be fine.
So what I wanted to talk about this week is this thing called Chalice, a Python serverless micro framework for AWS.
So basically, this is a Flask API.
Another Flask API.
So you implement these functions in Chalice.
And you decorate them with this Flask API.
But instead of running a Flask app, you create a Chalice app.
And then you can even say like Chalice deploy and run it.
And then you just go and basically request your thing.
So what you effectively create is something that looks like a Flask app with all the different pieces that are related and so on.
But then they're hosted as individual function calls on the serverless infrastructure.
So it's pretty cool, right?
Wow.
Okay, that's cool.
Yeah.
So I think this is really interesting.
So this is just like we're going to take Flask and put it onto AWS Lambda, which is pretty cool.
Maybe the other counterpart that I know pretty well is Zappa.
So Zappa is, I believe, its own framework.
I don't think it has a Flask variation.
I could be wrong.
I haven't done that much with it.
But Zappa also lets you basically create this API against this website equivalent scaled out across these different functions.
Yeah.
So pretty cool things to be playing with.
Like you don't even need cloud anymore.
Now you don't even need servers.
It's all serverless.
Yeah.
So you still, I mean, of course, you still have to set up like an AWS account and get your token or whatever to hook into this, I assume.
Yeah, exactly.
You've got to get your own token and all those things.
And yeah, you probably are talking to like some sort of hosted database or S3 or some combination thereof to actually do your work, right?
Right.
And actually, so I've never worked with AWS, but these sorts of things make me kind of want to try because it doesn't look scary at all.
Absolutely.
So let's wrap it back to item one.
When you create your Flask skill, your Ask Flask stuff, and when you work with Alexa, one of the main ways to work with Alexa is to actually tie, see?
See, she's speaking to me now.
To have her, you could tie those two Lambda functions, these serverless functions.
So actually, you could put it all together like that.
Neat.
Yeah, cool.
Definitely.
So I think you can probably help some people with job interviews coming up here.
First, how do I reverse a string?
Second, what's the fastest way to uniqueify a list in Python?
Reverse a string?
Yes.
This is a short little thing, but there's a blog article called The Fastest Way to Uniquify a List in Python greater than or equal 3.6.
So basically, 3.6, unless you're running 3.7 already.
I just appreciated the, instead of having just an article that says, okay, here's the answer.
There is a discussion of the different ways you might do it and the code for how he timed it.
So you can reproduce all of, if you don't believe it, you can reproduce all the code and get your results on your machine.
It's probably similar.
The short answer is, if you want to keep the order in place, you simply do a list of a dict from keys of your sequence.
And we'll have this in the show notes, of course, and a link to the article.
And if you don't care about the order, then just convert it to a set and then a list.
So that's it.
And I've used the list set before.
And I was actually, I mean, it makes sense that from keys works.
I've never really used that before.
So that.
Yeah.
And it's going to get interesting with the promises of dictionaries being ordered.
You could actually get some of these to be a little quicker, right?
But still preserving the order.
Well, isn't that the way it is now?
Not all.
Like some of them, there's like two graphs that says not order preserving functions and then order preserving functions.
And right now they have list of set of list.
Not order preserving.
Right.
Because set isn't an order preserving thing.
So, yeah.
But it's pretty cool, though.
Pretty cool.
Definitely worth thinking about all the different ways and seeing the tradeoffs and so on.
Okay.
All right.
So I want to wrap up this episode with leaving some people with homework.
They've got some research and some chilling on the couch watching some Python videos.
Okay.
So there's two sets of conference videos that came out.
And I'm sure there's some that I've missed.
But these are the two that stood out to me recently.
Pi Texas and PiCon Australia both have their videos up.
And I linked to the playlist on YouTube for both of them, which is pretty cool.
There's, you know, like always like 40 or more videos.
There's tons of really interesting stuff.
But I kind of wanted to touch on some that I, these are not necessarily endorsements.
These are just like, these look really interesting to me.
And I'd like to go watch them.
I haven't spent all this time watching all these videos just right now.
But from Pi Texas, there's a talk on MicroPython.
Which MicroPython is really, really cool.
Right?
You can run your Python on like a $5 microchip and hook your Lambda functions, your Python ones, up to like hardware interrupts.
Like that's just the coolest.
And then there's so much talk about machine learning and AI and all that stuff.
So there was a talk given there called, What is Machine Learning Anyway?
Or something like that.
So like a foundational background on machine learning, which is cool.
And another one is C for yourself with the letter C, not S-E-E.
So like trying to explore the internals of CPython.
And then there's one on Python and .NET for this thing called Python.NET, which is not the Iron Python that's been around for a long time.
But like this newer way to try to integrate those things.
So all the people that work on the big enterprise apps in C#, they can now plug in some sweet Python or vice versa.
Yeah.
Okay.
Those all look good to me too, especially the MicroPython.
Yeah.
The MicroPython is great.
So that's in Texas.
And then Australia.
I don't know.
Those guys were killing it with names down there.
They just really did a good job.
And there's so many.
I have more I pulled out.
So I'll go a little quicker.
Gradual typing.
Right?
We've talked about that, the typings and adding them and stuff.
And I think this is probably a really interesting survey that.
Hot reloading Python web servers at scale.
Ooh, that sounds nice.
Yeah.
That sounds like a lot of cool internals.
Prototyping Python microservices in production.
And secrets of a WSGI master, like understanding the base HTTP protocol.
And then another one.
Python 3 for people who have not been paying attention.
So that's not anybody that's listening to this.
Exactly.
They know about legacy Python.
Come on.
Then identity 2.0.
What, what, why, and how of social and federated logins.
So if you've got to do anything with like identity across providers, that's so painful.
This would be cool.
And then here's a sort of a Tesla reference.
I'm guessing Python ludicrous mode with Django.
So ludicrous mode in the Teslas is like, you know, like the insane amount of power.
Like, you know, give you a neck ache if you hit the gas yard sort of thing.
So something to that effect.
And then finally, scaling down.
We often talk about scale up and all this complexity you got to deal with.
You even talked about how you're not Google.
You're not Facebook or any of these things a while back, which was cool.
But this is, if you do have one of these large sites that's got a complicated architecture,
let's say a Redis back-end message queue type thing and a database and a whole bunch of other
stuff, maybe some of those are hosted in the cloud.
Like, how do you actually develop that locally also?
That's cool.
That's definitely a need for everyone, I think.
I'm sure there's a lot of good lessons in there.
So the links to both of those playlists are up on the show notes.
So that should be fun.
All right, cool.
All right.
Well, how about you?
Any other news?
We're out.
So that was six.
Cool.
You've actually been crushing it lately.
I've been so busy.
It's been so fun, though.
Yeah.
So last week, I released my Everything Bundle where people can get all the courses, right?
And so I shipped my first course for that Everything Bundle called Mastering PyCharm,
which, yes, it covers PyCharm, but it's also basically like a little mini course on like 16
different parts of software development.
So there's like a little tiny 20 minute thing on refactoring and a 15 minute thing on unit
testing and pytest.
Okay.
30 minute thing on Git and stuff.
So it's like sort of all those little pieces put together, but through the lens of working
with PyCharm.
So I'll link to that.
And yeah, people can check that out if they want.
And I'm also doing a webcast with the JetBrains people, but on MongoDB.
So if they want to, people want to drop in on that on January 30th, I'm doing a live event
with JetBrains and the link for that registration will be there.
It's free.
You can come check it out.
Cool.
I'll come watch.
All right.
Awesome.
Well, yeah, that's all I've been doing this week.
Nice.
Great.
All right.
Well, thank you, Brian.
Thank you.
A lot of good stuff this week.
Yeah.
And looking forward to more next.
Talk to you next week.
All right.
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.