Transcript #196: Version your SQL schemas with git + automatically migrate them

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.

00:04 This is episode 196, recorded August 19th, 2020.

00:10 And I am Brian Okken.

00:12 And I'm Michael Kennedy.

00:12 And actually, we have a sponsor this week, Datadog.

00:15 Thank you, Datadog.

00:16 Yeah.

00:16 Thanks, Datadog.

00:18 First off, I want to talk about Django a little bit.

00:20 I've always heard Django is super easy, and that's why people choose it,

00:23 because it's really easy to get started, and it has all these things that make working with Django easy, and so on, right?

00:28 Yeah, I think there's a lot going for it.

00:31 The community seems pretty awesome.

00:33 There's a lot of tutorials.

00:34 There's a lot of expertise that they can help you out.

00:37 So there's an interesting article by Dan Verrazzo called Surviving Django, If You Care About Databases.

00:44 So, I mean, Surviving Django, right off the start, it's an odd title for an article about Django.

00:51 It's going to be kind of hard to summarize, but basically, the take on it is a little bit of a...

00:57 There's a lot of people that are going to be able to do that.

01:02 It's a lot of people that are going to be able to do that.

01:02 And it's an interesting perspective, but the gist of it really centers around that there's a lot of parts of Django that seem to be database agnostic.

01:14 So you could use MySQL or Postgres or something else.

01:18 But he says, kind of in reality, people don't do that.

01:22 People don't really switch databases that much.

01:24 So if you really want to utilize the database and some of the great things about whatever database you pick, maybe not being database agnostic is good.

01:33 Also, he talks about how to set up schemas and database migrations using the database, not using the built-in Django stuff.

01:44 It seems a little bit more like, why would I do that?

01:48 It seems more technical than I want to do with Django.

01:51 But there is some reasoning around it.

01:53 And then he also shows exactly how to do this, how to do migrations, how to do schemas.

01:58 And it really doesn't look that bad.

02:00 The interesting take, I was curious about what the rest of the Django community would feel about this.

02:06 But then after the article, there's comments on the article.

02:10 There's a really nice civilized discussion between the author and someone named Paolo Melchior, I think, and Andrew Godwin.

02:19 Definitely have heard of Andrew before.

02:20 And some others talking about basically that take.

02:25 And one interesting comment was articles like this that point out some of the pitfalls of there possibly are pitfalls with Django.

02:33 And some well-written articles are a good way to point those out.

02:38 And because there's a lot of fans of Django that really aren't going to talk about the bad parts.

02:44 And this isn't necessarily the bad part.

02:46 It's just something to be aware of.

02:48 Another really interesting comment by Andrew was, I agree that at some point in a project or company's life, when it's big enough,

02:56 SQL migrations are the way to go instead of the Django migrations.

03:01 Migrations in the out-of-box state are mostly there to supplement rapid prototyping.

03:06 Like a lot of Django, it can be removed or ignored progressively if and when you outgrow the single set of design constraints when you chose them.

03:16 So that kind of take of using Django's migrations and all the agnostic stuff might be good early on.

03:24 And then maybe slowly going towards using your database more later.

03:30 Yeah.

03:30 That's an interesting take.

03:31 Yeah, that's cool.

03:32 A bit of a practicality beats purity on both ends there.

03:35 This article also made me really appreciate the Django community because this was not a flame war.

03:41 This was a civilized discussion about a technical topic.

03:44 What, on the internet?

03:46 For real?

03:46 Yeah.

03:46 It was great.

03:49 Yeah, that's really cool.

03:50 However, you know, a few comments.

03:53 One, I've switched from one database back in to another three or four times on major projects as you're like, you know what?

04:00 This is just not doing it or it's outgrown this or whatever.

04:04 So it happens.

04:05 But at the same time, like that's usually not my SQL to Postgres.

04:09 It's usually like relational to non-relational or something massive where it's going to require rewrite anyway.

04:14 So I do like the idea of saying you have this capability to be completely agnostic, but you're working with the lowest common denominator there.

