Transcript #172: Floating high above the web with Helium

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

00:05 This is episode 172, recorded March 4th, 2020.

00:11 And I am Brian Okken.

00:12 And I'm Michael Kennedy.

00:13 And this episode is brought to you by DigitalOcean.

00:16 And they've got all sorts of cool stuff we'll hear about later.

00:20 Who's going first? I always forget.

00:21 You know, I guess I'm going to jump in on this one, because I've got some cool stuff from Hank.

00:25 Hank! He even messed his name up worse than I do.

00:29 Heniek?

00:30 Okay, cool.

00:31 All right.

00:32 Sorry, Heniek.

00:33 I have to give you a bad time because he gives me a bad time all the time.

00:35 Yeah, well, it's a cool but unusual name, which is probably going to result in some mispronunciation.

00:41 He's got a cool article he tweeted about a little while ago, a week or two ago, and I just thought it was really interesting.

00:49 And basically, it's his thoughts on running Python in production.

00:55 So it's kind of a look back on some places he heard interesting discussions on people running Python in production, as well as maybe got some nice little call outs on things that seem solved but aren't solved that are interesting to talk about and whatnot.

01:12 So I just thought I'd maybe talk about that a little bit.

01:14 Yeah.

01:15 Yeah.

01:16 I mean, I definitely relate to this being someone who runs Python in production.

01:19 So in order to keep the two podcasts, the courses, and various other things, other services running, there's like eight servers and whatnot.

01:28 So there's a non-trivial amount of devopsy production architecture stuff.

01:34 It's not anywhere near Facebook, Google, or whatever, but it's way more than a $5 host running some WordPress thing.

01:41 So it's meaningful, I guess.

01:43 So anyway, his article, basically the premise is that he's missing a key part of the public Python discourse in that it seems like people really aren't talking about running Python in production, although maybe the exception of Instagram or Spotify.

01:58 Right? - Yeah.

01:59 - That's pretty interesting.

02:00 And he listened to this podcast episode, or recommended, or I guess listened to this podcast episode sort of kicked him off down this path of thinking about it.

02:06 Like there was this podcast, and I'm trying to remember what was it called, and here I'll pull it up.

02:11 It's called, well, "Running in Production." Actually, it's a pretty interesting one by Nick Gentakis, probably mispronounced that name as well, but Nick's got an interesting thing where he talks to people from all sorts of different technology backgrounds, JavaScript or Ruby or Python or whatever.

02:30 And he interviewed this guy named Gareth Thomas from the UK where they have some Plone, I believe it's Plone app, that is actually running like 10% of, getting like her afflict from 10% of the UK schools or something really interesting in this.

02:48 But it was more interesting to just think about listening to that episode, looking at Hank's article and saying, when do I agree with them?

02:58 When do I disagree?

03:00 And he said, look, I disagree with a lot of their choices.

03:03 Actually, I think they're using microservices a bunch.

03:06 And he was like, thank goodness there are no mark.

03:08 I'm not doing microservices basically.

03:11 And it's really interesting, even if you disagree, to think about the trade-offs that people made.

03:15 Because while you might make different trade-offs, that might be because you have different goals or different things you're optimizing or different experiences or things that you need over what they need.

03:27 So I just think this idea of exploring how people are running Python in production, how they're solving problems, it's pretty interesting.

03:33 - Yeah, I also kind of have to agree that I like the idea of hearing more about the pathway of why people are where they're at, what decisions they made and what things they faced and why they made those choices.

03:45 Because that's, it's almost more interesting than what end product they came up with, is what the path they took to it.

03:53 I mean, like Lord of the Rings would be nothing without the path to the end, right?

03:57 - Exactly.

03:58 Oh yeah, and they get the ring back.

04:00 (laughing)

04:00 - Yeah.

04:01 - Yeah, so his article, like all good complaints, comes with a suggestion.

