Python Bytes - #269 Get Rich and replace your cat

Episode Date: February 3, 2022

Topics covered in this episode: rich-cli Documentation unit tests Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/269

Hello and welcome to Python Bytes where we deliver Python news and headlines directly to your earbuds. This is episode 269, recorded February 2nd, 2022. And I'm Brian Ocken. And I'm Luciana. And I'm Brett Cannon. And we have Brett. So we invited Luciana on and we decided to have Brett on also. So we got to have some fun. Michael's actually gone this week, but hope he enjoys listening. So hi, Michael. And we'll talk to him next week.

So before we get into the topics, though, I think people hopefully know who Brett is. Brett Cannon, you've been on the show before. A couple of times. Yeah. Thank you very much for having me back spontaneously. Spontaneously. Like minutes ago, we said, hey, we should get Brett on. So, Luciana, welcome to the show.

Can you tell people a little bit about who you are? Thank you. Yes. Well, Luciana, I work with Brett on the Python extension for Visual Studio Code, but I'm a program manager. And yeah, I'm very excited to be here on the show. I was telling Brian that I used to listen to Python Bytes going to work back when we worked on offices. So it's really, really cool to be here. Yeah, nice. Well, thanks. I'm glad to have you here. So let's jump into really cool to be here. Yeah. Nice. Well, thanks.

I'm glad to have you here. So let's jump into the topics. We have an abbreviated list of topics, but we'll make it fun anyway. I'm going to start us off with Rich CLI. So Will McCougan, it seems like we talk about him every show, but this is cool. So I was like, I'll try it out first.

And I'm already hooked. So Rich Salei is, it seems lame if I describe it. So you install it. I installed it with PIPX because I just want to use it everywhere. And then what it does is it does pretty printing of stuff. You can give it a file, and basically that's what I use it for.

Maybe it does other stuff, but you can give it a file like example.py or example.markdown or something, and it will do the rich printing, pretty printing right on your screen in the terminal. That seems like not that big of a deal, right? But it is so cool because it's all like nice colors and you can have themes. Um, and I used, uh, what you can, you can do pretty printing of Jason. So it'll format your Jason for you without having to reformat it. Uh, you can do a dash M flag for markdown. I've been doing that to see my Markdown. It

does some cool stuff with Markdown. Although, supposedly, like with Python files and C++ files and stuff, it's going to do syntax highlighting based on extension. I'm wondering why I got to pass in a dash M for Markdown. It seems like dash MD should work fine.

It's actually going to be my immediate question was, why do you have to specify the dash M just for markdown. It seems like it's dash MD should work fine, but. It's actually going to be my immediate question was why do you have to specify the dash M just for markdown? And then like, and then there's some flags that's cool. Like, like whether, whether or not you want to use it with pipes. So you can for, if it does, if it's pipe it to something, it will, it'll strip out the formatting stuff like the color codes and whatever but you can force that to be on well i wanted to i tried to use it with a big file and it just flew past me and um and then so i tried to pipe it to more or less

and it uh it stripped out the formatting and so well i tried to fix that and then more and less don't handle that and so and this was just yesterday i'm like kind of really be cool if rich cli has supported paging with within it and so today uh will said hey i added paging to rich cli so which cli now has paging so of course he did like within a day so So anyway, pretty cool projects. Either of you check this out yet? I did the exact same thing you did. I used PipX and installed Rich CLI yesterday.

One thing is I will say I've actually been using a replacement. So this is kind of like a replacement for the cat tool on Unix, right? And I've been using an alternative called bat BAT that's implemented in Russ and has a lot of this as well in terms of color syntax and stuff. But I'm willing to bet Rich is rich. I'm willing to bet. Will is going to move a bit faster. So I'm just going to probably switch over to using rich CLI over bat and just see where this goes. But I mean, come on, Will even made the output look great. So yeah. Sorry for the output for the help.