04:23 And that's usually not the best choice if you're writing an application.

04:27 Maybe if you're working with a library, tons of people are going to use it in ways you don't anticipate.

04:31 But if it's an application, you know how it's going to be used most often.

04:36 Yeah.

04:36 Also, some of those speed and speed improvements you can get out of a database, you really can't do too much of with the agnostic front end.

04:45 You kind of need to know the specifics of that database.

04:48 Yeah, pretty cool.

04:49 For this next one, I want to talk about an interesting pattern that Python uses, I guess.

04:55 Interesting technique.

04:57 So you know the ID function, right?

04:59 You can say ID of a thing and it'll give you a number back and it basically tells you what it is, like where it is in memory.

05:05 Are you familiar with this?

05:06 I guess I don't use this.

05:07 Yeah.

05:08 So if you want to know, like if I'm giving two variables, are they actually referring to the same object or do they just have the same value?

05:16 Right?

05:17 Like if I had a dictionary and I want to know, is it the same dictionary or does it just have the same keys and the same values for those keys?

05:25 You can say ID of one thing and ID the other.

05:30 And in CPython, that'll actually give you the memory address.

05:32 But in all Python, that gives you a unique identifier that is guaranteed to be different if they're different objects, the same if it's the same object, right?

05:40 Okay.

05:40 Okay.

05:40 So one of the things that Python does that's really interesting, and this is all research I've pulled up from working on my Python for memory management course that is probably out by the time that this comes out.

05:53 But you don't have to take that to care about this.

05:56 So one of the things that's really interesting in Python is everything is a pointer, right?

06:02 Allocated on the heap, including numbers and strings and other small stuff that might be allocated on the stack in languages like C# or C++ or whatever, right?

06:12 So numbers in Python are way more expensive than they are in languages that treat them as value types rather than reference types.

06:21 So for example, the number four uses 28 bytes of memory in Python, whereas the number four could use one, two, four, or eight in the languages that treat them as value types, depending if they're like shorts or longs or whatever.

06:33 Okay.

06:33 Right?

06:33 So there's this cool design pattern called the flyweight pattern.

06:39 And I'll just give you the quick rundown on that.

06:41 So flyweight is a software design pattern.

06:43 A flyweight is an object that minimizes memory usage by sharing as much data as possible with similar objects.

06:49 Right?

06:50 So that's from Wikipedia.

06:51 I'll link over to that.

06:52 In Python, Python does that for numbers.

06:54 So if you compute, like through some mathematical function, if you compute the number 16 and then some other way you compute the number 16 and then somewhere else you parse a string, the number 16, those are all literally the same 16 in memory.

07:10 Okay.

07:10 Okay?

07:11 Because 16 is pretty common.

07:13 But if you computed 423, the three different ways, that would be three copies of 423.

07:20 So Python uses this flyweight pattern for the numbers from negative 5 to 256.

07:25 And you'll only ever have one of those in the language, in the runtime.

07:30 But beyond 256 or below negative 5, those are always recreated.

07:36 Isn't that interesting?

07:37 It is very interesting.

07:38 Yeah.

07:39 So it doesn't matter how they come out.

07:41 Basically, if the runtime is going to generate the number, say, 7 as an integer, it's going to use the same 7, which is pretty cool.

07:49 I actually have some example code that people can play with.

07:51 It creates like two lists of a whole bunch of numbers, separate ways, and then says, you know, are these the same number or not, which is pretty cool.

07:59 I was just playing with it right now.

08:00 So you can, if you assign x to 1, you can do an ID of both x and 1, and it'll show up as the same number.

08:07 But if you assign x to minus 10, x and minus 10 are different IDs.

08:13 Isn't that funky?

08:13 Yeah.

08:14 It's because the numbers in Python are extra expensive.

08:17 So Python takes special care to not recreate these very common numbers.

08:23 And apparently, very common means negative 5 to 256.