04:06 And he says, at the end, Here's a bunch of things that could get discussed more.

04:11 And so here's an offer.

04:13 I would love to encourage people doing interesting stuff with Python, running websites or APIs and whatnot to tell them basically to do talks at PyCon, at meetups and in blogs.

04:25 And I think he even offered to help mentor people to get those kinds of talks accepted more frequently at conferences.

04:31 - I think that's a great idea.

04:32 - I think it's a great idea.

04:32 And maybe we should do that at the PDX Python West meetup.

04:38 - That'd be fun. - Yeah.

04:39 - Yeah.

04:39 We think about that, but yeah, I definitely like this idea because on one hand, if it's kind of always the same story, it's not that interesting, but I do think there's a lot of trade-offs that people are making.

04:50 And I think it's pretty fun to see what's working.

04:52 - And it's clearly going on.

04:54 We're just not talking about it because we're, I mean, you and I have noticed that there's a lot of people in the Python community that are in the website, or the website of the Python community.

05:05 And it's way more than just the Instagrams and Dropboxes of the world.

05:10 - Yeah, absolutely, absolutely.

05:12 Yeah, it's really cool, and there's a bunch of more stuff that I'm not covering in this article, but I mostly covered it because I love his offer of like, hey, let's get more of this conversation out there.

05:22 We could do open spaces, we could do Python, PyCon talks, suggestions, proposals, things like that.

05:29 I guess one final thing to throw out there is Dan Bader and I did have this conversation for Talk Python and the training and Python Bytes and whatnot as well as for real Python over on Talk Python episode 215 at the last PyCon, we recorded that one.

05:46 So we'll see what happens with this PyCon, but that's a small contribution towards that, and that was a really popular episode, but I definitely wanna encourage people to take Henek up on this, up on his offer here, and get the word out a little bit more.

06:02 - All right, yeah. - Yeah.

06:05 So Brian, when I think about tests and whatnot, I feel like you should really be honest and like testing to tell a true story and you should never like cheat with testing, should you?

06:14 - Yeah, only, yes, you should definitely cheat.

06:16 Cheat as much as you can.

06:18 - Tell us about this next one.

06:19 - So this comes from, I think it's Simon Willison.

06:22 The article is called How to Cheat at Unit Tests with pytest and Black.

06:27 It's got all of my favorite things, testing, pytest, Black, and well, I'm not a fan of the unit part, but we'll get there.

06:35 So the premise is, I'm going to quote this, "In pure test-driven development, you write a test first and you don't start on the implementation until you've watched a test fail." Okay, so the idea is it's the red-green refactor thing.

06:50 So you write a failing test, you write code to make it pass, and then you refactor it so you're happy with it.

06:55 - And if I don't do that, I'm cheating?

06:56 - Yeah, apparently.

06:57 - I think I might've cheated accidentally recently.

07:00 - Okay, well, yeah.

07:01 My thoughts partly on that is there is no such thing as pure test-driven development.

07:07 Even Kemp Beck himself says he didn't make this stuff up. He rediscovered it from previous best practices. So there's no pure in test-driven development. We can't even agree on like whether mocks are good or evil or what a unit is. So whatever works for you, man.

07:23 So Simon's process really was to cheat on this and the way, and I think this is just clever pragmatism. His cheat method was to write a pytest test that calls a function that he's so he's been working on a function and he thinks it's he's happy with it and he writes a test that calls it but then compares the output to you know something he knows won't pass like just the output equals false or something and you know that asserts gonna fail. So you run the test and when it fails you take a look at the output and if you're happy with the output you just copy that just highlight it, copy and paste it into your test, and now your test should pass. So this feels like cheating, but it's really just taking a manual test and turning it into an automated regression test. Especially when you're exploring stuff, I think this is a great way to build up some of your test coverage.

08:16 The bit about Black is that the output might be this big long blob something, like a dictionary or a big list or something, and it might not be formatted well and that's where he just turns black on his test code and reformat it nicely and make sure it still passes. So I think this is a good time saver.