It looks phenomenal. One of the things that I noticed was that the default theme, the coloring didn the coloring was, didn't look quite right on the black background that I was using. So I just, I exactly, I was using it for cat. So I just aliased my cat to use a rich with, uh, the, uh, Monokai format format turned on. So, um, Luciana, would you use this for anything yeah i was gonna say i'm behind i haven't tried it yet but uh once i saw the amazing things they have there it's quite a few uh i was like excited to try it out so we'll do it today hopefully yeah cool um well uh let's switch over to debugging. Yeah. So I guess most folks, I don't know, at least I, when I started learning Python, I used to debug using pre-statements, which is like no shame in that.

It works very well. I still do that when it's like for real quick things. But I wanted to bring up this awesome tool that we have, DebugPy. It's a debugger for Python. And you can use it as a CLI tool. You can also just import it and set breakpoints normally. I'm a big fan of UI debugging, so I actually prefer to use it built into the Python extension for VS Code, which is the thing that we work on every single day. So yeah, I wanted to bring up a few features that are really, really cool and

I find very helpful and that save up, helps me save up a lot of time when I'm debugging code. So, the first one of them is kind of like conditional breakpoints. Yeah, sorry, go ahead. No, no, go ahead. Neat. Yeah, it's super neat. And this conditional breakpoints is something that I bring up because I guess when you're trying out debugging for the first time using the UI, you set up a breakpoint and then you hit it there, and then you always reload the window or reload the debugger,

sorry, to hit that breakpoint again. It keeps stepping over until it hits a condition that you want. In this GIF there, they have an example in TypeScript, but it works on Python files as well once you install the Python extension. But basically, you added the breakpoint to insert a certain condition so that the bugger will only stop when that expression is met or the condition is met. So one example there is hit count.

So you can imagine if you have like a for loop, and you really want to stop when, for example, after 10 iterations of that loop. So you don't want to stop on that breakpoint and hit the step over 10 times. You just want to stop when it hits 10 times. So you can do that with the hit point. You can also do that. And it's pretty cool. Saves up a lot of time.

And you can also do log points instead. If you're not interested in breaking the execution, you just want to make sure that line was executed. So it prints out on the output that, hey, this is, uh, we hit that point. This is like a log point, so it doesn't really break anything. Um, but it's very informative. Cool. So this is, this is an extension for, um, for VS code. Yes. I believe most IDs support that same feature. Um, but it's a feature that I always recommend folks to look for in their ID or editors because it does save a lot of time.

So to be clear about the tech stack on this, so there's a couple layers to this. So at the bottom layer is PyDevD by Fabio Cedrosny. Key, we have them on contract as a consultant to do anything we need to have get fixed and stuff and just support the project. Because on top of this, we have another project that we have called Debug Pie, which implements what's called the Debug Adapter Protocol or DAP. It's a meant to be a language agnostic protocol for debuggers to talk to editors. It comes out of VS Code. It's used by Visual Studio as well.

And actually, it's now used by Jupyter. This is how Jupyter was able to launch recently with debugger support. Because they actually run DebugPy. And then on top of that, we have support. Because we're a VS Code extension, we support the debug adapter. So we ship DebugPy in box right now for supporting this. Although we are talking about breaking the extension, breaking debugging out to its own extension

so that we can actually update it at a better cadence with debug pie because we can do platform-specific v6s now, extensions for VS Code. So we'll be able to shrink that down a bit for our users. So is there like a tutorial somewhere that has like all of the cool Python extensions that I need for VS Code to get VS Code with Python to work really great? Yeah, we have our get started tutorial. It doesn't have a lot of extensions. So there's definitely more extensions that I find to be personally cool.

Maybe we could have a blog post about this and there's definitely more extensions that I find to be personally cool. Maybe we could have a blog post about this and like cool extensions for Python specifically in VS Code because there are some of them. I think Don Gemini, he's the one who created the Python extension before it was a Microsoft thing and Microsoft Hieronym and everything. So he has one that I always talk about, which is the Python environments manager extension is just displays the environments that you can find in your machine and what packages are installed there. It's kind of like a environment viewer. And it's pretty cool. It's one that I always tell people about. So you know, a deep dive into all the useful extensions to add would be a great testing code episode. Just saying. I love that idea. I like it. Okay.