08:26 Anyway, I thought that might be interesting to people, this flyweight design pattern concept and then applied to the numbers might be interesting.

08:34 And there's a little example code that I included it there.

08:36 So it's not quite an article, but it's like an idea with some code.

08:40 Yeah.

08:40 So can you, I mean, as a user, can I use the flyweight pattern in Python for other stuff?

08:45 You totally should.

08:46 Yeah.

08:46 Like imagine you've got some objects you're creating and instead of recreating them over and over, they're being used in a lot of places.

08:54 You could totally create some kind of like shared lookup for certain common ones.

08:59 Like maybe you create, you're creating states and the state has a bunch of information about it.

09:03 Like US states or countries or something.

09:06 But then you often have to go like, all right, what state is this?

09:08 Give me that information.

09:09 Right.

09:10 You don't need to necessarily recreate that.

09:11 You could just create 50 states, keep them in memory and never allocate them again.

09:14 Okay.

09:15 I guess I'm like caching and memoization are ways to do something similar, but with only one thing at a time.

09:22 Exactly.

09:23 The big important thing here to make this work correctly is they have to be immutable.

09:27 Right.

09:28 Because if one person gets the state Georgia and it has certain values and another person gets it, oh, it has a new county.

09:35 Let's add that.

09:36 And like, wait a minute.

09:36 That's not.

09:38 I've now not recreated a different thing or like, you know, so it's got to be immutable, which is why it works for numbers.

09:44 And you could do it for strings and things like that.

09:46 Okay.

09:46 Cool.

09:46 Yeah.

09:47 Pretty cool.

09:47 Something else that's really cool is Datadog.

09:50 So thank you, Datadog for sponsoring this episode.

09:52 Let me ask you a question.

09:54 Do you have an app in production that's slower than you like?

09:57 It's performance all over the place, sometimes fast, sometimes slow.

10:00 Now here's an important question.

10:02 Do you know why?

10:04 With Datadog, you will.

10:05 You can troubleshoot your app's performance with Datadog's end-to-end tracing.

10:10 Use the detailed flame graphs to identify bottlenecks and latency in that finicky app of yours.

10:16 Be the hero that got the app back on track with your company.

10:20 Get started today with a free trial at pythonbytes.fm/Datadog.

10:26 Awesome.

10:26 Thanks, Datadog.

10:27 You know what else is awesome?

10:28 What is awesome?

10:28 pip installing a thing that when I pip install something and it happens right away and it's

10:34 not like 30 seconds of compile time, like say MicroWhisgy is, to get the thing installed

10:39 and I don't have to have like MSBuild or VCVarsBat set up right or whatever.

10:44 Yeah.

10:47 So definitely I'm grateful for wheels.

10:49 It was still a world that we didn't, there was less wheels in it when we started this podcast.

10:54 I'm pretty sure.

10:55 Yep.

10:56 Most of the common packages, a lot of them have migrated to distributing wheels and package

11:02 authors have had to care about this a lot.

11:04 And so I want to talk about this article that's on the RealPython blog from Brad Solomon called

11:10 What are Python Wheels and Why Should We Care?

11:13 One of the things I really love about this is like I said, a lot of package authors have already

11:18 gone through this and understand some of the ramifications.

11:21 But as a normal casual user of pip install, we don't really think about it.

11:27 But this is the first half of this article talks about kind of what the user's perspective is.

11:33 And it's kind of a nice look.

11:34 When you say pip install something and it's a cool because it as an example, I'm glad they list an example.

11:41 And it's a particular version of MicroWhisky because most packages are wheels now.

11:46 But if you install something that is not a wheel, it's probably a tarball.

11:50 And I don't know if there's other options other than tarballs.

11:53 But anyway, a tarball is something that ends in tar.gz.

11:57 So it's a tarred and zipped.

12:00 And that's a whole bunch of Unix speak that you don't really have to care about.

12:03 But it downloads this blob of stuff and then unpacks it.

12:07 And then pip calls setup and some other stuff to build the wheel after you download it.

