Python Bytes - #345 Some Big Time Releases

Episode Date: July 26, 2023

Topics covered in this episode: Cython 3.0 Reading code : An important but seldom-discussed skill Major new version of MicroPython: v1.20.0 Advanced Python Tips for Development Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/345

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 345, recorded July 26th. Is that right? July 26th, 2023. I am Brian Ocken. And I am Michael Kennedy. And, you know, 345 episodes, you'd think I wouldn't have to read that, but I still do because I don't mess it up. Anyway, a lot of fun topics today. Our sponsors today are us. Of course, as a Talk Python training, we'll talk about those. And the new Python People podcast. And our Patreon supporters, of course.

Thank you, everybody, for continuing to support us. And everybody that's listening to this, usually, so this is a Wednesday morning, but usually it's Tuesday at 11 Pacific is when we're recording. If you are around at that time, we'd love to have you join the show. Just go to pythonbytes.fm slash live, and you can see when the next episode is going to get recorded. Yeah, Brian, I usually try to,

I'm not always successful. Also, sometimes I just don't know. I usually try to schedule the next live stream soon as we're done with this one. And so if you go to YouTube, you can click notify me for just that event if you want to come to the next week's one or something. So that's kind of the best way to know when the next live stream is. Yeah. And I appreciate people to show up and add comments. It's nice. So Michael, why don't you kick us off with the first topic? Yes, indeed.

This is a very, very exciting one. So the next topic, the first topic is the third version of Cython, not CPython. I didn't drop a P on accident, Cython. Many people know what Cython is, but I suspect sufficiently many don't that it justifies me saying what the heck it is. So Cython, let's do a throwback, Brian. This will be fun. You've done plenty of C. Do you remember inline assembler when like little sections of C code

had to be like really close to the metal? And so you would write like a little bit of assembly inside of a C function or make a function in assembly and call it something crazy like that. We're talking like 90s. Yeah. Well, Cython is kind of like that for Python. If you've got some part of your code that's not fast enough, well, one of the options is to do what a lot of people are doing is go like, well, I'm going to go learn Rust

and I'm going to write this section in Rust and then I'm going to import it into Python. And there are certainly tools for doing so, but what if you could write Python and make it as fast as C almost? And that's what Cython is. And it's kind of like this inline bit, like this function or these, this module, I need to be in like closer to C speed, farther from Python speed, especially in the math type of scenario. So that's what Cython is. It lets you write Python code that gets compiled to C and use very, very slight variations in the Python syntax. It used to be way different. You'd have to have your own types and they were imported from Cython. So instead of having a traditional high object derived integer type, you would actually have a

Cython int, which was like a local int, and you would express that in different ways. And they've been moving towards what they call pure Python mode, where the code that you write for Cython is actually still valid Python if you wanted to just run it that way. And that's pretty cool, right? Yeah. That involves things like type int. So if you want to say,

oh, here's a thing that's an int, instead of importing some specialized int type from Cython, you would just say x colon int. And guess what? That's how it works in modern Python. So the news for this week is that Cython goes 3.0, and this news comes to us from, let's see. Oh, no, I ran across this with other ones sent over.

They're both new releases with lots of details, so sorry. Yeah, so anyway, this one, the headline here is that it says, long in development. That's in like five years it's been working on this. And so it sheds legacy Python support. That is Python 2. Look, see that legacy Python people are starting to adopt our term. I don't know if we had anything to do with it,

but we sure tried to popularize that view of Python 2, didn't we? Yep. And it has a lot of boosts for this pure Python mode that I talked about. So you might say, okay, well, that's interesting that you have this pure Python mode, but why would I really care? Because if the goal is to make it faster, I don't want to run it in pure Python. I want to run it in Cython. So compile it to C and then behind the scenes as part of your building of the wheel and