Well, speaking of plugging stuff, I want to take a moment to thank our sponsor. So this episode is sponsored by Datadog. Datadog is a real-time monitoring platform that unifies metrics, traces, and logs into one tightly integrated platform. Datadog APM empowers developer teams to identify anomalies, resolve issues, and improve application performance. Begin collecting stack traces, visualizing them as flame graphs, and organizing them into profile types such as CPU, IO, and more. Plus Datadog APMs live search, so you can perform searches across full streams

of ingested traces generated by your application over the last 15 minutes. Try Datadog APM free for a 14-day free trial, and Datadog will send you a free t-shirt. And actually, I have one of these purple t-shirts, and I love it. So visit pythonbytes.fm slash Datadog will send you a free t-shirt. And actually, I have one of these purple t-shirts, and I love it. So visit pythonbytes.fm slash datadog, or just click on the link in your podcast player show notes to get started. Awesome.

I got to pay the bills. So where are we at now? We are back on me again. Unless, Brett, you got something right out of the blue you want to talk about uh well i put you on the spot that's okay uh i i believe you've talked about exception groups on the podcast already i don't oh yeah i think so yeah so just because dated all the sponsor actually cares about trace packs and stuff, one interesting thing that's coming up in terms of a PEP,

it has not been given to the steering council yet, but there's actually a PEP coming up that's going to add a Dunder notes field potentially to exceptions. This actually came out of the exception group work because Zach from Hypothesis was working with it over on that side. And realized that it would be convenient to be able to kind of just basically, literally, the name says, add a note to extensions to kind of help explain why this came about. And so there's a pep coming that's going to basically just allow libraries and stuff that work with exceptions to just

attach a little note saying this is why this happened more than just a little thing especially for exception groups you can kind of get kind of big and murky by having a single note added to it to help explain why this came about um it's hopefully gonna help make it easier for users to understand a bit more why something happened. So that's that's pretty neat. I like it. Nice. I got some feedback recently that I'm not covering enough test stuff on Python bytes. So I'm going to try to I'm going to try to try to solve that.

I'm not going to cover test of every week, but I've got a test thing this week that I'm pretty excited about. So Simon Willison, a great guy, he wrote an article called documenting unit tests. And this, wow, it's old. It was came out in 2018. I just noticed it. So yeah, there's the internet for you. Um, but it's like, it's a super cool idea. So the idea is we've got tests like PyTest and other test runners. You can do anything. Uh, he's using PyTest, uh, to test your source code, but why not? And Python has all these introspection things you can do. So he's using introspection to look at the code and then introspection to look at the documents with, with his test code and then make some,

make sure that there's some items that are definitely in the docs as an example. So in this, this, his example in the, in the doc, in the blog post is mentoring his project data set. And so the test for this is right there.

So you can go take a look at what he's doing. But he takes a look at the repo. And for instance, if he adds a config option, he's got to test to make sure that the config option gets documented. That's cool. So it's just tests or fail if he forgets to document a new option. Also plugin hooks, and different views within data set, they all have to make sure that he has special the views, like he wants special pages for each view. So it makes sure that there's a page

there. So I just there's a couple neat things here, just the concept of using tests to make sure that there's things documented. It doesn't tell, he makes a comment that it's not telling like a lot of tests. It's not telling you that the documents are good or documented well, but that they're documented at all, which is, which is good.

And same with our code tests. Don't necessarily tell you that your code is perfect. It's just that they're tested. The other thing that I wanted to point out about this is there's some nice use of features of, of PyTest. So there's a nice use of fixtures and parameterization. So he's got like the views, for instance,

he goes out and looks at generate, like goes and gets a list of views from the code and then use that list to have a generated test to make sure that each of those views is tested or is documented. It's a nice idea. I've been trying to do that sort of generate generated parameter lists. I'm trying to do that more in my code because it, it's just kind of a cool idea to generate your own test cases. So anyway,

good job, Simon. Yeah, as someone who spends more time reading code and writing code, I definitely appreciate this initiative. It's very much better to have documented code out there. Well, a combination of making sure that the documents are tested or things are covered. And then also, I think a few episodes ago, we talked about, um, uh, a project projects using, um, um, generating documents themselves. So like for instance, uh, instead, if you're going to plop your help text, uh, in your document, don't copy and paste it, use code to generate that. And then it's always