12:12 And then it labels it and then it installs it.

12:16 There's a whole bunch of steps in there.

12:18 Plus, it's calling setup.py.

12:19 So there could be really any code in there.

12:21 And so that's kind of creepy.

12:23 The difference is often with if you actually have a wheel instead of a tarball, pip install will just pull this down and install it.

12:31 And it doesn't call setup.py.

12:33 That's really nice, actually, because one of the things I think a lot of people don't realize until they're like, oh, wait, what just happened?

12:40 When you pip install something, you're running semi-arbitrary code off of the internet.

12:46 That's not ideal.

12:48 Right.

12:48 With the wheels, you don't have to run.

12:50 Because basically that runs the setup.py in the sdisk version, I believe.

12:54 So this is really nice that wheels can cut out that Python execution bit.

12:59 It cuts that out.

13:00 Plus, also, I'm not sure what the technology is here.

13:03 Well, I think it's probably just it's already pre-compiled and there's operating system specifics.

13:08 But wheels tend to be smaller than the tarballs, so they download a lot faster.

13:12 Wheels have a bunch of stuff in the name.

13:15 And it's not just random stuff.

13:17 It's specific stuff.

13:18 But it talks about what distribution it is.

13:21 It's got the version number.

13:22 It's got maybe build identifiers and which Python it's for.

13:27 If it's Python 2 versus Python 3 or a specific version.

13:31 And then the platform is one of the important bits.

13:35 So if you have compiled code, then there's kind of a different CI pipeline to try to build all those wheels.

13:43 But on the user end, we don't have to care about it.

13:46 So one of the different things is one of the interesting bits about going and moving towards wheels is there's a whole bunch, often a whole bunch of different, whole bunch of packages up there.

13:56 And that's something that users will see if they look at what downloads are available.

14:02 There'll be this whole slew of stuff.

14:04 And for the most part, you don't have to care about that.

14:06 If you do pip install, it'll just pick the right one for your operating system.

14:09 However, it's good to be aware of those because if you are creating like a cache of stuff at your, if you have your office or something, you may want to cache more of those depending on what operating systems are being used around.

14:24 So that little discussion, I think, is pretty cool.

14:26 Absolutely.

14:27 Anyway, I'm not going to get too much into it.

14:29 This is a good article for, yeah, I use wheels, but what are they?

14:33 And this is, this doesn't get too deep into it, but it's nice.

14:36 Yeah.

14:36 Well, wheels are definitely nice.

14:38 And another solid article from RealPython.

14:41 So very nice.

14:41 You know what else is good?

14:43 Pandas.

14:44 I've heard that Pandas does a lot of cool stuff.

14:46 Now, actually, Pandas is really, really cool.

14:48 You could do a whole bunch of interesting things with it.

14:50 And Jack McHugh, he's been on fire lately.

14:55 He's created all these different projects that he keeps sending them over and like, oh, this is another one I found.

14:58 He's like, no, this is another one I created.

15:00 And a lot of them are cool.

15:02 One of the things he created was awesome Python bytes.

15:04 So hat tip to Jake on that.

15:05 That's cool.

15:06 Like all the awesome stuff that we happen to have covered periodically.

15:08 But this one is called Pandas Alive.

15:11 And so, Brian, to get the experience of this one, you need to open it up and just scroll through the readme on the GitHub page and just look at the animations.

15:20 So you probably have seen these racing histograms or racing bar charts that show stuff happening over time.

15:27 Like here's the popularity of web browsers all the way back from 1993.

15:31 Where it was Mozilla and then Netscape and then IE and then, you know, whatever.

15:35 And you see them like growing and moving over time.

15:37 Yeah.

15:38 So this is a package that if you have a Pandas data frame in a really simple format where the columns are basically the different things you want to graph.

15:49 And they're all arranged by a common date.

15:51 And they just have numbers.

15:53 You can turn that into a really cool like bar chart race type of thing or line graph race where it's just this animation of those over time of the dates that you have in there.