all that. The reason you might want to do that is what if you care about MyPy or you care about Ruff or you care about Black or all these other tools that are Python tooling to understand the Python code or even PyCharm or VS Code, right? You want it to look at that and be able to lint it and format it and understand it, right? So the pure Python mode allows you to do things like keep your linting tools, right? Yeah, and also just there's been discussions basically that if we had type hints when Cython started, they probably would have used them to start with instead of their own thing.

Yeah, they had no alternative, so they came up with something. It's just interesting that it kind of came, I mean, I guess it compiles to C, so it makes sense that it had like a really strong C flavor in the way that you wrote it. Yeah. Yeah. So what else is notable here? So there's major NumPy support improvements. So Cython's worked well with NumPy, but now with Cython 3, it gives you the ability to write NumPy ufuncs. I don't do enough NumPy to know why I care about ufuncs, but you can write them directly in Cython. So my understanding is basically that instead of going through the Python API and layer to work with NumPy, it drops down to the C layer. And so it's like C to C interoperability when you're

doing NumPy within Cython. That's pretty cool. Another thing that's not mentioned in this article that I'm linking to on InfoWorld that's really cool about NumPy, about Cython is you can remove the gill. You can go no gill. There's a context manager that's just called no gill. So I can say like with this section, i'm going to do a bunch of code and i don't want to i want to release the gill for other parallel processing stuff so if multiple bits of code call that into that function and they're being done within threads they can run truly in parallel on hardware right on the cores right true os thread parallelism which is pretty excellent now the limitation there is that uh you can't be working with directly with the python api right like say

list or something because those assume that they're thread safe because of the gill right but uh if you're just doing like your own algorithm right that then you can which is pretty cool and yeah that's that's pretty much it so uh well done folks on that it sounds like a ton of work but yeah yeah and you are interested in cython check this out um zero in the audience says uh cython is great for h waiting for h pi output nice all right well that's number one. Okay. Which is actually number three. Oh, yeah. Because it's Python 3.

Exactly. So I want to talk about reading code. And I kind of agree. So this is an article by Eric Mathis. And he's the dude that wrote Python Crash Course. And it's on its third edition now. It's a pretty good book. Anyway, reading code, an important but seldom discussed skill.

And I have to agree with that. I've had many discussions in the past about coding standards within teams, and I try to have them be lightweight. It's better to just teach people how to read code. And so I'm mostly bringing this up because I definitely agree that we need to talk about it more, especially when teaching people reading code and reading, like we often tell people go out and read the, the source code for some popular third party libraries or packages or,

or even the, the internal, the internal Python standard Python library. But it does take some skill to read code. So anyway, he takes an example of a lottery example or something that doesn't really matter. But there's a few techniques, a couple techniques that he lists that I really like.

So there's a, if you just look at code, you've got a whole bunch of comments, you got a whole bunch of stuff going on often. And one of the things he says to start with is ignore the function definitions, which is interesting, because the function definition is where the name of the function is,

but just sort of ignore that for now. And he doesn't say this, but in his example, he said, ignore all the comments. I mean, he took out all the comments and the function definition and just so that you can just see the code and not everything else. And I actually, I had a code base once where I had, there were so many comments that I wrote a little script that would strip the comments out so that I could read the code better. Anyway, it does, it's a, you can mentally do it when you, when you're kind of have a, when you get used to doing this and also IDs help.

But that's a great way to just sort of simplify what you're looking at so that you can mentally see what's going on. The second technique is to simplify repetitive blocks. Like in the example we're showing, there's a couple big print blocks. And he his example says mentally, you can just lump this into print a message and and that helps you and then there's really not that much code left when you're looking at it and so that that he talks about trying to make sense of it i'm not gonna uh throw any i'm not gonna discuss really what i think of the quality of the code he's showing, it's fine. But, and then the last thing,

or one of the next to the last is to talk about using an IDE. And so I do this a lot with many IDEs, I think all of them now. You can like, just instead of hiding the function definition, you can hide everything but the function definition on a lot of functions. And especially if you've got a whole bunch of helper functions that are cluttering up your workspace or in weird places, you can just hide them so that you can see.