going to be correct if you got it in your build system. So nice ideas. And it was about using cog, right? Yeah, that was it. Cog, I forgot. Yeah. And what I really love about that is when I came across Cog a long time ago, I thought, I got to have a use for this, but I can't think of it. But this is the perfect use because we often do that within our little readme or something is just to plop a little example of code using your tool, whatever library you have. So having Cog generate that for you is great. So I think I need to go back and do it.

So I've got a little toy project called cards that I use for teaching testing. And, and I changed the interface for it for layout reasons that the, the tables that I was using didn't show up in eBooks very well. So I switched the switched the table format, but then I forgot to change the readme. But if I had had cog in place, I would already be doing it.

So it's a neat. My first thought was to write tests to make sure that the output in my readme was the same as the code. But I think a better idea is to just have the readme generated. So, I mean, either one works, but both are good ideas. Yeah. And to tie this back to this point, Simon's the one that actually

started the trend on Twitter of everyone using cog to use this on the readme. At least that's how I first came across it. And then I subsequently saw multiple people do it. And then I finally had the same reaction you had, Brian's like, oh yeah, I've been looking for a reason to use cog for ages. I never quite had one. I was like, this is a great one. So I went and updated the readme for the Python launcher to use this to generate all the URLs for downloading the built binaries for it.

So it's great. Gulf binaries? Built. Built binaries. Okay. Because I tried to build the launcher for like a bazillion different platforms. And I'm grateful for that because I'm using the launcher like almost every day now.

Oh, fantastic. We are. Thank you, Brent. Well, so let's pop over to talking about ourselves. Oh, that was such a good, wow. I'm impressed. Yes. Pep 673 self-type.

I heard from, well, Brett Cannondare that it has been recently accepted. And it's interesting for me because I'm now learning more about types in Python. I'm very new to it, admittedly. And I thought it was interesting because, well, adds this away to anything methods that return an instance of their class. And they give a very cool example there of a class or shape and then we have circle that

inherits from shape. And then shape has this method called setScale, and then the type that returns is shape, because it returns self. For circle, it returns self as well, so it's a type circle. Then it shows there are some, for example, editors that may throw in error when you call circle setScale, which is a method from shape, and then setRadius radius which is something from circle

but once you call them it will say error because shape doesn't have this method that is specific to circle so to kind of like have this a better way to to frame that would be to return self and it was accepted and it's very interesting i feel like it's it seems very clean to me and a very good solution so i'm personally excited that it was accepted it was very well explained as well and like that was real for people on the podcast who can't see uh but um brian's scrolling through basically uh think of capital s self as the return type for those all those class methods you write that construct an instance of your object this is what this is like built for right it's fantastic if you have the from whatever method class method on your class to construct that instead of that class from something else

you'd now have a return self with a capital S versus specifying the exact class that would have returned. So you don't have to worry about what that's going to look like and having to worry about the spelling or any of that forward declaration problems you can have if you don't do from dunder future import annotations. Where it's like, oh, I'm referring to a name that doesn't exist yet, and Python throws a fit because that object doesn't exist yet by that name. So it solves a couple problems like that, but it's really, basically, if you write class methods

that construct instances of that class, it's great. Well, I don't, but I probably will now when this comes out. So is this part of uh 311 do we know 311 right yes nice yeah so you can probably get that probably today if not in the near future from the typing extensions package which kind of tries to do a back port and forward port of anything in the typing world that's experimental or has been landed but not in a release yet. And I believe the type checkers,

I don't know if they all support it yet, but I'm sure very shortly they will all support this. So you can get to it today. And then we keep people that are writing tools like Flake and Black on their toes catching up with all these changes. Well, luckily it won't hit them because it's all typing. So just

strings to black and I don't think Flakey will care. But like mypy, pywrite, pylands, pytype, pyre, all those type checkers are the ones that have to get updated for this. But they were all in on the discussion of even proposing