16:02 Oh, I really like this.

16:03 Isn't this cool?

16:04 Yeah.

16:04 And the, I mean, like the race charts and stuff, those are cool.

16:07 But then you can also do the, like the line, the line graphs, the growing, zooming.

16:13 Yeah.

16:14 Yeah.

16:14 You can do like line graphs and you can do other types of things, little plot, scatter plot type things.

16:19 You can also do pie charts, but you can even have them together.

16:23 So you can have maps.

16:25 So if you want to have a map evolving over time with like different countries or counties fading in and out,

16:32 you could have like those two graphs animated side by side at the same time.

16:36 So you could have like the, the chart of the bars as well as the map all animated together in like one graph.

16:42 Cool.

16:42 Seems pretty awesome.

16:43 Well done, Jack.

16:44 It's based on, I believe, matplotlib.

16:47 And basically it'll render a bunch of different matplotlib renderings into an animated GIF.

16:53 So all you have to do is just go like dataframe.plotanimated, give it a file name, and then this happens.

16:59 Oh, that's cool.

17:00 So then you can just generate this GIF and then put it wherever.

17:03 Exactly.

17:03 You can put it on your website.

17:04 You can put it wherever you want.

17:05 You can share it on Twitter, I guess, even.

17:07 Right?

17:07 But it doesn't require like a JavaScript backend running something and your Jupyter notebook and then all that kind of stuff to wire up.

17:15 Like, no, it's just an animated GIF that comes out.

17:17 Neat.

17:17 This is mesmerizing.

17:18 I could just watch these all day.

17:19 You could watch it for quite a while.

17:21 So, yeah.

17:22 Anyway, really think that's a cool project if you want to visualize data over time, which, you know, there's a lot of good reasons to do that.

17:29 One of the things that it has there is animated maps.

17:32 But maps are something else also.

17:35 There's also a map function, which has nothing to do with geographic maps.

17:39 You probably learned a Python a long time ago, but do you remember being surprised by map and all?

17:44 Yeah, map and all those things, they always confuse me and I've always tried to basically avoid them.

17:48 And I've successfully mostly done that.

17:51 But I know also.

17:53 Yeah, yeah.

17:53 I also know how useful they can be.

17:55 So tell us about it.

17:56 This is an article from Catherine Hancock's How to Use the Python Map Function.

18:01 And I know we're sure people have heard of maps and map, the map function.

18:06 It's an extremely useful function, a useful thing.

18:09 So it's a built-in.

18:11 And what it does, if you're not familiar with it, it takes two or more parameters.

18:16 The first parameter to map is the function that you want to apply.

18:19 And then, like, let's say if you give it as the second argument an iterable, like a list or something,

18:25 it takes that function that you passed in and applies it to absolutely every element of the iterable, the other one.

18:32 So, like, if I have quick, like, the normal often use is using a lambda function or something to apply some, like, quick thing.

18:42 Like, if I want to do x times squared, x times squared, x times two or x squared or something like that.

18:48 And apply that to every element.

18:50 You can do that.

18:51 And you can make one list into another.

18:53 I think it's good for people to, like, read about them every once in a while if they're not using them often because they do come in handy in places that you, all the time, for me at least.

19:04 So, it's not an obvious thing if you're not used to this sort of a function from other languages.

19:09 I wasn't coming from C.

19:11 Yeah.

19:11 And maybe Perl has something like this, but I never used it.

19:14 So, that's the normal use of applying it.

19:16 One of the things I like about this tutorial is it goes through a few different things.

19:20 So, applying lambdas to a list or an iterable, and then the function that you apply doesn't have to be a lambda.

19:27 It could be your own user-defined function, or it could be a built-in function that you map to it.

19:32 I want to, like, warn people, the part where she's talking about the user-defined function, it's oddly complex for some reason.

19:40 I'm not sure why this was made so complex, because a user-defined function just works like anything, any other function that's using for map.