So like in this example, we've got get winning ticket, check ticket, and make random ticket. And then you can kind of a part of one of the functions but maybe i also want to see like one other function so especially if you're looking at two functions you can hide the rest of them it makes it nice um yeah it usually goes under the the term of code folding yeah that's it yeah but um then uh off a great discussion of uh think about this think about that people are going to read your code and try to understand it. So think about that when you're writing code. So writing readable code.

One of the things he didn't bring up that I want to make sure about is, so this technique of like hiding the function definition, one of the powerful things about this is because we have mentally, when we're reading code, at least when I am, and I think this applies to a lot of people, we believe the function name and we believe the variable name because somebody chose it. But so therefore it really needs to be accurate. It should be, it's hard to name functions and variables, but sometimes they drift. Sometimes the, like, it'll say like set name or something,

but it does a whole bunch of other stuff. So if it does a whole bunch of other stuff, you're gonna have to change the name of the function because if the function's name is not accurate, people are gonna fold it up and just assume that's what it does. So I would add to this, make sure your function and variable names are descriptive,

and change them when the body of the function changes. Yeah, it's interesting. I just had Eric on TalkPython, which is not yet out. So, you know, time travel, podcasts. He was both there and is not there. And it's sort of an Heisen-Eric sort of thing going on there. But a couple of thoughts on this. I think if, it's kind of a big if in the

comments or or hinting towards this in the live stream as well if the the naming is super good i i kind of prefer the second way like collapse all the functions and then expand them as you're like uh that's not clear what this is doing like let me dive into that but you know print print header like okay well we'll just we're gonna assume that that prints the header and just go on, you know, or, you know, things like that, right? Where it's pretty straightforward and there's not a lot of, I wonder what the algorithm does there.

It's like, eh, not too much. So then I like to kind of fold it down. But if, I'm not sure that I would take away the function names. I guess it would be like a unique IDE plugin where you could say like inline everything and even if there's repetition just inline it and just like you know and then work backwards as a way to understand don't do that in the main branch but that'd be that'd be interesting

to do but kind of in the reverse a lot of times what you'll end up with is a function that's like super long and poorly structured if you're trying to understand it. If just reading the function name doesn't work, it's usually because it's a big glob of a mess, right? Not always, but often. And so the part where he says, comment out this, instead of having all the steps of like, print the winning thing, and here's like the seven things it does,

you just like have a comment, print the winning thing. What I like to do for that is, as I'm trying to understand it, I'll grab like that section and refactor to a function and say print the winner ref grab the other part refactor print print loser or something along those lines right and it actually will start to have the same effect as like replace it with a comment but you end up with running code that is still like understandable and consistent as you kind of like play with it so i'll go through something like big and go okay this section this should be its own little thing with a name hey how about i can make a function that has that name and the ide just a highlight

right click you know control t or whatever um do it and give it the name that you were going to make the comment and that works a little bit better for me because it doesn't destroy the running code in case you're like well but now i need to run it to see what this other part does yeah yeah another thing that you're i was thinking of other tips um when i so i learned to program mostly doing a lot of c code and in there you've got to you've got to have if you're writing helper functions they need to go ahead above the uh the normal the other function, like, because it's not declared, it has to be visible to the function. That's not true with Python.

And so I like to have the reverse. So if I've, like, one of the suggestions is to break out, if you've got a bunch of helper functions and it's confusing you, to put them in another file. I don't actually like to do that, especially if it's only one file using it. I'd rather put them below the function that they're helping. And especially if there's just a couple main functions

that are used in this module that are used externally. But I'd like to put those at the top and then all the helpers at the bottom or something like that. I used to have a coding style to do the reverse and i think it was inherited from c code style but uh python's different um and i i don't necessarily i i guess i i'm not sure what i feel about the uh hiding the function name but i guess maybe don't trust the function name yeah verify um yeah there's