this. Nice. checkers are the ones that have to get updated for this but they were all in on the discussion of even proposing this nice but they were is that we repeat that so the all these uh these people writing these tools were involved with this these sorts of type processes yeah so the way typically decisions around typing happen especially from a static typing perspective not i don't want to make statements on Pydantic's part in the dynamic typing world, because there's kind of two parts to typing, right? There's the general typing as in, oh, there's the concept of typing now in Python, but there's the people who do static typing, right? And that's the kind of thing where you add your type annotations, your type hints, and you run a tool later that somehow reads them

offline, as it were like like my pi or pi write or whatever and then there's the dynamic typing folks that's like pydantic where during runtime they actually look at the annotations from the static typing perspective there's something called the typing sig it's a mailing list and all the major static type checkers all work there together to try to figure out where they want to take things and kind of what gaps there are in terms of typing. Basically, how can they move typing forward in Python? It's also a place people can go to ask for help if they have a generic typing question that isn't tool specific. But to answer your direct question, Brian, the tools that are

involved there, which are basically all the static type checkers that I know of. So there's PyWrite, which underlines PyLance, which is what we use for our completions in VS Code. There's MyPy. There is PyType that comes from

Google. And then there's Pyre that comes from Meta. Okay. Wow. dizzying. Yeah, although, I mean, one of the nice things about all the peps, right, is this is all backed by specs. So there's not a lot of crazy deviation, as it were from the semantics, it's more of a bug, if someone disagrees. So they're all pretty pretty consistent but some of them do a bit more like inferencing like pi type is does more like runtime inferencing and other inferencing to try to kind of fill in the gaps that's actually why google wrote it i think to help them move over to python 3 start introducing types to their code base yeah um so they all have slightly different

strengths and weaknesses but they should at least type, more or less once they've all implemented the same specs lead to the same type outcomes as it were. Yeah. Okay, cool. See, I learned so much about typing just by listening right now. Yeah.

Well, we're we're to the end of our normal topics. But Luciano, do you have any end of our normal topics. But Luciano, do you have any extras for us? Yeah, so it was announced in my team that Black is no longer in beta version. So version 2020.1.0 has come out. So it's their first stable release, I believe. So that's very exciting i really like

the highlights um that they have there that python 2 is no longer supported nice so that's a cool announcement for the week and the other one that i have is to remind folks about pie cascades 2022 it's happening this weekend it's remote uh tickets are on sale so if you're interested in joining the events really awesome it was my first python conference and the community there is just really amazing so again remote join us this weekend pike Cascades was your first conference? It was. It was back in 2019. Was that the Portland one?

It was in Seattle. Seattle, okay. Yeah, I guess it was the 2020 one that was in Portland, right before everything shut down. Yes, 2020. It was right before it, yeah. Yeah it. That was the one I had to miss because I was out of the country on vacation when it happened. Yeah. Not in China, I hope.

No, I was in Thailand for a friend's wedding. Interesting. Nice. That was back in the day when we kept track of what countries do have COVID cases, not how many cases in every country. So it was, it was a different time. Yeah. So I only have like, I guess one, I don't have a,

anything to show for this, but I did a couple extra things. I, it wasn't going to talk about it too much, but I did notice that pip is now at 22, version 22 dot something. It's what we're at 2202 now. But one of the neat things about it is there's some cool stuff around having pip vendor. There's a couple of neat things. There's one of their vendored sum of rich. So some of the, especially the error output error output, um, if everything goes great,

you probably won't notice much of a difference, uh, except for maybe the, um, progress bar if things are slow. Uh, but the, but the error report of something goes wrong. Like if it's building something, um, that's where things, uh, apparently show up really neat, uh, some better, better error outputs and better error outputs are always great also interesting that they replaced talks in their development workflow with nox and i'm i don't know if that's worth noting or not but it's interesting nonetheless yeah i know predium one of the core developers of pip is a big no Knox fan. I'm also a Knox fan. So I think part of that's just kind of the difference.