08:35 This is interesting. I was working on some tests recently where I had a big chunk of test data that I wanted to compare against something kind of like he's describing here and I was really torn. I'd love to hear your thoughts on this.

08:49 You know I put this at the top of my test file so I could reference it right.

08:54 I didn't put it in the test, I put it kind of separate 'cause I'm like, well this thing is, you know, it basically fills the screen.

08:59 So I didn't want it to generate a huge test.

09:01 I wanna say compare against that thing, right?

09:04 And one of the thoughts I had was creating like a, I don't know, a test data module where I could pull those things out, like put it completely into a different file and pull it back.

09:14 And it sounds like that might also be a nice way to organize things here, but at the same time, it takes what you would see as I'm comparing against this and it hides it away behind a label of whatever that test module is.

09:27 What are your thoughts on that?

09:28 Good, bad, indifferent?

09:29 - I think there's lots of times where that, if that is a good thing, especially like you said, it's a data, a big structure or something that you're comparing against.

09:39 One common method to do something like that is if there's like, for instance, it isn't really what you're asking, but if there's, instead of comparing a whole bunch of different fields or something, to actually compare structures.

09:51 So to create the expected data structure, especially with data classes, it makes it pretty easy.

09:57 You can just say, this is my expected object.

10:00 And what I got back was this thing and compare those two.

10:04 Now, if that thing, if all the data is huge and it makes it more clean to work with your tests, to stick it in a different file, then go for it.

10:12 I think that's fine.

10:14 There's a method of regression testing, which is kind of the model of, I know it works now and I'm gonna modify the code for some reason.

10:23 So instead of trying to come up with thorough tests for everything, just running it with a bunch of logging and stuff and capturing all that.

10:31 - Yeah, absolutely.

10:32 - And then running it again and make sure all of your output and logging is the same and just comparing against that.

10:38 It's yucky to work with in the long run, but in the short term, it's a pretty handy quick thing to do.

10:44 - Yeah, instead of changing your entire architecture so you can mock out everything, and then who knows if you get that right, you're just like, I don't want it to change. Let's just start from like keep it where it is and if it breaks then we'll figure out if that's some a change we wanted right but just to know that it didn't change is really helpful and that's a quick easy way I like it. Right and I mean change detector tests are a smell that you need to be aware of because they're not you want to be able to to change your architecture as long as you can make sure that you're checking for you don't want the behavior to change sometimes those are good things. Yep I agree. Be a pragmatist. For sure, good advice. You know what else is good advice? To work with DigitalOcean.

11:21 Yeah, definitely. We've been working with DigitalOcean and we've got a lot of our infrastructure there and we've been really happy with it. And so one of the things they've got, they've got Kubernetes clusters and all sorts of stuff. So however, getting started with hosting and running Linux servers or Kubernetes clusters and all that stuff can be a little tricky and getting into that, going from just building on your own computer to dealing with all of this, some people might not know how to do that. And so that's one of the reasons why DigitalOcean launched their new support center. So the support center makes it easier to find the answers to your questions and to get help that you need right when you need it. You can search across product docs or community tutorials and forums and it's all in one place and you can get all your answers.

12:05 So I'm sure that's going to help a lot of people really a lot. So you check this out you can visit pythonbytes.fm/dosupport to see their tutorials and of course you can use pythonbytes.fm/digitalocean to get $100 credit for new users.

12:22 Their tutorials are pretty awesome and I just want to tell people like how helpful they have been. So typically you know especially when I was getting started I'm like man how come this microWSGI thing won't start? It seems like it should work when I run it but it won't. It's probably something like the logging file didn't have permission to write to or something weird like that.