a couple of comments like that david pool says a quote i once read is if the code and comments disagree both are wrong it's kind of similar to the function names as well as given sufficient times the code and the comments maybe function names as well will start to lie which is interesting there what and i also see that people are like more reluctant to change somebody else's comment than they are to change their code and i'm like you got to get over that if the comments are on go feel free to change it that's that's a perfectly fine refactoring so anyway yeah let's move to the next i i totally agree with you about putting the most sort of the organizing, coordinating, high-level stuff first. You know, maybe what would be in the dunder, if name, dunder name equals dunder main,

whatever that is, make that a function and put it at the top. I totally agree that that's the way to go. Yeah. Cool. All right. Next, how about another release? This time, something very small with lots of effort. So this is the one that i was thinking that comes from matt trintini and let me pull it up because that's some good stats in it says after 10 months a

thousand mainline commits and a hundred over 100 contributors we have a new version of micro python so thank you matt for sending that into us that's a pretty big release, 100 contributors. And so the reason I brought that up is the GitHub announcement for the release doesn't point out like how big of a release this was, like almost a year's worth of work. So MicroPython, the one that runs on embedded devices, not phones, but like incredibly small and cheap devices, you know, like five, $10 chips. Yeah. It's awesome. It's awesome that you can run Python there. Right. And so MicroPython and CircuitPython are, you know, similar projects, one fork from the other, I believe, but they've deviated a little bit. CircuitPython being more beginner

educational friendly, MicroPython being more production device, you know, creating devices to do actual jobs type of friendly. But I think they're working a lot together. There's been a lot of merging back. So that's pretty cool. So this release of MicroPython introduces a lightweight package manager called MIP. Instead of pip, you've got MIP.

It uses a custom protocol to query and install packages that's optimized for embedded systems. So that's pretty cool. It's easier to get packages involved. It's like if you've done MicroPython stuff before, it's not as easy as just pip install this thing. It's a little bit trickier than that. Also, the core runtime and built-in types have been compressed

to only including C-level type structs for as much as possible. So that's shrunken the size of it, not by a lot, but it's so small that losing kilobytes actually makes a difference, which is a pretty interesting way to think about it because we don't worry about the size varying by kilobytes in CPython. Right.

Then there's a bunch of small changes like Bluetooth low energy changes, SSL settings. By the way, SSL is way harder over there than you would imagine it would be. There's a bunch of different ports, like the ESP32 is the one that I've worked with. And so for each of the different ports that it goes through, there's sort of a summary of like, how has it changed for that one? And I'd also like to just remind people, like, while this is awesome for embedded devices, you might think, ah, I don't do, you know, small chip programming. So it doesn't

matter to me. You also might be interested in PyScript, right? And so one of the things that they're trying to do is work to get MicroPython to be one of the possible foundations, the runtimes in WebAssembly for PyScript. And when this thing is 100k or 75k, whatever it is, all of a sudden you can run PyScript in the browser nearly on par with JavaScript, right? Traditional PyScript used the full CPython, at least as much as you can get into WebAssembly, which has meant a 10 meg download and then in the browser to parse and start up that whole thing. If that goes to MicroPython, that becomes incredibly fast to download 75k. That's like JavaScript size, right? So all these changes are not just like, I don't think, oh, I don't do this embedded device programming,

so it's not for me. It may well be for all of us soon instead of JavaScript, which is very exciting. So there are many changes. Like, Ryan, see the scroll bar size as I'm going through this list? I am not going to go through them. But if you care, I just want to point out, like, there's a massive new release of MicroPython. You can go and see what's changed for the different ports. And then in the core, right, like, there's just, you know, almost, I don't know how many pages that is, but it's many, many, many pages.

So check out the linked release notes from the MicroPython team. Congrats to them as well, Damian, George, and others. Yeah, this is really cool. I love to see that basically also that the project is continuing and we all benefit from

Python-enabled devices and stuff and people can invent new things better. And yeah, the Internet of Things being in Python is better than having a different language. Absolutely. Also, just want to, you know, sort of a time travel sort of thing as well. I think Matt sent this over quite a while ago and it's been sort of on our list. I finally pulled it off our list and made it a topic. So this is from end of April. It's a couple of months old, but still, you know, almost a year's worth of work is worth celebrating, even if it's a couple of months later.