For those of you who don't know the difference between talks and Knox, other than the letter, Knox is a bit more of a, I would say, general task runner. So because you can write just straight, it's writing just straight Python code. So I think for projects that like to use it for release process stuff, like on the packaging project, Pridion wrote a Knox file that has literally a release command that will do everything you need from within Knox so you don't have to have a separate shell script

or something else. So it can all be in the same file that you also specify how to run your linter and how to run your tests and stuff. That's pretty neat one of the things that i've um and i i don't remember if there's a way to get around it or not talks operates in a virtual environment so it creates so one of the things the the default behavior at least creates a virtual environment um and then runs uh runs whatever you're going to have it do within that virtual environment. So like the idea being you're going to have multiple Python versions, so it creates

a virtual environment for each Python version that you're running. There's some stuff like this extra stuff, like I just want to publish now. I'm already in a virtual environment because I'm always in a virtual environment. don't really need uh talks to generate another one just to run a command is is that sort do you know if that sort of thing is easier in nox or does nox also create a virtual environment before it does stuff so nox can create a virtual environment i can't remember if it does automatically for every command. Putting you on the spot. But it's something I'll look up then.

Ask Thea, she can tell you. Yeah, yeah, definitely. So go ahead. Sorry, I was gonna say that, speaking of pip being updated, I was trying to use it with pip tools today, and it seems that pip tools is not working with the latest version of pip just

fyi there's an open issue i'm sure the team's investigating but for all pip tools users there you're not alone yeah so the problem yeah so what so i can yeah uh so what happened was is pip tools is using the private api of pip and it changed and so pip tools broke so pip tools if you use it you will need to pin uh to a version uh pip 2021 or older uh to work with pip tools until they figure out what they need to do to uh to use the api the changes that pip made to their internal api and to be fair to the pip tools team pip 22 just came out like a handful of days ago so it's really new yeah i'm a huge fan of definitely love it so um well one other thing actually yeah just one other thing on the new pip release uh for people to be aware of so one thing that happened here is to try to cut down on the vendoring, pip stopped vendoring HTML5 lib and now use the HTML parser in the standard library.

And that actually broke a bunch of simple repo API indexes. For those of you who don't know the simple repo API, if you go to any URL in PyPI for a project and replace the project part of the URL with simple, you'll see what I'm talking about. But basically, there's a spec that just says, there's a pep that says, hey, write this HTML, and then packaging installers can read it and figure

out where to find all the files and the projects for something it turns out a lot of people weren't following the spec and so it all so a lot of um these indexes broke because pip wasn't able to read them anymore because it couldn't be parsed as pure html uh they were doing funky things that broke so they i believe either have or are planning to roll it back with a flag to let you alternatively use html5 lib for now with the goal of getting all these projects that have broken output they don't follow the spec to fix themselves so that they can go back to not having HTML five lib in box. So just a heads up, if you use an alternative package index and it suddenly broke,

that's why they're working on a fix. But I would talk to the project that creates that index for you and have them work on making sure that that project creates valid HTML5 that can be parsed by the HTML parser in the standard library. Because that'll probably go away in PIP 23. But it's not broken now, right? It's just flagged? It was broken. They didn't realize how much of the world was doing invalid HTML for these indexes.

So I don't know if it's in 22.0.2 or if it's going to be in the next release, but there is an open issue where they're where I at least was looking at where they were fixing it. Cause I got looped in because I have one of my side projects, mouse bender that actually wrote some, some code around this originally that there's talk about moving up to packaging up that a lot of back behind the scenes stuff no people don't need to care about i hope that yeah no go ahead well i was just gonna say so the plan is i think is to add a flag to say use old html parser or something

along those lines for now so you can say hey use the html5 lib version of parsing html but it's just just to be clear here, there will be a fix, but it's a temporary fix because people should be getting after their projects that create these indexes to do the right thing and actually follow the standard. Okay.

So as someone that got bit by this, because we have an internal PyPI caching server that also we store our own stuff on and we don't own it. We like, it's a third party thing that we're licensed. So I don't know how long it's going to be. So hopefully that hopefully they move quickly,