12:43 You go search for that and it's very likely that one of these tutorials is gonna come up but you know I just went and put microWSGI into their tutorial thing here and it comes up how to serve a flask app with microWSGI and nginx on Ubuntu 1804 but then it has a drop-down oh would you like to do that on 1604 or 1404 or maybe on CentOS 7 or whatever and you can actually change the operating system it's running on and the tutorial will adapt.

13:09 I mean, it's ridiculous how involved it is.

13:12 >> Yeah. They've really done a lot to help novice users come up to speed to get things running well.

13:18 >> Yeah. I just remember how helpful that stuff was for me.

13:20 So yeah, check them out at Pythonbytes.fm/digitalocean, get that credit, but then use their support center to actually get going.

13:26 You know what I'm glad I don't have to support?

13:28 Hundreds of microservices.

13:30 >> Yeah, me too.

13:32 So I think I found this from Mahenyak's article where he was talking about how people were running in production and whether or not they should have microservices or not.

13:42 And that podcast I told you about, I believe those people were using microservices.

13:46 He's like, "Yeah, no way. No, thank you." And referred to this article by Alexandra Noonan who works for a company called Segment.

13:56 And this is like a retrospective on their experience.

13:59 So they had started out with a monolith app.

14:01 app. I believe they're doing JavaScript, but it doesn't really matter. Basically, it's like package managers and maintaining versions that talk to API. It's the same story for Python, you can just switch the code samples or whatever. And they're not really relevant. So there's this article called Goodbye microservices from 100 problem children to one superstar. And it talks about how segment was founded during the height of microservices as the architecture du jour, right?

14:30 architecture of the day and how to sort of decided that was going to solve all their problems and at first it did but as they grew and grew and grew it turned out to be such a huge headache.

14:43 They had three software developers and eventually they said basically their three software developers were spending almost all their time tracking down broken tests across these hundreds of different variations of microservices and all sorts of stuff and they were just going nowhere. So it talks about how like all the benefits that microservices should have like improved modularity, reduced testing burden, better functional composition, isolation, team autonomy, and all that. And how many of those things turned around to actually become like molasses in their world and slowed them down instead of letting them work faster. So basically, it's a really concrete story about how they took a step back from microservices, how they actually made that step backwards because with 100 microservices into one app, that's kind of a beast to pull off and how it helped them basically get everything under control again.

15:37 What's really interesting is basically the places where things broke down.

15:42 For example, each microservice was talking to a similar but slightly different API, like customer integrations and stuff.

15:51 They had slight different needs.

15:53 Over time, some of the core bits of those libraries were slightly different across the different APIs.

16:02 It became, instead of having things you manage separately for each endpoint, you actually ended up with 100 different services, all of which you had to manage.

16:10 If you're going to make a big change, you got to test it against all these variations.

16:14 Their tests were super slow to run.

16:16 There's just a lot of things.

16:18 Also dependencies, as in requirements.txt type dependencies, they wouldn't upgrade all of them at the same time because they wanted to make sure that they had to test it and whatnot.

16:29 If you're going to be running on, say, requests 2.1 over here and 2.2 over there, are you sure if there's a problem with that, how do you deal with that?

16:42 Now, I'm a big fan of the big monolith type apps and keeping a little more control over it that way.

16:49 So I'm all behind this sentiment, but I do feel like they could have actually done a lot of work on the DevOps side to make this dramatically better, and maybe, who knows, maybe they would have never switched.

17:00 Yeah. Did somewhere I catch that there was a limited number of developers?

17:04 I think there was like three or something.

17:05 At one point there was three working on all these things.

17:08 And you know, microservices are often touted as being really great ways for dev teams to have autonomy.

17:15 but when your dev team consists of three, you don't really need autonomy.

17:19 You're already autonomous.

17:20 Yeah, exactly.

17:21 That's one team.

17:22 It doesn't need more than one thing to be autonomous, right?

17:24 Basically speaking.

17:26 But let me just take a step back and say, for example, one of the big problems I said is, we've got a hundred different services that behave similar but not the same with slightly different integrations against different API endpoints.