Yeah. Pretty cool. All right. Ready for the last, our last topic? Yeah. Bring it on. I wanted to just, so I, I'm a, you know you know i get i shouldn't even uh qualify this i am a i was gonna say i'm not a sucker for listicles but i kind of am so um this is an article called advanced python tips for development but when i was reading it so this is by uh sculfield i didn't idahan um and when i was reading it there's 15 tips and some of them don't really seem that advanced. Like the top one use list comprehensions. Okay. You should do that. But there's a few that I

wanted to point out that I thought were that I just wanted reminders of to use it more often. Um, so list comprehensions are awesome. And, uh, and I, I kind of forget that they aren't obvious to people now because I've been using them for so long. So they're great. But one of the things, the next step, so tip one is use list comprehensions. Tip two is leverage generator expressions for memory efficiency. And I don't use generator expressions enough, and I think I should. And one of the cool things about this article is it shows side by side a list comprehension and a generator expression. And they look identical, except for there's brackets versus parentheses.

So parentheses, yeah, parens. And I kind of forget about generator expressions. So generator expressions, are list comprehensions not generators? I thought they were. No, no. Okay. Well, the list comprehension executes it all into memory and then the the generator one you have to start you know iterating through it to

create it which it's cool that they're so similar but i'm sure it's caused unknown untold amounts of yeah challenges for people to go they look the same you can do both it doesn't seem to matter until it really matters you know yeah and and also it's not i mean you can when you get used to list comprehensions general expressions kind of looks like a tuple expression but it's yeah well and then you put curly braces on it and it becomes a set comprehension yeah uh the grant reminded us that don't't forget set comprehensions. Yeah, yeah, yeah. Okay, so let's hop down.

The enumerate function, this is just take advantage of enumerate function. This is just remember to teach people that are coming from C or other, for I equals one to 10 sort of languages that enumerates around. So if you need the index, also use enumerate. Don't be a dork and get the length of a list.

Counter equals one. For I equals one to link the list. Yeah, yeah. Don't do that. Also enumerate can, if you need, if you need it to be a, so enumerate does zero through whatever. If you need it to be one through whatever, you can give it a start. Enumerate takes a starting point. So you can make it start at one if you need it to be one through whatever you can give it a start enumerate kit has takes a starting point so you can make it start at one if you need it right if you're working with indexes the default is good but if you're trying to print thing one thing two thing three then start equals one is the

way to go instead of yeah or if you're using it to like get into some other data structure or something anyway uh i'm gonna hop down to um so that's true. Hop down to five, which is the zip function. And I just, so zip is great for parallel iterating through parallel lists. And you can do more than, this is showing name and age is two different lists and going through them. I, my, my tip is just practice this several times and unfrequently if you're, if you need it, because this is, this was a hard one to pound into my brain as to, to remember how zip works, because it's not that confusing what is it a list of tuples or some sort of iterable i don't know if it's an actual list in the iterable of tuples that you can pull out different parts of it or something and and then you can in this example it says for name last age so that's

unpacking it after you get it and it works great i just always forget to use it so a good reminder um and then i'm now i'm going to jump down to my 12. One of the things, 12, but 8 is kind of funny because it's a formatting problem. But anyway, use counters. Counters are good. 12 is, what is 12? Oh, one of the things, 11 is decorate, use decorate, decorate functions with static method and class method. I just hardly ever do this.

Do you use static method or class method that much, Michael? Yeah, quite a bit, actually. Oh, really? Okay. Yeah. And I guess one of the neat things, anyway, I just don't use it much. Maybe I'll try to explore where I can use it more often. The number 12 is use slots to reduce memory usage.