but at the same time, hopefully this extra use the old one flag or whatever will work for a while. I was a little surprised when I saw the flood, the warning pop up of like, Oh, you're not using a good, you know, it's invalid HTML. And I'm like little surprised when I saw the flood, the warning pop up of like, Oh, you're not using a good, you know, it's invalid HTML.

And I'm like, what am I supposed to do about it? But I don't think the bit developers were expecting it to be so widely broken either. Right. It's like, what are these projects doing that are creating invalid HTML? But I did it all the time though like okay but it's

fair it works if it works it works it's html yeah well and that was the problem right is the spec very the the pep that defines it very specifically says it must be valid html5 and i think it was specifically so that it could be parsed by the standard library so it also means none of these these pages could even been parsed by the standard library so i think that's what happened right is people because people because pip had been using html5 live which is obviously way more lax in terms of what it can parse everyone just like okay it's good enough and didn't realize that the spec specifically mandated valid html5 and so hopefully all these projects that got caught up can get a fix out over the next year because as i said i suspect this will be in until pip 20 pip 23 which will come out in 2023 so it's

not like it's going to disappear in a month this flag so let the fix out but hopefully everyone can kind of get caught up so that they can get back to not vendoring html5 web okay um before we go jump to a joke i want one last extra is for the first time in like 18 20 months i'm not writing a book i'm no longer writing this book the writing is done the editing is done so it's it's off to all the rest of the cogs that have to go through the process to get it. But the ebook right now is really solid. So anybody that grabs the ebook now, if you've grabbed it before, it's all the updates are there, but this has got all the copy edit changes and the final edits, the rest of its layout and stuff to try to get the physical book form. So that's coming out sometime this month, maybe, hopefully. so that's my hope is by the end of

february i'll have a physical copy in my hands but well congratulations we everyone who listens to this podcast and testing code anywhere else for you have no you put a lot of blood sweat tears and love into that book so congratulations for each and well i just was realizing that my youngest is what my youngest daughter's 12 i spent a year and a half on this book a year and a half on the first edition so i've been writing about pi test in book form for a quarter of her life um that's a pretty weird um i'm ready for a joke thank you for your work brian well i'm gonna be reading a physical hobby hopefully so one of the So one of the, and one of the goals of the second edition was to try to put it in a

format that would be easy to teach, easier to teach and learn. So I'm the next step is I'm going to work on trying to teach people in person, teach people in person and through video courses and stuff like that. Turn this into, because I know a lot of people don't read, but you're coders.

Why don't you read? You have to read your code, but still some people don't read books. Um, how about something funny? Yes. Today's joke brought to you by Luciana. Thank you for finding something funny. Um, and we'll add this to the thing. So I love this. So for people listening, there's a picture of, of, of an ocean and you've got a really big ship. It's called, I don't know what's on the ship.

It's a big ship. I don't know. I don't know. But it says, but it looks all official, like everything. It says proper software design. And then there's a guy on a surfboard standing up.

So it's like a wakeboard thing. And he's holding an umbrella, getting pulled by an umbrella on a surfboard and says, whatever I'm doing. So it's funny. That's how I feel whenever I'm coding. And sometimes it feels like this going from the old days of these huge design documents to now, oh, we're doing Agile, so let's just write some ideas on some post-it notes and stick

them on board and run from it with there. If it works, it works, right? Yeah, it's got tests, right? Well, I think so. It's unit tested. It's 100% coverage. It's's good let's ship it so perfect perfect nice well um first of all thank you luciana for joining the show um i think it's your first time right yes it was my first podcast uh awesome participation thank you for having me

and thanks brett for joining last minute yeah thanks, Brett, for joining. Last minute. Yeah, thanks, Brett. It's always good to see you. I'm happy to play the fake Michael for this episode. Thanks, everybody, on the stream for showing up. And we'll see you all next week. Thanks 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.

Get the full show notes over at pythonbytes.fm. If you have a news item we should cover, just visit pythonbytes.fm and click submit in the nav bar. We're always on the lookout for sharing something cool. If you want to join us for the live recording, just visit the website and click live stream to get notified of when our next episode goes live. That's usually happening at noon pacific on Wednesdays on YouTube. This is Brian Auchin. On behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast with your friends and colleagues.