17:39 And we're feathering out or fanning out requests to those services based on on which thing they're kind of integrated with.

17:46 And the big problem was the dependencies.

17:48 Well, if they had used something like Docker and Kubernetes, and they forced them all to say, we're going to install the same runtime environment with the dependencies pre-configured, and the only way you get to release a new version is you get your little thing to work with the latest image that has a uniform set of dependencies across the board.

18:10 Well, that sounds like that would have completely taking out one of these problems to me, right?

18:14 I mean, sure, you might have to do a little work to replace a new version of some thing, but you're keeping it in sync, right?

18:20 So it seems like there's a couple of things like that that they could have done.

18:23 There's other issues on the testing side that were caused by these variations.

18:27 And I feel like there could have been some uniformity stuff done, especially around Docker, that could have made this a lot better, but still.

18:35 I think there's a lot of interesting lessons there.

18:37 - Yeah, I think I'm looking forward to reading this 'cause that sounds like an interesting story.

18:40 - Yeah, yeah, it's pretty good.

18:41 Well done, has nice pictures.

18:43 - Yeah, neat.

18:44 Oh, I like pictures.

18:45 - Speaking of tests and running them on the web.

18:47 - Yeah, so one of the workhorses of front-end web testing is often Selenium.

18:52 And Selenium's awesome, but it can be abused.

18:56 And also it takes a little bit of knowledge.

18:59 So there, I think we've covered others.

19:01 There are some higher level APIs that use Selenium under the hood, but have a different interface.

19:07 And I'm a fan of a lot of this sort of stuff because if it simplifies your life, go for it.

19:14 One of the things we're gonna cover today is Helium.

19:17 It's a newer, oh, it's very much newer.

19:19 It's only a few months old Python library for automating web browsers.

19:23 It's a project that's built on top of Selenium, and even though it's fairly new, it's already got over 1,000 stars on GitHub.

19:33 That's cool.

19:34 The claim is Selenium Python, 50% easier.

19:38 Helium is the best Python library for web automation.

19:42 Well, of course, it's saying that to itself, but it does look pretty clean.

19:45 There's some pretty clean drivers to be able to control Chrome, control your browser, and navigate some stuff.

19:53 So it looks good.

19:54 - Yeah, I really like this.

19:55 I think Michael Herrmann did a interesting job on this.

19:58 And the reason that I think this is neat is it takes you away from working at the structure level.

20:07 So for example, just like selecting, you say I'm going to open up this website, right?

20:13 So you say start chrome, github.com/login, but instead of doing some kind of CSS selector to find the text box, you just say write, if you wanna like set something to a text box, you say write this text into, and you just give it like a short bit of text, like the label that is right before, immediately before the text box, right?

20:34 So write something into username, and that'll just fill out the username thing, then write something into password, and that'll type in the password, and then click the button, they say click sign in, and it just finds the button with the text sign in.

20:48 What is nice is like what a human sees about the page is how the code interacts with it.

20:54 And you might say, well, that's unstable, right?

20:56 What if somebody changes the text?

20:57 Well, if you've ever had to work with CSS selectors, and then somebody redesigned the site, and your automation stopped working, it's not a whole lot better.

21:05 So, might as well make it easy for humans as far as I see it.

21:08 - Yeah, and the API is so clean and short.

21:12 So you've got function calls like click, and you just give it the tag of thing, the button tag that you're gonna click on.

21:22 So, man, it's pretty sweet.

21:24 And to fill in a username, for instance, in a username field, it just is write, and then you give it two parameters, the name of the field that you're gonna write into, and then what you're gonna write in there.

21:36 So this is pretty slick, I like it.

21:38 - Yep, for sure.

21:39 Too many things get the for humans tag in Python, but this one kinda could get that.

21:43 - Yeah, and so since this is new, I'll be curious, and there's a lot of web testing going on, I'll be curious to see where this goes.