And I kind of forget to do this too. So this is a good reminder to use slots when you're... And this is great, especially if you know ahead of time what your classes aren't going to add new data as it goes on. It's not going to be dynamically generating new fields. And I guess here, I just use the adders. So anyway. It's worth pointing out that slots don't just reduce memory.

They also make attribute access faster. So like thing.field, getting and setting that value is also faster with slots. OK, yeah, that is. Yeah, it's good to remember. Anyway, some some fun tips. 14 use by test. It says use unit test or by test. Ignore the first part. Use by test. And there's a typo there. Is that what you're saying?

There's a there's some typos. So use unit test or take out the unit test or. And also it says for unit testing, just automated testing, just for all your automated testing, not just unit test. Yeah. Well, those are our topics. Do you want to talk about some extras, Michael? I do have some. So I feel like, Brian, it's not time for a joke yet, but there's a pretty good joke on that page

we might have to come back to. Well, do you want to explore it now? Oh, not yet. Not yet. We can do it later. Okay. Let's do it later. All right.

So, you know, people have different faces, Brian. You know, sometimes you got your sort of like neutral face. You got your happy face, your sad face. How about your hugging face? What's your hugging face look like? So there's this project created by Agustin. Let me pull it up here. The source code's linked at the bottom by Agustin Pekiris or Agus, as his friends call him. Sent in, hey, I was looking to play with the

hugging face API. And so I'm like, well, what could I work with? What if I turn a large language model or semantic search loose on TalkPython to me and their transcripts? That's cool, huh? Yeah. So he created this project. You got to go and get a free Hugging Face API token because it uses Hugging Face. I was joking around. But then it says you can ask a question. For example, what's my advanced options? Oh, yeah. I can see how many things I could get back. Let's make that 10. Focus, focus, come on. So you can go to things and say, who uses MicroPython in production, for example. All right, I can type that into the search field and then I can say submit. And sometimes it takes a second, sometimes it's pretty quick,

but we're going to see what we get. That's a little running character. Although they can't choose their sport. It's like rowing and then swimming and then it's running and then it's biking. That's what the like on. It's like a decathlon. I guess you're right. And so here comes the answer back. It says over on TalkPython, you should check out PyScript powered by MicroPython and MicroPython plus CircuitPython. You might be thinking, well, it's just searching titles, but then empowering developers by embedding Python by Nina Zakarenko. And then there's a weird one by Brian called 30 Amazing Python Projects and so on.

Or even the Year in Review. Isn't that cool? That is neat. So if you want to play with this stuff, either because you want to build a thing like this for something else, or you want to just go ask questions about DocPython, you can go and check out this app. The source code is linked at the bottom.

MARK MANDELAIDISI- I guess another comment that maybe it's a good idea to have transcripts for people to be able to use is search. MARK MIRCHANDANI- Exactly. We didn't have transcripts. We weren't able to do this cool project, right? So yeah, excellent. So that's one.

And yeah, that's it for me for my extras. You got any? Yeah, one, I just wanted to, I guess, remind people that Python People is a thing. Python People is a new podcast and episode three is out with Brett Cannon. And one of the comments, one of the quotes from him is,

I came for the language, but I stayed for the community. We explore that and what was the situation when he talked about that. One of the quotes from him is, I came for the language, but I stayed for the community. We explore that and what was the situation when he talked about that. And we talked about a whole bunch of stuff, like what is the meaning of backbaking and toque, things like that. So check it out. Oh, nice. I had forgotten to, for people listening, I had forgotten to actually show the episode on the screen. I could go back and search TalkPython again for this and see if we find Python people. You would find a ton of Brett Cannon over there, and we have an episode for him coming up very soon.

Yeah. But no, I'll switch it There's a. Oh, that's the wrong thing. Oh, I deleted the thing I wanted to talk about. So I guess that's it from extras for me. It's gone from the Internet. It is gone. So I have a joke for us. OK, well, let's before we do the joke, we didn't do any sponsors. One of the sponsors, of course, is Python people or it's us.