19:48 But one of the things that I even got out of it is I had forgotten that map applies the function to the iterable one element at a time, and it doesn't do it ahead of time.

20:00 So, like, for instance, and I'm like, really?

20:03 And I had to, like, prove it to myself by putting a print statement or something in a function to do it.

20:08 But what happens is, like, let's say I've got iterable hooked up to grab, like, a huge data chunk out of a stream or something.

20:15 I can apply some function to each element as I'm pulling it out and using map to do that, so I can iterate over map.

20:23 So map returns a map object, which, whatever, it doesn't matter.

20:28 It's just every element that you use, if you use it as an iteration, is the answer after you apply the function.

20:35 It's like a custom generator type thing.

20:37 Yeah.

20:38 And then if you want it as something solid, you can convert it to a list or a tuple or something like that if you want to do everything.

20:46 I'm done with generators.

20:47 Throw it in a list.

20:49 There's some honesty here, too.

20:50 The other thing I often forget about map is that you can map it across.

20:55 If you have a function that takes multiple arguments, you can pass it multiple iterables.

21:01 And it'll take, you know, element-wise each one.

21:04 So, like, the nth element out of each list and apply, pass it to the function and then return the answer to that, which is cool.

21:12 The other thing, a good comment in this, because it's a similar problem area, is comprehensions kind of do the same thing.

21:19 So when would you use map versus comprehension?

21:22 And the advice in this article is comprehensions are very useful for smaller data sets, but often for large data sets, map can be more powerful.

21:32 So that's reasonable.

21:33 And sometimes you want to do operations that if you had to go over different collections of data would make a really nasty-looking comprehension and stuff.

21:40 So, yeah, cool.

21:41 Yep.

21:42 You also can do, like, pandas type of things a little bit, like multiplying vectors, right?

21:46 Like, if I've got two lists and I want to have pieces put together, like that power example that's in there, right?

21:52 It'll take the first element of the first one, the second element of the second one, and then apply the function and generate a new list, effectively, that has, like, as if you had sort of done vector multiplication, which is cool.

22:04 Or, like, cross, I don't know, cross multiplication.

22:07 Yeah.

22:07 I often use map also when I want to muck with something and it seems a little cleaner to me to iterate through something.

22:14 If I know I'm looking for something and I'm not going to get the end of the data or I'm using endless data.

22:21 Nice.

22:21 So, we spoke earlier about databases and I've got another one for us.

22:25 This cool thing called AutoMigrate.

22:28 It's a project called AutoMigrate.

22:29 Okay.

22:30 So, what it does is it's kind of like you talked about Django migrations and we also have SQLAlchemy migrations with Olympic.

22:38 But some people, either they're not using an ORM at all, in which case those tools are useless, or they want to very carefully write the SQL scripts that control their databases.

22:52 Like, some people, there's, like, a group of DBAs that manage the database and that's that, right?

22:58 We're not going to run just random tooling against the database.

23:01 We're going to run scripts that are very carefully considered.

23:04 So, this AutoMigrate thing, what it will do is if you have a, those DDL, data definition language scripts that say create table, add column, and so on.

23:16 All it has to do is have the script that will say, here's how we create something from scratch.

23:21 You put that into GitHub and then you make changes to it.

23:25 Like, to add a column, I go and edit the create table thing and I just type in the new column in there.

23:30 And what this will do is it'll look at your git history and it'll do diffs on the create table statements and it will generate the migration scripts from that.

23:39 Oh, that's really cool.

23:40 That's neat, right?

23:41 So, all you got to do is, like, maintain the, here's how I create the database and it'll actually go, well, to go from this version to that version, here's the script that would actually do it.

23:48 It'll do all that stuff for you.

23:49 Oh, nice.

23:50 Yeah.

23:50 So, if that's your flow, if your flow is to work with these DDL files, these SQL files, this seems like a great tool.

23:58 Now, they do say, oh, this is way better than, like, an ORM or something because in those, like Alembic, what you have to do is you have to go and write the migration scripts.