21:52 Keep an eye on it.

21:52 - Yeah, absolutely.

21:53 And the easiest way, if you wanna get a sense of whether or not this is interesting for you, is just go watch the, there's a little GIF, animated GIF.

22:02 Just watch that for 10 seconds, and you'll have a quick idea what you can work with there.

22:05 - We've said this before, animated GIFs of how things work are a good thing to get people excited about a project.

22:12 This project also includes a cheat sheet of some of the common things you might wanna do.

22:17 Single page with a whole bunch of stuff.

22:20 It's kinda like an FAQ, but just sort of no questions, just answers.

22:26 - Yeah.

22:27 So I'm pretty certain that's a good idea, but sometimes you're not certain.

22:31 - Yeah, lots of times.

22:32 So I remember, I don't know where I learned more about this.

22:35 Either this was in physics or this was in statistics or something.

22:41 I think it was one of my science classes in college.

22:44 I've promptly forgotten it.

22:45 So there's no way I could work with uncertainties in measurements really well.

22:50 Maybe it was even engineering.

22:51 I'll tell you a quick example and then I'll ask you a question.

22:54 You can't look ahead and don't cheat because I have to answer the notes further down.

22:58 So imagine we're back in school or you're solving a real problem.

23:02 Jane, she needs to calculate the volume of her pool so she knows how much water it'll take, right?

23:07 So she measures the length, the width, and the height.

23:10 Now of course you can't measure it ultra precisely and also there's probably some variation in there.

23:15 So she determines the length is 5.56 meters plus or minus 2.5%.

23:21 Like that's her guess on the inaccuracy.

23:23 And the width, 3 meters plus or minus 2.6%.

23:26 And the depth, three meters, plus or minus 3.7%.

23:31 So what is the uncertainty, right?

23:33 That plus or minus little bit, that uncertainty.

23:35 What is the uncertainty in the volume?

23:38 Which is the length times the width times the depth.

23:40 - Oh, I can't even remember.

23:42 Is it, do you multiply them together?

23:44 - Yeah, do you multiply them?

23:46 Do you add them?

23:47 Do you average them?

23:48 Like what the heck?

23:49 Do you take the max?

23:50 I don't know.

23:51 Well, there's actually very strict rules about how you do it.

23:55 So when you multiply things, apparently, I didn't remember this but I've looked it up, apparently you add the uncertainties when you multiply things.

24:04 So in this case, it's 2.5 plus 2.6 plus 2.7 is 8.8% uncertainty.

24:10 That is super tricky.

24:12 And these kinds of calculations are the kind that ends up with spacecrafts burrowing into like a desert or into a moon because they're like, "Oh, did we get that wrong?

24:23 Whoops." did we use the wrong units or did we get the wrong uncertainty or whatever, right?

24:28 So there's this really cool library called uncertainty.

24:32 And it comes with all these different math operations like it has values like a float and it has a sine, right?

24:40 Which is like sine, cosine, tangent sort of thing. So you can do mathematical computation but instead of having a regular float it has an uncertain float, a u-float. So you create like x would say like ufloat of one is the value and then comma point one is the uncertainty.

24:57 And then if you were to do math with it and print it out, it'll say like if two times x would be two plus or minus 0.2.

25:06 And so it always carries its uncertainty.

25:08 And then as you take like the sign of it or you multiply or you square it, it will actually integrate and consider all those different uncertainties to give you a final uncertainty in your output.

25:18 Isn't that awesome?

25:19 >> That's very cool.

25:20 - Yeah, this is useful in lots of fields.

25:23 - Yeah, if you ever have to compute with uncertainty, this seems so glorious, this and Pint, right?

25:30 If you could put this and Pint together, then it's on.

25:33 'Cause Pint lets you work with different units of measurement and then add and multiply and divide them.

25:38 And then you throw the uncertainty on top of that, boom, you're golden.

