Python Bytes - #60 Don't dismiss SQLite as just a starter DB

Episode Date: January 11, 2018

Topics covered in this episode: Who's at nine? Retiring Python as a teaching language Don't dismiss SQLite as just a starter DB Chalice: Python Serverless Microframework for AWS Fastest way to uniquely a list in Python >=3.6 * PyTexas and PyCon AU vidoes are up* Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/60

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 Ocken. 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 slash 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.

And right. 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. Someone just sent us something that was almost a web API for the command line. But I'm noticing Flask being 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 episode to uh 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 uh 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 talk python.fm slash 146. There should be a whole lot there. That's cool. 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 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. Yeah. 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 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's 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 zero percent, you know, like basically, right. Once you round it and 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 setup. 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 is the database. If you just say, what, SQLite 3 import in Python, you get a little single file database.

This is beautiful because it's built into Python. Every instance, everybody who has Python has this. So was they just assumed it was a starter database that you always eventually have to move over to something else. 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 or 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 if you had some sort of client-side thing that periodically wanted to sync with a real database, you could store it all 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. 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 interpreting languages and weekly typed. So that makes sense.

It's kind of cool. Yeah, I thought 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. 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. Yeah. So it's quite ubiquitous. It's definitely ubiquitous. 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 that,

which is one fewer server to configure, one fewer thing 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 Datadog real quick. So Datadog 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 Datadog t-shirt, which has got a cool little dog on it. So check it out for yourself at pythonbytes.fm slash Datadog 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 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 it's the, 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, then 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. 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 Sharp, 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 what Docker container to create, run that on, make that happen, scale it, et cetera. 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 functions 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 is a new docker container i'm not entirely sure about the internals but basically every 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 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's 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. Another 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? 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 the 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 little 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 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 uh job interviews coming up here like first how do i reverse a string second what's the fastest way to unicify 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 unicify 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, and get the same, get your results on your machine. It's probably similar. The short answer is, um, 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, 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, isn't that the way it is now? Not all, like some of them, there's like two graphs.

It says not order preserving functions and then order preserving functions. And right now they have lists 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 trade-offs 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 PyCon 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 PyTexas, 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 and C Sharp, they can now plug in some sweet Python or vice versa. Yeah. Okay. Those all look good to me too, especially the MicroPython. Yeah. MicroPython's 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.

We've talked about that, the type hints and adding them and stuff. And I think this is probably a really interesting survey. 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, why, and how of social and federated login. So if you've got to do anything with identity across providers, that's so painful. This would be cool. And then here's a Tesla reference, I'm guessing, Python ludicrous mode with Django. Okay. Ludicrous mode in the Teslas is like the insane amount of power. Give you a neck ache if you hit the gas you are 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, writing 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 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 in 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. 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 refactoring and a 15 minute thing on unit testing and PyTest. 30 minute thing

on Git and stuff. So it's like 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 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. Alright, awesome. Well, yeah, that's all I've been doing this week. Nice. Great. Alright, 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. Alright, 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 Auchin, this is Michael Kennedy. Thank you for listening and sharing this podcast

with your friends and colleagues.