 Okay, hello everyone. This is the CircuitPython Weekly Meeting for June 6th. This is the time of the week where we get together to go over and talk about all things CircuitPython. My name is Tim, and I am sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python that's designed to run on tiny computers called microcontrollers. The CircuitPython development is primarily sponsored by Adafruit, so if you want to support them and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join at any time by going to adafru.it-slash-discord. We hold the meeting in the CircuitPython Dev Text Channel, as well as the CircuitPython Voice Channel. This meeting typically occurs on Mondays at 2 p.m. Eastern Time, 11 a.m. Pacific Time, except when that coincides with the U.S. holiday. In the Note Stock, there is a link to a calendar that you can view online or your favorite calendar app. We'll also send notifications about the upcoming meetings via Discord, so if you'd like to receive those notifications, then you can ask to be added to that CircuitPythonista's Discord role. There is a notes document to accompany the meeting. The notes document contains time stamps to go along with the video, so you can use the document to view only the parts of the video that interest you most. The meeting tends to run 60 to 90 minutes, so this gives you an option to skip around if you're watching after the fact on YouTube. After each meeting, we post a link to the next meeting's notes document to the CircuitPythonDev channel on the Adafruit Discord. Check the PIN messages to always find the latest notes document so you can add your notes for the following meeting, and you can find that throughout the week as well, so feel free to fill in your notes even before Mondays if you would like. If you wish to participate but cannot attend, you can leave hug reports or status updates in the document and we will read them during the meeting once we get to you in the list. This meeting will be held in five parts. The first part is going to be community news. This is a look at all things CircuitPython and Python on hardware in the community. It's a preview of the Python on microcontrollers newsletters, which comes out on Tuesdays. The second part will be the state of CircuitPython, the libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we are all individually working on. The third part is hug reports. Hug reports is an opportunity to highlight the good things that folks are working on in the community. It takes some time to recognize the awesome folks in our community. The fourth part is status updates. This is an opportunity to sync up on what we've been working on, so you can write out a few things into the note stock. You can mention what you have worked on since the previous meeting and what you plan to work on since the next meeting. This is also a good place for folks to give tips and tricks if you happen to know about something that somebody is working on. But if the discussions do start getting too long, then we can always move things to the fifth and final part, which is in the weeds. In the weeds is an opportunity for long form discussions. These can come out of status updates or they can be identified ahead of time as too long for status updates. That covers how the meeting will go. So next up, to get us kicked off, we will start with community news. I'll take a timestamp here. And the first item in community news this week is the latest Python developers survey results have been published. The Python Software Foundation announced the results of their fifth official annual Python Developers Survey. The work is done each year as a collaborative effort between the Python Software Foundation and JetBrains. Late last year, more than 23,000 Python Developers and enthusiasts from almost 200 countries and regions participated in the survey revealed the current state of the language and the ecosystem around it. So there is a link here to PyFound blog where you can read more about the survey results. Let's see. Next up here, we have Python 3.11 is up to 10 to 60% faster than Python 3.10. So Python 3.11.0 has reached beta one status and it's close to release. It is up to 10 to 60% faster than Python 3.10, the previous version. On average, developers measured a 1.25 speed up increase on the standard benchmark suite. How's this being done? Python 3.11 is the first release to benefit from a project called Faster C Python, where C Python is the standard version of the Python interpreter. Faster C Python is a project funded by Microsoft whose members include Python inventor Guido Van Rossum. And there is a link here to analytics insight to learn more about those speed ups coming in Python 3.11. Next up here, we have Life as a Python software foundation director. So this is a YouTube video and it's a window into what it takes to lead the foundation responsible for guiding Python. So check out this video on YouTube with some of the current and former, I believe, Python software foundation directors. Next up, Google's plan to make chip development more like open source software. The Google hardware tool chains team is launching a new developer portal, developers.google.com to help the developer community get started with its open MPW Shuttle program. This will allow anyone to submit open source integrated circuit designs to get manufactured at no cost and there are links here to a Google blog as well as Slashdot. If you want to learn more about that, Lord knows we could always use more open source designs for just about anything. So that was pretty exciting to see. Next up, we have a Make Zine board review. This is a board review of the Adafruit Feather RP2040. If you're interested in Make Zines take on that board and learning all things about it. You can go and read that post over in Make Zine. And then the last one I have here is a project highlight for the week and this is a macro pad mod. This project is a little 3D printed stand with a macro pad. It looks like they modified the display to be set up at an angle. So it kind of faces back towards you instead of flat. They also added a couple of extra rotary encoders as well as a 14 segment display up above the macro pad there. So it's all in a 3D printed case made out of TPU and it runs Circuit Python. And the link here is to Reddit's mechanical keyboards subreddit. So I thought that was a super neat project that featured Circuit Python that will be in the newsletter this week. And speaking of the newsletter this week, the Circuit Python Weekly newsletter is a Circuit Python community run newsletter that's emailed every Tuesday. The complete archives are available at AdafruitDaily.com. There is a link in the notes if you want to follow that. It highlights the latest Python on hardware related news from around the web, including Circuit Python, Python and MicroPython developments. To contribute your own news or projects, edit next week's draft on GitHub. There is a link for that in the note stock as well. You can submit a pull request with the changes. You can also tag a tweet with hashtag CircuitPython on Twitter or email to cpnews at Adafruit.com. Let's see. So that gets us to the end of the newsletter update for the week. So let's do a timestamp here. And next up we will look at the state of Circuit Python, the libraries and Blinka. So first up we'll take a look overall and I'll read this section. So overall across the whole project we had 35 pull requests merged from 18 authors, a couple of names that I don't recognize here. So these folks may be newer at least to the project. And actually I noticed I missed one here, but Sim Allaire is the first one. Lisa Apple or Liz Apple, Nathan Y3G, DJ Air Junior, I think this is, Bab Lock B, AJS 256 and Simon Vale. Those were a couple of users again that I didn't recognize as being regular contributors. And that was across all of the Circuit Python libraries and other related projects. So thanks to all of those folks as well as all of our other more regular contributors. We also had six reviewers this week. So thank you as always to all of our reviewers. And we had 21 issues closed by 11 people and 13 issues opened by nine people. So we're net down about eight issues it looks like this week across everything. So that's great to see, moving in the right direction. And that is it for overall. So I will take a timestamp and send it over to Scott. Do you want to tell us about this core? Sure. I managed to get undistracted from the Apple announcements. So for the stats for the core, 11 pull requests merged from 12 different authors. So thank you to all of our authors. I won't highlight the new folks since Tim had just did that. We also had three reviewers, Lady Adana, myself. We have 15 open pull requests. Again, we do have like this long tail of pull requests that are getting a bit old. So if you're involved at any of these, please take a look and just see where they're at. I'll try to do that today as well. We've got three that are over 100 days old and then a few that are kind of in the 30 to 90 days old range as well. Issues wise, we had six closed issues by five people and four open by four people. So we're net down as well, which is good for a total of 512 open issues. We generally gauge how urgent issues are by the milestone that we've assigned to them. And this impacts the prioritization of those of us who work on circuit Python. 480 fruit. We have two open issues on 73x. We have 43 on 8.0. I think we intend on triaging the 8.0 ones as well, but we haven't done that yet. Again, we have negative two issues not assigned to milestones. I'm not exactly sure why that is, but we'll take a look and not assigned to milestone is a great way for us to know what we have to triage when we go forward. So that's it for the core. All right. Thanks, Scott. Next up, we will pass it over to Katnit. Do you want to tell us about the libraries this week? Sure. So this section applies to all of the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore circuit Python underscore, as well as a few extras such as the community bundle and our cookie cutter across all of those repositories. We had 16 pull requests merged from six different authors and five different reviewers to one of those was a month old, which is good to see that we're still picking up some older PRs. And the rest were 12 days or more recent. So we're still keeping up with new ones as well. That leaves us with 22 open pull requests. We had 11 issues closed by eight people and nine opened by six people, leaving us with 640 open issues. 185 of those are good first issues. If you're interested in contributing to Circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more, including the open pull requests and open issues. If you're interested in reviewing, look at the open pull requests, take a look, leave a comment, let us know what you saw if you have the hardware test it. All of that is super helpful. And once you're comfortable with that, we can talk about leveling you up to our review team. If you're interested in contributing to code or documentation, check out the open issues. If you're new to everything, good first issue is a great place to start. We also have a guide on contributing to Git and GitHub. I'm sorry, contributing to Circuit Python using Git and GitHub. And we're always available on Discord to help out. If you're looking for something a little more complicated, check out bug or enhancement. But you can search for that open issues page and see if anything strikes you fancy and leave a comment that you're working on it. And again, we are always available to help. In terms of library updates in the last seven days, there were no new libraries, but there is a list of updated libraries in the note stock that I will not read off, but you are welcome to check out if you're interested. And that's what I've got. All right. Thanks, Kenny. Next up, we will send it over to Mako Melissa to tell us about Blinka for the week. Hello, Blinka is our Circuit Python compatibility layer for MicroPython, Raspberry Pi, and other single board computers. And this week, we had eight pull requests merged by four authors and four reviewers. There are currently four open pull requests amongst all the different repositories. And there were four closed issues by one person, zero open by zero people leaving a net of 75 open issues. There were 8,788 PiWheels downloads in the last month, and we are now up to 89 boards. And that's it. Awesome. Thank you, Melissa. So that concludes the state of Circuit Python, the libraries in Blinka. Next up, we will go to the first of our two round robin sections, the hug reports. So hug reports is a chance to highlight folks in the Circuit Python community and beyond for doing awesome things. As mentioned, this section is held as a round robin where I will start and then we'll go down the list alphabetically, giving everyone a chance to participate. If you're text only or missing the meeting, but have hug reports in the notes document, then I'll read them off as we get to you in the list. So my hug reports for this week. Thank you to Scott for reviewing my PR for tile grid contains inside the core, as well as sharing some ideas around group interactivity as well, sort of tangentially related to the tile grid stuff. Thank you to C Grover for testing out many devices with a custom build of Circuit Python that changed the brightness PWM frequency in the built-in display in leaving notes and detailed info and diagrams and things about how each one of them behaved. Definitely appreciate C Grover's work on that. Thank you to Makar Melissa for reviewing some of my recent PRs across a couple of different libraries and other utilities and then a group hug for everybody. And then next up we have C Grover. Let's see, you text only C Grover? Yeah, I think so. If you are here and want to read your status updates, let me know and then I'll call you back up if you have status updates. But C Grover has a group hug this week for everybody. Yeah, text only. Okay, perfect. And then next up we will send it over to Dan. Okay, thanks. Okay, thanks to Scott who redid how translations were compiled and saved a whole bunch of space on the ESP32 boards and that was great. Thanks to D Sarabian who's helping me debug an ESP32 SPI problem. They have a sample program that clearly causes a problem and I've been using that as a test case and we've been iterating that. It's been really helpful. And thanks to you for me guy for a big PR to add a PWM frequency argument to display initialization which required changing a lot of calls. Thanks a lot. Okay. For sure. Thanks Dan. Next up is G3 holiday who's lurking. So I'll read theirs. They have a group hug and a hug for Scott for tile grid work. So again, that was G3 holiday. And next up is catney. Thanks, Tim. So first up I have a hug report for Mark gambler for helping me out over the weekend with trying to get some code going on a personal project to Jerry for writing the code and helping me along the way with hardware and so on to Dan for jumping into the project thread to attempt to help me with code issue that involved pin alarm and deep sleep and to Tectric for helping me with figuring out a simple micro python thing that I was struggling to find an example of and a group hug. Right. Thanks, catney. Next up is maker Melissa. Hello, I wanted to give a hug to similar for adding a new board to Blinka to get a user 10 new at for fixing this by port setting for the Raspberry Pi on Blinka and a group product everyone else. All right. Thanks, Melissa. Next up is Mark gambler who is lurking. Let's get a timestamp in. There we go. And then I'll read them. So Mark gambler has hug reports for Tanute Scott and anecdote for PR reviews this week. So thanks again from Mark gambler there. Next up is Tammy makes things. Whoops. I'm stamping the wrong spot. Here we go. All right. There we go. Now, Tammy makes things if you want to go. Sure. Hi, everybody. I just have a group hug for the whole community for being awesome. All right. Thanks, Tammy. Next up is Scott. Hello. Just a quick hug report for you, Tim, for keeping the deep dies going. I was able to watch part of it on Friday and it was nice to kind of hang out. So thanks for keeping this going. Awesome. Yeah, for sure. My pleasure, definitely. Next up is Tectric who is text only. So I will read theirs. Tectric says a hug report for near a doc for help understanding a cookie cutter issue and then a group hug. So thank you, Tectric, for entering those hug reports in for the week. And that is the end of hug reports. So next up, we will go to status updates. Let's get a timestamp. Status updates is our time to sync up on what we're doing. The section is also held as a round robin where I will start and then we'll go through the list alphabetically, giving everyone a chance to participate. When I call on you, go ahead and take a couple of minutes to talk about what you've been doing since the last meeting and what you plan on doing up until the next meeting. This is also an opportunity to provide those tips and tricks relevant to what people are working on. If a discussion does become too long for status updates, then we can always move it to in the weeds down towards the end of the meeting. So I will start with status updates. Let's get a timestamp. So this was a bit of a light week for me. I did take Monday, the holiday off last week, so I definitely did less this week, but I'm getting back into things now today. But over the last week, a couple of things that I did do were update devices in the core. All the devices with a built-in display updated them, all the initializations to use a new constructor argument for the PWM frequency, and so that got added internally in all those board definitions, and that new argument is helpful for in particular the Pipe Portal Titanic because it had a slightly different driver chip or something for the display, and so it's PWM needed to work differently in order to have full range of brightness. So we added that argument and then updated all the boards to use it. I did also make a couple of tweaks to circuitpython.org, which is always fun to get back into developing kind of a different type of thing. It's not really Python, but more HTML and JavaScript templating type project, so it was fun to play around in that world a bit. I added a new note to the Pico system, Pimeroni Pico system device, to say how to get to the boot loader, and then I also made it so the downloads page will automatically autofocus the search box. So if you click over to the downloads page, you can then just start typing, and it will be narrowing the boards down for you, which is a nice usability improvement, I think. A couple of things I have planned to work on this week. Trying out the, well, actually no, this was still, I did work on this over the weekend on a stream. So playing around with the tile grid contains function, that's a PR that I have in the core, and in order to test it out, I created a slide puzzle application. So like old school little kids toy, you know, four by four slide puzzle type thing. We made one of those using tile grid, and then for this week, the thing I have planned so far is making a easy, very, very basic simple text scroller for the matrix portal. There's a couple of different projects out there that scroll various things. But I wanted one that uses no network, no additional setup, minimal libraries, and just reads the text from a text file and scrolls it. That way it's like, dead simple for anyone and everyone to set up, even if they have basically no, you know, programming or computer proficiency really beyond just opening the text file. So that's one thing I'll be working on this week. Next up for status updates is C Grover, who is text only. So I'll read them. And then Dan, you'll be after C Grover here. So C Grover's updates. This week submitted a PR to add a global neopixel brightness getter and setter to the neo trellis slash multi trellis library. This PR was approved yesterday and is waiting for an independent test. Next up, C Grover still working on the display IO based brightness algorithm for the matrix portal and other RGB matrix displays. The prototype code is working nicely but needs to have the controlled display IO objects and palettes defined in advance. The continuing challenge is to figure out how to make the algorithm autonomously discover and control all display IO objects. And then last entry from C Grover this week says display brightness is my life now. All right. So next up, we will send it over to Dan. Okay, thanks, Tim. So first I, we have a number of minor circuit Python eight changes to the API of for circuit Python native modules for circuit Python eight. One of them is to move one wire out of bus IO to one wire IO. We did it. We moved it into one wire row and left it in bus IO for seven. And now we're moving it out. So that required circuit Python changes, Blinka changes, and one minor library change. So that's done. I reviewed Scott's build space in PR, which I mentioned earlier to keep an eye on making sure that it didn't, it was still not using up too much build time when we ran a continuous integration run. And that worked out well. And we have, it's got the same word about that. I added and tested a board definition for the latest feather ESP 32S3. This is the one with four megabyte flash and two megabyte PS RAM that's available in absolute newest in the S three buckets. And we will, it will be in the next in the first alpha release for eight. Oh, I'm debugging problems with ESP 32 SPI. I've been working with someone, as I mentioned, to come up with a reproducible test case for problems that occur when you use display IO specifically on the makefix portal with ESP 32 SPI. And now I have a test case now to debug it. And I'll probably go ahead and make an 801 alpha one release soon since we have some new boards and other things. And we may as well have a placeholder alpha one. And it makes it easier to do the next release after that because there's not such a backlog. Okay. All right, sounds good. Thanks, Dan. Next up, Katny, you have going on this week. Thanks, Tim. This, let's see, last week, I did the final testing on pylip and green lit it for release. So we've been doing a ton of testing over the past. Geez, month and a half, two months now to get from 1.0 to 2.0 and 2.0 is now live. I took a series of videos and converted them to gifts of double tapping reset to get into the bootloader on different boards. This is for the whipper snapper application. I think it's for documentation for it. Apparently, one of the biggest support issues with things like this is folks not understanding the rhythm of getting into the bootloader. So instead of just trying to explain it in words, they wanted to actually include gifts for each board. So I got a bunch of those and continued on the QT pie ESP 32 Pico guide. So this week, I'm going to finish that guide now that I have hardware. I have MicroPython NeoPixel blank going. So that's a start. That one took some iteration to get it working. And then next up, I'm going to be doing a GitHub fancy profile guide. I got a little more clarity on what the idea is for that. Basically, if you wanted to join an open source community or introduce yourself in the process of joining an open source community, what would you want to show about yourself on GitHub? GitHub has a thing where you can make a repository that is just your name, your user ID, and you can add a read me to it. And then you can use Markdown in many, many ways to create a profile. So the plan is to update my own profile and go through the process, explain a bit about Markdown, talk about what types of things make sense to include. Obviously, that's different for everybody. But I will be doing this guide from my point of view. So I will go through the things that I would want to add. There was a repository that's full of tools to improve your GitHub profile. And so initially, it was a little overwhelming and very unclear what the guide was supposed to be. But I talked to Phil about it today and it's much clearer. And then following that, I will be doing a guide with a tower light that is a GitHub actions data slight. Using the GitHub API and obviously desktop Python because it is a tower light plugs into your computer via USB and then talks over serial. There's no microcontrollers involved. And that is what's on my list for this week. And then over this past weekend, I worked on the mailbox project. Finally, I still need to get the Raspberry Pi set up, which I do so rarely. It's always a huge pain when I need to do it. Everything is soldered and assembled, but there's something up with the code. It's not working properly. I need to do a bit of more testing with some guidance, but it might be a bug. And with a pin alarm in deep sleep. And then I managed to solder a chunky LED onto the PyLaura bonnet with some creative use of mounting holes and unconventional wiring. I have no idea yet if it works, but it looks really nice from the top. If it does work, I will use this bonnet in the final project instead of trying to do it again, because I don't know if I can replicate it. That's what I got going on. All right. Thanks, Kenny. Next up, let's get a timestamp here and maker Melissa. Hello. So last week, I added some issue tags to the circuitpython.org open issues under contributing. I fixed various e-ink issues and added some new features. I added, or I updated the PyTFT installer script with some options to allow it to work in Ubuntu better, like being able to pass in your boot folder, which is a little different than on the Raspberry Pi OS. I went through guide feedback for programming in Arduino using Raspberry Pi GPIO guide. I started with, I started looking into getting the TSC touchscreen breakout to work with the kernel drivers, and I also organized and closed a bunch of Blinka issues. This week, I'm going to continue looking at the touchscreen stuff and possibly look at some of the HT16K33 library issues. And that's it. All right. Thanks, Melissa. Next up is Tammy makes things. Thanks. So last week, I finally am starting to dig out of the backlog with my new job and promotion. So I have a little bit more breathing room to work on other stuff. I did one Twitch stream this past Sunday working on the display. I owe part of my card deck library and demonstrating in real time that I cannot do geometry without drawing things out on graph paper. But that's okay. I tried to do a second stream earlier in the week, but was foiled by repeated Cox internet outages in my neighborhood. There's been six of them in the last two weeks, and it's driving me bananas. So hopefully that stops. And this week, I'm hopefully getting back to a more regular streaming schedule still working on the display. I owe card deck library and I'm building some debugging helpers for um, sprite sheets and tile grids because I keep getting the X and Y coordinates and some other things reversed in my head when I'm figuring them out. And so I'm trying to build some debugging helpers to help me keep them straight. And I will probably share those at least in a GitHub gist or something for other people. And I'm hoping to do some PR reviews and maybe some more type and annotation stuff this week if I get some time. So that's what I got. Thanks. That sounds awesome. Thanks, Tammy. Next up, we have Scott. Hello. So, um, not a ton because this translation stuff, uh, took some time. So, for those of you who know that I've been working on, uh, code size optimization for translations on non-LTO builds, um, basically with LTO, we're able to remove a bunch of source strings and remove a bunch of code to decide which translation return. But when we were doing traditional compiles like we do on Espressif, we were actually storing all the code in all of the original strings. So it's all, it's like 30 or 40k. Um, there's a trick where we play, where we can now inline it and let the each individual call site be optimized away. Um, that had some build time issues that Dan pointed out. Thanks again to Dan for looking at that. Um, and I realized what I could do is I could split the, the translation data out of that giant code block that gets optimized away so that we only optimize it the once and then link to different, uh, translations at, at the end. So that was good, and that gets, gets us pretty comparable build times and, but we still save the space. Um, so that was just merged in today. Thanks for Dan. That was a lot of like running down build problems. Um, and changed some LTO stuff as well. LTO make file stuff there as well. Um, so I'm now back to working on the wifi auto join stuff. Um, and I think the kind of first iteration of the status bar on the serial terminal will also be part of this work. Um, and then I'm going to talk with Brent, uh, about their approach with whippers snapper as well. Cause you still have this problem of like the very first time you get a device, how do you get it on, uh, your network? So that is something I think Brent and the whippers snapper folks have thought a lot about. And so, uh, I think we're hoping to replicate that. Um, the other thing is they've done some status LED work. So maybe we'll kind of bridge that and be able to do status LED work or in the same way that they do. Although I have a feeling they took what we did in circuit by thumb for code.py execution and now use it for wifi. So, uh, going to talk with Brent later about that. Um, but it should be pretty neat. And it's a first another step towards web workflow stuff. Um, hopefully you can't hear the baby too bad. And then, um, just a note for what I was doing in my personal time, I've gotten a little bit interested in redistricting Seattle city council districts. And I made a quick site over the weekend that is a way for you to, uh, draw on a map and just share a link to people and they can see what you drew on the map. So map note dot dev, just a single indexed HTML. But they were having this problem where like people who are giving feedback to the redistricting folks can't just say like, this is the area that I care about. So I put this together, uh, over the weekend as a, hopefully a tool that they'll be able to do of just sharing, uh, polygons and stuff. So that's it for me. I'm excited to do, uh, get back to the web workflow stuff. Um, yeah, shipping me. Nice. Got lots of interesting stuff going on, as always. Thanks, Scott. Next up and last for our status updates is tech trick, uh, who's text only. So I'll read his last week tech trick, um, last week, uh, worked on finalizing, uh, getting the Adafruit logging 4.0.0 deployed, uh, flagged libraries with potential problems due to the logging module upgrade spent time, uh, with my girlfriend and her parents. So a light week. And then this week for tech trick, uh, working on address library and learn, uh, let's see, I think probably working to address library and learn example repo changes resulting from the new logging, uh, update, um, applying manual patches for the pilot, I see, uh, upgrade from a few weeks ago. And, uh, lastly, tech trick says some more, uh, debugging on the blue fruit connect image transfer feature addition. So that's the ability to send images. Um, I don't know if it's to or from, but, uh, like between a smartphone and a, uh, blue fruit capable device like circuit playground, blue fruit. Um, all right. And that wraps us up for status updates. So I will take a timestamp and then talk about in the weeds. So, uh, the final section of our meeting here is, uh, the in the weeds section. This is an opportunity for more long form discussion that either comes out of status updates or that folks have identified ahead of time. Um, if you have an in the weeds topic, uh, please make sure to add it down at the bottom of our note stock. Uh, we have one in here now. So we'll get into that. But if you know of another one that you want to discuss, uh, please do go ahead and add it there. That way we can just move on when the time is ready. Um, so this week we have, uh, in the weeds from tech trick, uh, tech trick, you were text only. Uh, so I will read this out. Um, unless you let me know otherwise. Um, let me get here. Okay. So, uh, tech trick says in the weeds, um, go for it. Okay. Yep. Um, Adafruit logging. So this is the library Adafruit logging library. Um, this library has recently, uh, become a strict subset of the CPython logging module. Um, the differences between the two have been hidden under the hood. One such difference is that a handler takes a message and log levels directly instead of a log record object. Um, so if I understand correctly, it's been a few days since I've looked into this. So I may be, um, I may have it backwards or incorrect, but from, from my record election, I think the CPython one, uh, takes a log record, but our circuit Python one takes, um, the message and the log level instead of that object, that log record object. Um, so those, uh, methods have been made private in the circuit Python one. Um, that way we won't have, um, you know, functions that have different signatures. Um, one learn guide example and potential use case is that, uh, people are wanting to create their own handlers, uh, for the loggers and they need to define those methods. Um, and there's a link here, which I will copy and drop into the chat here. Um, so I think the high level idea, which I'll read the rest of this here, but if I understand it's basically weighing the, um, subset of CPython against the, uh, functionality of us being able to make the custom handlers. Um, so Tectric also added here, uh, pros of the current, uh, way that it's done. There's not a lot of overhead, uh, for what the typical use case would be, uh, logging to sys.stdr or possibly an external file. So it's lightweight and simple to understand. Um, cons of the way that it's currently done is we can't easily define custom handlers. Um, and those handlers methods, uh, would take different arguments than their CPython equivalents. Um, if we did want those to be equalized, then we would need to implement, uh, log record. Um, but we could use a more inexpensive solution like named tuple, uh, instead of, I guess, creating the full log record, um, object if I'm understanding that. Um, so the kind of, the root of the question is, is it worth exposing methods of handler to allow for customization? So is it worth exposing those methods, um, even though they would then differ from the CPython module, or do we want to not expose them, uh, at the cost of making it more difficult to customize? Like, specifically to create a custom handler. So if you wanted to create a handler that, you know, I don't know, sent to your logs across the network or something different that's not happening in any of the existing ones. Um, I think that's my understanding of it. I would say I don't have a lot of experience with the logging library or loggers in general. I think I would probably lean towards, um, the same thing which we generally lean towards is trying to make it match the CPython one. So I think I would lean towards the subset at the cost of it being a little bit more difficult to customize. Um, but again, I don't have a lot of experience, so I also may not be the best judge of, of that trade-off, truthfully. Um, anybody else have thoughts or ideas on this issue? I kind of, I kind of agree with you. I mean, I've, I've been doing Python a long time and I still don't use the logging library. Yeah, Prince, Prince would be helpful if you ever found a, to level up all the way. Yeah, I've just not, like I think in the server world where you're dealing with like lots of libraries and stuff, it makes sense, but uh, like we had something similar when I was at Google, but I do a lot of smaller Python stuff. I think that I think it's fine to just have the subset of the API and then the private versions of those things that should take log records, but don't, like Python doesn't care if they're private, right? Like, and then there's non-standard names. And so if you really need to reach into the, the object, you're kind of accepting the risk. Um, so yeah, I would say the public API should be the same C Python. I mean, this is a little weird that we have a guide about it. Um, maybe because we have a guide, we should do it the proper way. I also think that it's probably not, it's probably not the, the end of the world to do a log record object. Like the strings and object anyway, log records probably pretty small. Like if you needed to do log record, you'd be okay too. Okay. Um, like logging is not fast either way. I don't think it's really a performance problem. And maker Melissa points out in the chat there, it could be done like many MQTT library and it's done with callbacks, I guess in that library. I'm not super familiar with it either, either. But that's maybe something to consider as well. I think Melissa probably has more experience than URI in terms of logging with regular Python. Okay. I think you under the under cans, you understand the constraints. So you've got it. All right. Tectric, does that kind of give you a point in the right direction? I think we lean towards the, um, so keep it as is. And if people want to customize, then they can dig into the code and figure out, uh, yeah, that is my, that is my understanding as well. Tectric, yep. Well, if you have to, if you have to update the custom logger guide to, it should probably match C Python. Like if we have a learn guide for it, you should probably not use a private API. Oh, in the learn private API in the learn guide, I got you. Yeah. Yeah. What all is in the learn guide? Okay. Yeah, I, I just saw the example code. I didn't look at what the text around it was, but so then log record, it sounds like is probably best to Yeah. to keep that learn guide code matching a CPython if we can. Right. But if we have higher level functions that, that use those internal versions that don't create the object, then just that. I don't know. I've looked at it enough, but generally, I think we should, we should consider APIs that are in learn guides as public APIs that we want to do properly. And because we're going to support it, and there's going to be a lot of example code for it. Okay. So if it's something that it's in a learn guide, we should probably not teach them to do it through the sneaky way. Let's see the learn guide might, might not. Yeah. And then it will be CPython compatible, which will be. Yeah. Don't worry about the object creation. It's all logging slow. Might have to change a bit if I can. Yeah. And so tech trick when it does come time to, if there are changes to make in the learn guide, when it does come time to do that, I can help you out with that as well. Access to update stuff and learn. So if you need somebody to help change a page, I can, I can help you with that when the time comes as well. And that is our only topic for in the weeds this week. So let's wrap it up. Let me I'm stamping there for the wrap up. So this has been the circuit Python weekly meeting again for June 6 2022 is today's date. Thank you everyone who participated. If you want to support Adafruit and circuit Python, as well as those of us that work on circuit Python, consider purchasing hardware from the Adafruit shop at Adafruit.com. The video of this meeting will be released on YouTube at YouTube.com slash Adafruit and the podcast will be made available on major podcast services. It will also be featured in the Python for microcontrollers newsletter, which comes out tomorrow. So head over to AdafruitDaily.com to subscribe to that. The next meeting will be held on Monday as usual at 2pm Eastern 11am, 11am Pacific, and that is going to be on June the 13th. This meeting will be held on the Adafruit Discord, which you can join by going to adafruit.it slash discord and to be notified about the meeting and any changes to the time or day you can ask to be added to the circuit Python Easter's role on Discord. So that's all for today. Thank you again to everyone, and we hope to see you all next week. Thanks. Thanks everyone.