25:41 - Yeah, yeah, that'd be cool.

25:43 We had worked with once with a measurement value that it was a power level for a cell phone, and the uncertainty ended up being plus or minus like the amount of power that the sun produces.

25:56 So it's like we essentially don't know the answer if that's the uncertainty.

26:01 - Right, right, right.

26:02 It could take a double A battery or it could melt the earth.

26:05 We're not really sure which.

26:06 - We're not sure which, yeah.

26:08 Not ready for shipment yet.

26:10 - Exactly, maybe we gotta like get a little more accuracy there.

26:14 Anyway, this comes from Tim Head who mentioned it on Talk Python where we recently did an episode on Binder, which is super interesting, but not yet released.

26:22 So eventually we'll talk more about that there as well.

26:24 Anyway, Uncertainty, cool little library if you gotta do any sort of computation with this kind of stuff.

26:29 - Yeah, I think it's cool, but I'm not sure about it yet.

26:31 - Yeah, well, can you ever be?

26:33 - No.

26:34 - But you can be sure about the level at which you can't be sure using it.

26:38 - Yes.

26:38 - Awesome.

26:40 I'm pretty sure that I wish my Python prompt was cooler.

26:44 - Well, I'm okay with my Python prompt, but--

26:47 I don't know. I mean, come on.

26:49 But think of all the options.

26:50 - You could do anything you wanted.

26:53 And I never thought to do that.

26:55 I mean, I do it with my, like a bash prompt and stuff.

26:58 You know, we put our virtual environment name in there.

27:02 It's stuff like that.

27:03 - Get status, get branch, all that kind of stuff.

27:05 - Yeah, definitely.

27:06 So you can change those things.

27:08 So why not?

27:09 This article comes from, I think, Arpit Bajani.

27:12 And it's called "Personalize Your Python Prompt." Those three right angle, right, what is it?

27:17 The right, greater than signs?

27:20 That are together when you're doing interactive Python.

27:23 Apparently you can muck with those.

27:25 There's a sys.ps1 variable that if you sign to that, you can change it to whatever you want.

27:30 And of course, the author didn't stop there, said, oh, it can be dynamic also, but you have to have a non-string object to make it dynamic.

27:42 So he gives a little example to where you can, And the way you do that is you have an object that has a Dunderster method.

27:49 If that has dynamic action, that gets called every time.

27:53 So for every prompt, so this is pretty neat.

27:55 And he has an example of doing some stuff, but I wanted, I didn't have time to do it this morning, but I was working on it.

28:01 I was trying to get a prompt that would mimic the Windows command prompt, because apparently I want that on my Mac, 'cause that would be fun.

28:11 - You just wanna confuse people, like, what are you doing?

28:14 - This is insane.

28:16 - I mean, C colon backslash greater than was easy, but I wanted to also put the path in there and flip the direction of the slashes and stuff like that.

28:28 - Yeah, yeah, that's really cool.

28:30 And I didn't, one, didn't know that you could just set that import sys, sys.ps1 equals something, and that now is your prompt.

28:38 But I didn't really think that it could be a dynamic object that has a str, dunder str, it's pretty cool.

28:45 - Yeah, that is neat.

28:46 - You could easily set up something like the Jupyter, you know how in Jupyter notebooks you have bracket one, bracket two, bracket three for your various calculations?

28:54 Like five lines, you got that in your Python prompt if you want it.

28:57 It doesn't have very much value 'cause you can't change the order, but still, it's pretty interesting, I think.

29:02 - Yeah, yeah, that's cool.

29:03 - Yeah, quite cool.

29:04 All right, well, that's a good little find, a quick and easy to play with.

29:07 - Well, do you have any extra stuff for us?

29:09 - Oh, not really.

29:10 I'll go and throw one thing out for you.

29:11 So I finished my Python for absolute beginners course.