24:08 Here's how you migrate up.

24:10 Here's how you migrate down.

24:11 But they left out a little important thing, --auto generate, which looks at all of your classes in your database and go, here's the difference.

24:19 We automatically wrote that for you, which I think is way nicer even than this project.

24:23 So, I think Alembic is better, but the big requirement there is you are using SQLAlchemy.

24:28 If you're not using SQLAlchemy to do these migrations, then this tool, but you're using these scripts instead to define your database, like, I'm sure a lot of, like, especially the larger companies where there's, like, a database team or, like, DBAs and so on are doing.

24:44 And this seems like a really cool project for it.

24:46 Yeah.

24:46 That said, the converse is actually pretty cool.

24:49 So, what it can do is it can look at a database and it will generate your SQLAlchemy files for you.

24:54 That's pretty cool.

24:56 That's nice.

24:56 Yeah, it'll generate ORM definitions from SQL, right, using the SQLAlchemy generator, which is pretty awesome.

25:04 So, you can say, here is my create table scripts, generate me the corresponding SQLAlchemy thing to match that.

25:12 So, in that direction, it's pretty awesome also.

25:14 So, which does that?

25:15 This one, this auto migrate.

25:16 It'll look at your DDL, like, create these table scripts, and it'll turn it into Python SQLAlchemy classes.

25:23 But the reverse, it was saying, like, oh, it's painful to use Olympic in the other direction.

25:27 But if you use the auto generate feature of Olympic, then it's also not painful.

25:32 But there's certainly a couple of use cases that are pretty awesome here.

25:36 One, like, starting from all the create stuff, like, given a database, just ramp me up to getting a SQLAlchemy set of classes that'll talk to it as quick as possible.

25:46 That's really cool.

25:47 If I've got a schema change, is there a version number that's stored in the database somewhere to say which version of the schema is being used?

25:55 Yeah, I have no idea about this thing.

25:58 With SQLAlchemy and Olympic, there is a version number.

26:01 It says, I'm version some hash.

26:04 And then all the migrations, one of those is the hash.

26:07 And each migration says, the one that came before me is this, and the one that comes after me is that.

26:11 They can look at an existing database and say, your version X.

26:15 Yes, exactly.

26:16 For Olympic, I have no idea about this thing.

26:18 This thing could potentially look at the table, basically run it, like, script this create table stuff for me, and then look at that compared to what it has.

26:27 Potentially, I have no idea if it's that smart, though.

26:29 Okay.

26:29 Yeah, but it looks like it could be handy for a lot of folks.

26:31 Well, I've had a rough week, so I've got no extra stuff.

26:36 No extra stuff?

26:37 No extra stuff.

26:38 I don't have too much either.

26:39 I have a little bit.

26:40 I just want to give a shout out that we have a ton of new courses coming.

26:45 And I want to just encourage people, if they're interested in these, to go to training. talkpython.fm/getnotified and put the email there if they haven't created an account or signed up there before.

26:55 Because we have Excel, moving from Excel to Python with pandas coming out.

27:00 We have getting started with data science coming out.

27:03 We have Python memory management tips coming out.

27:05 Those all three will probably be within, like, a couple of weeks.

27:08 And then getting started with Git and Python design patterns as well.

27:12 So there's a bunch of cool stuff.

27:13 If you want to hear about any of those, just be sure to get on the mail list.

27:16 Oh, wow.

27:17 That's cool.

27:18 If I didn't talk to you every week, I would totally get on this mailing list.

27:21 Awesome.

27:22 Actually, I think I'm already on it.

27:25 I'm sure you are.

27:26 Because you do talk to me, though, you get jokes.

27:28 Definitely.

27:29 But everybody who listens gets them also.

27:30 That's right.

27:31 This is a fun game to play.

27:33 The idea is you take some actual, legitimate, classical painting.

27:40 And if you go to an art gallery, it'll say, like, flowers in bloom, oil canvas, Monet 1722, or something like that,

27:53 like, in the little placard underneath.