But I'd like people to check it out. We have like maybe three listeners so far. No, it's bigger than that, but I'd like it to grow. I also want to give a shout out to everybody on Patreon. So if you go to any of Python Bytes pages, especially ones without any advertising like today's or episode 343, you can see become a Patreon and you can click on it and become a member and help support the show for a buck. That's great. I also wanted to give a shout out to all of the amazing courses at TalkPython Training. Michael has done a great job, plus pulling in amazing other people to teach courses like me at TalkPython Training.

There's some great stuff, so check it out. Now we can do a joke. Yeah, I've got some new courses coming from some really awesome people. All right, on to the joke. On to the joke. So this one is a meme somebody put together. I have two jokes here,

then we can even do the third joke that you had on screen a little bit ago. So HTMX, if you all are familiar with HTMX, if you're not, you should definitely check out our HTMX and Flask course. This thing is so awesome. I had so much fun learning it. And I'm like, where's the next project I can use HTMX on? Because it's great. The idea with HTMX is instead of doing JavaScript, you just write attributes. And then that magically through HTMX gets turned into server calls. Like if I need to rebuild a table as somebody interacts with some other part of the page that could just be done on the server and just send little fragments back. It's incredible, right? So it means you don't have to write JavaScript. So the joke is,

there's a guy that's back in dev and then this other dude, that's HTMX's. HTMX says, look at me. Look at me back in dev. You're full stack now. You're full stack. Stand up for yourself, man. Don't let those, don't feel like you can only write it back in code. You're full stack now, HTMX.

Isn't that good? Yeah. The other joke, before we get to the one that you had on the page, is what is happening to Twitter? What, like, how did a child try to rebrand this? we get to the one that you had on the page is what what is happening to twitter what like how did a child try to rebrand this it is so incredibly bad no it's like branded by a high school band it's so bad let's let's call ourselves x that'd be so cool man yeah man and so like for example people might be thinking i go you're overre They, they tried to take the Twitter logo down and replace it with an X. And then the police came and stopped them because they didn't have the Twitter employees doing it. Didn't have a permit to drive a crane around downtown San Francisco. So it's like half the Twitter logo is like half removed. There's no X, nor is there Twitter. It says tweet.

I'm on twitter.com, but there's an X. But, you know, sometimes, like, what do you call these? Are there supposed to be Xs? You know, usually Xs is kind of a bad, I mean, it's just like. And if you share another one, is it a re-X? Yes, exactly. And there's some random person who has X as a handle on Twitter. And they're like, what's going on? Am I going to be like Twitter? I heard that they don't know for sure on this one,

but they don't seem to have the intellectual property rights to trademark the letter X. Well, you can't. I know. property rights to like trademark the letter x well you can't and i know and this x looks like um i think the x11 logo if you go look at that uh i think that was the one it's like it's like a thick right slanty versus a a thin left slanty which is um you know one's hollow one's solid other than that they're kind of... Anyway, there's... That's sort of a meta joke. On the good side, current employees and those that are laid off are all ex-employees now.

Exactly. Look at all the people that work for Twitter now. They're all ex-employees. All right. So that was just because this came from Twitter, I'm going to open up like, wow, this is getting janky. It's X news, so it has to be part of our extras. It absolutely does.

All right. Do you want to just give a quick shout out to what was on that page before? So what were you referring to? The only valid measurement of code quality. Oh, yeah. WTFs per minute. Okay. Yeah.

WTFs per minute. It's true. Oh, that's the. Yeah. You need the full one. Oh, wow. You lost it now. It was true. Oh, that's the... Yeah. You need the full one. Oh, wow. You lost it now. It was an ad.

It was an ad. Yeah, okay. It was a code review, and behind the door, you could just hear WTF. What WTF? And the good code only had a couple. The bad code was just, like, overwhelmed with them. That was the joke. Yeah.

All right. Well, this episode was no joke. It was a lot of fun. Thanks, Brian. Thank you. And thanks, everybody, for showing up at a weird time. I really appreciate it. It's great. So yeah. See you later. Bye.