29:14 And so now I'm starting a new course, which is like adding a CMS to a proper data driven web app.

29:22 So if you've got a flask app or pyramid or Django or something like that, and you want to let other people write part of the site, and the rest is more like Amazon would be with you know, here's the categories, here's the products, here's the product page, and here's a review page, like, you know, very structured, but you want to just let them like write free form stuff.

29:39 So I'm working on a course that lets you kind of add that to existing sites.

29:44 So that'll be fun.

29:45 I'm having a lot of fun working on that.

29:46 - Okay, interesting.

29:47 - Yeah, yeah.

29:48 - Is this kind of where the Markdown work that you were working on comes in play?

29:52 - Yes, exactly.

29:53 So I decided the work that I did for Talk by Don Training to build out the landing pages and the interesting stuff to basically make a whole section of that site just driven by Markdown and just editors and whatnot.

30:09 I'm going to take that, extract it, and sort of take it to the next level, like with rich Markdown editors and, you know, database backends and stuff like that.

30:17 It'd be fun.

30:17 Nice.

30:17 Okay.

30:18 Cool.

30:18 Shall we close it out with a limerick?

30:20 Sure.

30:21 I'm not very good at limericks, so I'll give this a shot, but this comes to us from Alexander A.

30:27 He sent this over, he had written it.

30:30 This is his, he wrote it recently.

30:32 And this is submitted, apparently there's some kind of limerick contest at Manning.

30:37 you win free content like books and whatnot if you submit a winning programming limerick.

30:44 All right, so here goes coding environments in three parts.

30:47 To this day, some prefer bbedit. VS Code is now getting some credit.

30:51 Vim and Emacs are fine, so are Atom and Sublime. But it doesn't matter much if you don't let it.

30:57 But wait, let's not forget IDEs. Using PyCharm sure is a breeze.

31:02 Komodo, Eclipse, and Idea, Clion is my panacea, and Xcode leaves me at ease.

31:08 But Jupyter Notebook is also legit.

31:11 Data scientists must prefer it.

31:13 In the browser you code, results are then showed.

31:16 But good luck when you try to use Git.

31:20 I love it. It's good, right?

31:22 >> This is great. Yeah.

31:24 >> Oh my God, it's so good.

31:26 Especially that last line. I love it.

31:28 >> Definitely makes the whole thing worth it.

31:31 Yeah.

31:32 Yes, indeed.

31:33 So, well done, Alexander.

31:34 Thanks for sharing that and letting us use it on the show.

31:37 That's great.

31:38 All right.

31:39 Anything else?

31:40 Do you got anything you want to share with folks?

31:41 I guess I jumped ahead of you and did my limerick.

31:44 No, no.

31:45 No, it's good.

31:46 We've got a whole bunch of great feedback from the most recent testing code episodes.

31:50 So, it's been good.

31:52 Yeah.

31:53 What are some of the ones?

31:54 I know you just did one with Anthony Shaw.

31:56 Yeah, we did.

31:57 And his plugin.

31:58 Yeah.

31:59 So, we talked about security.

32:00 about Django recently and just the most recent one is talking about the most downloaded pytest plugins. So Anthony Sotile and I talked about 28 of the top plugins. That sounds like the perfect show, that's really great. Yeah, really geeked out on a lot of stuff. I found some super interesting ones I'm gonna talk about the next show but we'll leave it at that. Awesome, thanks. Cool, all right.

32:25 Yeah, well, thank you as well. Happy to be here with you, like every week. Bye.

32:29 Bye.

32:29 Thank you for listening to Python Bytes. Follow the show on Twitter @PythonBytes, that's Python Bytes as in B-Y-T-E-S. And get the full show notes at PythonBytes.fm.

32:40 If you have a news item you want featured, just visit PythonBytes.fm and send it our way.

32:45 We're always on the lookout for sharing something cool. This is Brian Okken, and on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast with your friends and colleagues.