27:54 So the game is to reinterpret these paintings in modern tech speak.

28:00 Okay?

28:01 Yeah.

28:02 So here, I'll do the first one.

28:03 I put three in the show notes that people can check out.

28:07 I'll describe this to you, and then I'll read the little thing.

28:09 So there's, like, a ship that seems to be on fire with some extremely strong guys trying to drag the ship out of the water.

28:18 Maybe, no, they're pushing it into the water.

28:20 And a bunch of folks on the edge sitting off.

28:24 It's like a Viking ship.

28:25 I think they're actually cremating.

28:27 Somebody's sitting out.

28:27 Anyway, it's this historical picture, and it says, the placard says, Engineers remove dead code after dropping a feature flag.

28:36 Sir Frank Bernard Dixie, 1893, oil on canvas.

28:42 You want to do the next one?

28:45 Oh, sure.

28:45 Pull it up.

28:47 Oh, okay.

28:48 How do I describe this?

28:50 This is like a picture.

28:53 It's a Picasso picture.

28:54 It's like an abstract violin that explodes or something.

28:58 Yeah.

28:58 It's hard to tell, really, what's going on.

29:00 It kind of looks like a violin.

29:02 And the title is CSS Without Comments.

29:05 That's good.

29:06 Pablo Picasso, 1912.

29:10 All right.

29:10 The last one.

29:11 The last one we'll do.

29:12 By the way, there's hundreds of these.

29:14 They're all really good.

29:15 So this one is a little disturbing.

29:18 There's a person who looks deathly ill with a bunch of, like, gargoyles over them.

29:23 A priest with a crucifix, kind of glowing, apparently trying to ward off the gargoyles.

29:30 And the placard says, experienced developer deploys hotfix on production.

29:35 Francisco Goya, oil on canvas, circa 1788.

29:38 That's good.

29:40 Yeah.

29:40 So there's just so many of these.

29:41 You can go through them all day.

29:43 It's really fun.

29:43 Didn't PyCon do that once at, like, one of the PyCons?

29:46 I think you might have been with us.

29:47 I know Chris Medina, Kelsey Hightower, and I were walking around the Portland Art Museum,

29:53 like, basically playing this game.

29:56 We were, like, coming up with a placard.

29:57 It was fun.

29:57 And were you there for that?

29:58 You might have been.

29:59 No, I wasn't.

30:00 I missed that one, but.

30:01 That was good.

30:02 Remember that one when you could go to conferences?

30:04 If there were people around you?

30:06 Other people?

30:07 Close?

30:08 It was weird.

30:08 Actually, we don't need anybody to contact us and tell us that we have no idea when different

30:13 painters were alive.

30:15 But thanks.

30:15 And cool.

30:16 Good for you if you know it.

30:17 Awesome.

30:18 Yeah, these are really good.

30:19 If you enjoy this kind of stuff, there's hundreds of fun pictures to go through.

30:23 And I think it's also amusing that we often pick visual jokes for an audio format.

30:28 So, sure.

30:29 Why not?

30:30 Do it hard.

30:31 That's what burgers do.

30:31 Let's do it with, that's right.

30:32 Let's do it with abstract art.

30:34 Yeah.

30:34 Yeah, it's funny.

30:37 Anyway.

30:38 Awesome.

30:38 All right.

30:39 Well, thanks, Brian.

30:39 Thank you.

30:40 Yep.

30:40 Bye.

30:40 Bye.

30:40 Thank you for listening to Python Bytes.

30:42 Follow the show on Twitter at Python Bytes.

30:45 That's Python Bytes, as in B-Y-T-E-S.

30:48 And get the full show notes at Python Bytes.fm.

30:50 If you have a news item you want featured, just visit Python Bytes.fm and send it our way,

30:56 where I was on the lookout for sharing something cool.

30:58 This is Brian Okken, and on behalf of myself and Michael Kennedy, thank you for listening

31:02 and sharing this podcast with your friends and colleagues.