 Hello everyone. This is the Circuit Python Weekly Meeting for December 4th, 2023. It's the time of week where we get together to talk about all things Circuit Python. I'm Jeff, or Jepler, and I'm sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is sponsored primarily by Adafruit, so if you want to support Adafruit and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafru.it-slash-discord. We hold this meeting in the Circuit Python DevTex channel and the Circuit Python Voice channel. But we've got people in almost all world time zones, so if you just want to show up and talk about Adafruit pertinent stuff, we welcome you anytime. This meeting typically happens on Mondays at 2pm Eastern Time, 11am Pacific Time, those are American time zones, except when it coincides with a US holiday. In the notes doc, there's a link to a calendar you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you'd like to receive these notifications, there's usually two or three a week. Ask us to add you to the Circuit Python East's Discord role. I mentioned a notes document that accompanies the recording. If you're watching this after the fact, the link is down in the show notes and includes timestamps so you can skip to the part of the video that interests you the most. This meeting tends to run 30 to 60 minutes. After each meeting, we post a link to the next meeting's notes document in the Circuit Python DevChannel on the Adafruit Discord. You can find it by going to the pinned messages list and then you can add your notes at any time during the week before the following meeting. And of course, if you wish to participate but can't attend live, you can leave your hug reports and status updates and the host will read them out during the meeting. This meeting is held in multiple parts. Next up is community news, a look at all things Circuit Python and Python on hardware in the community. It's a chosen set of items from our Python on microcontrollers newsletter, which now also comes out on Mondays. The second part is the state of Circuit Python, the libraries, and Blanca, a quantitative overview of the whole project, a chance to look at things by the numbers separate from status updates. Then we get to the first of our round robin parts called hug reports. It's an opportunity to highlight the good things people are doing and take the time to recognize the awesome folks in our community. Fourth is status updates. It's an opportunity for you to report on what you've been up to. We invite you to take a couple of minutes to talk about what we have been doing in the week since our last meeting and what you plan to get up to over the next week. And the fifth and final part is called in the weeds. If anything merits more long form discussion, this is the place for it. That can result from something during status updates that is taking longer than anticipated or something that you identify ahead of time as needing more of a group discussion format rather than a report. And that covers how the meeting will go. So I'm going to head over to the notes document, scroll up to community news, and tell you about some of this cool stuff in our newsletter. So first up, Eben Upton hints at an RP2040 successor and promises a Raspberry Pi Compute Module 5 in 2024. And there is a link in the notes doc to hackster.io and I think that review has been published in a couple of places. And here's a quote. We know what people don't like and what people do like and we have a chip team. All right, next up. This is a new one on me, Nanopi, a new Python for programming microcontrollers. Oxon AG in Switzerland has renamed Oxopi to Nanopi and are touting it to program microcontrollers. Nanopi is a simple and clear scripting language that both beginners and experienced users can quickly get to grips with. It is used in microcontroller projects, for example, for smart homes, educational and gaming computers, or automation and robotics projects. Nanopi masters the well-known Python style or can be programmed even more simply in a more compact form without colons and fewer brackets. And speaking as myself again, I did take a look at their website today and it's a language that is like similar to Python in style, but the notes say that it is a statically typed language which is different than Python, different than circuit Python. So that's very interesting and it's interesting that they wanted to kind of choose a Python layout for their programs, but I don't think it tries to hue as close to standard Python as circuit Python and micro Python do. So I wish them all the luck in their project. Anyway, these are just a couple of items from the Python on microcontrollers weekly newsletter. And the Python on microcontrollers weekly newsletter is a circuit Python community-run newsletter emailed every Monday. The complete archives are at adafruitdaily.com slash category slash circuit Python. It highlights the latest Python on hardware-related news from around the web, including circuit Python, Python, and micro Python developments. To contribute your own news or project, edit next week's draft on GitHub and submit a pull request with the changes. Links are in the note stock. You may also email cpnewsatadafruit.com or tag a post with hashtag circuit Python on Mastodon, Blue Sky, or X, formerly known as Twitter. And Ann says, please tell folks about the newsletter. It's free to subscribe with no ads or spam. Yeah. So that wraps us up for the newsletter, or at least this tiny little view of the newsletter. So next up is the state of circuit Python, the libraries, and Blinka. We use our adabot to run a report of the last seven days of activity. This runs sometime in the early hours on Monday morning, and, yeah, reports on approximately seven days of activity. So over that time, we had 35 pull requests merged from 20 authors and seven reviewers. And I failed to highlight the new or less frequent contributors, so let me just scan through this list real quick. M. Rangan, Tristan Warder, Uberie, WizDPI, KingFeru, Argrisel, and some of the others are less familiar to me, so I want to say a big thank you to them. While some of us are able to do this, kind of as a day job, it is also wonderful when people just with an interest help make things better for everybody. So thank you very much. Reviewers, we had seven reviewers. In addition to the Adafruit people, I also want to thank Bill88T for your reviews this week. And issues-wise, we had 28 closed issues by 10 people and 22 open by 19 people. So just overall, it's really a nice number of pull requests merged, as well as a wide range of authors, reviewers, and people interacting on issues. We're also down a little bit on issues, so that's always heartening to see. And that wraps it up for the top-line statistics. And next, I've asked Dan to tell us the statistics on the core today. Okay, thanks, Jeff. So in the past week, we had 18 pull requests merged by 11 authors. As Jeff mentioned, some new names. That's great. WizDPI, Henry Clinton, and Nogman, I see. There were five reviewers, and now there are 18 open pull requests, which is a nice number that's getting smaller. A few of them are really old because they're waiting other things. In the past week, there were 12 issues that were closed by five people and 13 opened by 10 people. So that's staying about the same. There are 662 open issues right now. There are eight active milestones, which is how we track up what needs to be done by when. There are two issues open for the 10.00 version, which is now strictly a figment of our imagination. But those are things that we'll need to change when 10 comes out. Usually it's removing deprecated features. There's one open issue left after 8.2.x. Just to interject here, Scott and Jeff and I had a triage meeting where we cleaned up some of the open issues and moved them around. So the number of open issues for 8.2.x went down to only one issue now. There are now only 41 open issues for 9.00. There were more like 50 or 60 before that. There are seven issues open for 9.00.x. So some of the ones that were for 9.00 we pushed forward and we pushed a few of them to a long term. There are 23 open issues having to do with libraries, 563 for long term things, 14 which are support, which means we're not sure that they're bugs or it's obvious that it's somebody who's just needing support with a particular issue. And there are 10 issues that are third-party issues that are dependent on something that is beyond our control right now. And there were a few issues not assigned to Milestone, but we probably triaged those already. Okay, that's it for the core. Thanks, Dan. Next up, Tim will take us on a tour of the libraries. Thanks, Jeff. This section covers all of the circuit Python libraries, which are the Python layer of code. All these libraries live on GitHub under names like Adafruit underscore circuitpython underscore and then some library name. Across all of those libraries this week, we had 14 pull requests merged from nine authors, a couple of the names that were newer or less frequent to me, at least, were Tristan Warder, Uberi, R Grizzle. So thanks to those folks. And I'll say also for the less frequent contributors, it's really nice to see Jerry as well. Hope you're doing well, Jerry. Nice to see you pop up in here as well. For those PRs, we had six reviewers, which is mostly the usual team, but I'll say a shout out to Brent this week for popping in to do some circuit Python reviews. Brent's been over in Whippersnapper IoT land, so it's also nice to see Brent pop up. The list of merged pull requests is here in the note stock. If you'd like to take a look at it. Of those that were merged this week, the oldest one was 122 days old and the newest one was brand new at just one day. That leaves us with 57 pull requests that are remaining open. And also we have, for the week, we had 12 issues that were closed and seven new ones opened by seven people, which leaves us with 688 open issues. And of those, there are 19 of them that are labeled good first issue. You can find those 19, as well as lots of other helpful information over on circuitpython.org slash contributing. If you are interested in getting involved with Circuit Python, you want to help contribute code or reviews, time, effort, testing, anything like that, head over to circuitpython.org slash contributing. This is going to allow you to contribute on the Python side of things. On that page, what you're going to find is a list of the open pull requests and open issues. The issues side is where you can find the filter for the good first issues. If you're interested in getting started with reviewing, check out the open PRs. Take a look at any code there, even for things like spelling and just basic information in the code. You can try it out if you've got the hardware. If you are wanting to do some coding yourself, check out the list of issues and find something that you've got some hardware for or have an interest in trying to tackle. Again, good first issue is one of the things you can filter out on that page. There are a handful of other filters if you like to get involved in there. There is a guide for contributing to Circuit Python with Git and GitHub, so if you are new and have not experienced Git or GitHub before, don't worry, we have a guide that can walk you through getting your code contributed and merged in. As well as the guide, there's also plenty of helpful folks around on the Discord, so you can join us on Discord to get help from folks throughout the week as well, because as always, we want to help you contribute in whatever way is best for you. The last bit of stats for the libraries this week is over on the PyPy side of things. These are the PyPy download stats across all of our libraries. The total this week was 114,613 downloads on PyPy. The top 10 list is listed out here with mostly the usual suspects, although many MQTT and a couple others DHT are some that I don't think we see in there most typically. There's also a list here if you want to take a look at them of the libraries that were updated, including a couple of the new libraries over in the Community Bundle, like the Lilligo T-deck. Let's see what is this one, the P1AM 200 Helpers. Those are new libraries over in the Community Bundle, as well as a list of updated ones here as well. So take a look at those if you'd like. And that's what we've got for libraries this week, thanks. Thank you. That was a couple of mouthfuls. To round out this section, Makar Melissa is going to tell us about Blinka statistics. Blinka is our secret Python compatibility layer for my Python Raspberry Pi and other single board computers. And this week we had three pull requests merged by two authors and one reviewer. There are apparently seven open pull requests amongst all the repositories. There were four closed issues by one person and two open by two people, leaving a net of 79 open issues. There were 13,921 Pi PI downloads in last week, 7,679 Pi Wheels downloads last month, and we are at 126 supported boards. And that's it. Thank you, Melissa. And now it is time to start the participatory stuff in the meeting, which is the best parts. We will go on to hub reports. As I mentioned before, hub reports is a chance to highlight folks in the circuit Python community and beyond for doing awesome things. I'll start and then we'll go down the list in the document order, which we try to keep alphabetical, but you know, no problem if it's not, and give everybody a chance to participate. If your text only are missing the meeting, I'll read your notes when I get to them in the list. All right, and here we go. So I have a group hug for all y'all, and I specifically want to thank Dan and Scott for the organizing or triaging of the 9-0-0 bug list. We need to make that list tractable and then get to work on it. And finally, Katnie, thanks for chatting last week. I really appreciate you staying in touch. And next up is Dan. Okay, hold on. I've lost track of my... Okay. So, thanks to Scott for noticing that ESPIDF 5.1.2 has dynamic services, which is something we were waiting for for BLE. We thought we'd have to do it ourselves. So this is for Expressive BLE. Thanks to Katnie for a nice catch-up conversation, as you did also, Jeff. Thanks to ACC, who was continuing to investigate the macOS Sonoma problem, which delays rights to the Circuit Python Drive. He was able to instrument the rights on the Circuit Python side to see which metadata and data rights were happening when, and it was extremely helpful. And thanks to Scott and Jeff for the triage meeting we had about 8.2.x and 9-0-0 bugs. All right. Thank you. Next up is DJ Devon 3. Thank you. I just have hugs for Anecdata and Justin for helping to troubleshoot and add-a-fruit issues, request. I hugged a foamy guy for reviewing some PRs that I submitted and Gladick for reviewing a PR, and he had some really good feedback on some changes. And that's it. Thank you. Next, I have notes from David Glode, who can't make it today, but sends a group hug. And next is foamy guy. All right. Hug reports. For me this week, thanks to DJ Devon 3, who's been helping out lots of folks over on Discord in the Help With Channel. Thanks to Dexter, who has done some really nice testing and reviewing of some work that I'm doing inside Circuit and a group hug for everybody. Thanks. Great. Next is Maker Melissa. I had a hug for you, Jeff, for a nice chat to catch up on things and group hug to everyone else. Thank you. I was going to thank you, but then I wasn't sure if it was two weeks ago and I didn't actually check. So yes, hug right back at you. And next up is Scott, also known as Tan Newt. Hello. First, I hug to Jeff for filling in for me and Liz recently for meetings we weren't able to do. Hug to Jeff again and Dan for the 9.0 issue prioritization. Hug to foamy guy for the Web workflow support in Circuit and the library wrangling. And lastly to Maker Melissa for all of the Pi 5 work and support. It's a lot of work to have a bunch of people come with a shiny new thing and expect everything to just work. So thank you, Melissa, for taking that all on. And to round out the section, I've got some notes from Todd Bot who is text only. Todd Bot writes group hug. Thanks, everyone, for making Surpi such a nice platform. It's so much more rational than the others I use. And one for Tan Newt for USB host on RP 2040 and you ate a fruit USB host MIDI. It's a great start to what will be huge for reusing all those cheap USB MIDI controllers as UI devices for projects. And I want to second on that one because I have a MIDI keyboard that I would like to use with Circuit Python. That wraps up hug reports and that brings us to the status updates. That's our time to tell folks what we've been up to individually. I'll start and we'll go through the list in document order. When I call on you, take a couple of minutes to talk about what you've been doing since the last meeting and what you plan on doing until the next meeting. This is also an opportunity to provide quick tips and tricks, but if a discussion becomes at all long, we'll want to move it from status updates to in the weeds. And with that, I will get started. So I'm kind of in a yak shaving mode and I'm going to do this from the inside out. So in Circuit Python build tools, I've got an open PR that adds support for including arbitrary binary files with packages, which is any library that has a directory structure. This relies on metadata in the file called pyproject.toml and we never checked that data before. If the library was also published on PyPI, it would have been checked, but this is new for Circuit Python build tools. So of course, it didn't work with all the libraries. I made a list of all the libraries that didn't work right. They are mostly in the community bundle. In the Circuit Python build tools change, I have a blacklist so that this doesn't need to hold back incorporating the PR because folks in the community bundle are obviously not necessarily going to respond as quickly to an issue as we would like in order to incorporate this change into Circuit Python build tools. So for that to be ready, I need to make one last check that the contents of the bundle are unchanged before and after my changes, so we aren't, for instance, failing to package files that we should have packaged up. So that is to enable some things with the Circuit Python library that we're calling pycam, which is for an upcoming camera product. I've reorganized it so that the firmware for the autofocus feature of the camera can be bundled inside the library rather than copied into all of the examples. And I added a mode tentatively called G-Boy because it's inspired by the Game Boy camera, which shows a one-bit black-and-white-dithered version of the camera image and then can save that to a GIF on your SD card. Once that's done, then I still need to add it to the bundle, add it to PyPI, and add it to read the docs. The next thing I've got as an iron in the fire is JPEG IO. I've started a skeleton implementation of JPEG decoder. It is going to take a JPEG from an in-memory buffer and output it to an RGB 565 bitmap in memory. And initially, this is just going to work on the expressive family microcontrollers that have JPEG code in their ROM. But we are choosing... This is also a library that's open-source, so we will potentially be able to incorporate that same library on other microcontrollers within the flash. But the goals are all relative to two kind of products, which is the Qualia. We'd like to decode JPEG images and display them on an LCD or dot-clock display or whatever from CircuitPython. And for the camera, we'd like to, for instance, display an image, like review an image on the viewfinder, which is a common feature of digital cameras. And doing that, like actually from the JPEG, would be the most obvious way. Anyway. And let's see, I'll just delete that item because we don't need to talk about that. And anyway, in personal news, I got a Resin 3D printer, the Elegoomars 3 Pro, which is actually quite an entry-level printer. I've had some initial success. My project that I really want to do is to print keycaps for all of my homemade keyboards. But I've kind of had a string of disappointments and failed prints since then. And dealing with uncured resin, which is basically hazardous waste, is quite a chore. So I'm not sure I recommend it. I'll keep playing with it, but it's been a little bit up and down. And yeah, just dealing with the goo is kind of unpleasant. So with that, I will hand things off to Dan. What's up? Okay. So I'm still working on A2X and 900 bugs. As I mentioned, we had a triage meeting. And so that was really helpful because we got rid of some bugs and we filled each other in on our hints about what's wrong, might be wrong. So we have more direction about what to work on and hints of what might be wrong for the bugs that we're still trying to work on. And I'll probably work on some more releases soon. There's nothing that's really imminently shippable, but there are a number of small changes for both the A2X and the 900 branches. And so we'll probably, maybe later this week or maybe early next week or something, we'll see what we're waiting for and whether we should delay until some significant thing gets changed. Okay. Thanks, Dan. Next is DJ Devin 3. Thank you. Last week I spent an entire week troubleshooting an issue with out of fruit requests running out of sockets. Ultimately ended up being a self-inflicted wound using session inside the main loop, which will absolutely lead to out of socket errors. And thanks to Anikdata and Justin, who spent a better part of a night with me and the next day helping me to troubleshoot that one. So they put in considerable effort, so they deserve a hug for those. I started adding some touchscreen GUI features to my feather weather project using the out of fruit button library instead of pad layouts, because it's just easier to go with the buttons. So instead of sleeping for 15 minutes between polling, it's now using those 15 minutes to search for button presses or touchscreen presses. And I'd like to get to build a menu system capable of changing the SSID and password using only the touchscreen. That way I can give that to a relative and they don't have to hook it up to USB or anything like that in order to change the Wi-Fi and SSIDs. I think that would be a nifty feature to add. Submitted a couple PRs that were approved and merged this week. The updated Twitch API example for out of fruit requests has already helped one person in Discord after Twitch's recent API breaking changes. If you attempt to use their old API, you will be greeted with a JSON message that simply says, gone, which is kind of funny. I've never seen something like that. The change breaks at least two out of fruit learn guides for live on-air projects using the Twitch API. So this is out of fruit folks notice that your Twitch API learn guides have been broken. And that's all I got. All right, next I have notes from David who writes, weeks of doorbell related activity, non-circupython part, modified a wireless doorbell by adding a bodge wire to the button PCB in order to press the button from a relay, acquired a made for ESP home smart doorbell, there's a link in the note stock, installed home assistant and ESP home add-on, with ESP home in a few clicks, you go from a YAML file describing the hardware to flashing the firmware, a bit like CICD IoT infrastructure as code, changed the YAML file to make a doorbell with 10 seconds of delay between button press and activation. Notice ESP home device can work standalone in my case with home assistant protocol or MQTT. And then there's the circuit Python part of the doorbell project. Doorbell song, turn a feather RP2040 prop maker into a Christmas song doorbell. Could I run circuit Python on the smart doorbell version 3? It is using an ESP32 war room. And the final result, a visitor presses the doorbell button and activates relay that closes three circuits. The Christmas wave file starts playing on the prop maker. The button from the wireless doorbell is pressed, triggering one or more remote ringers. And 10 seconds later, our traditional loud ringer is activated by the smart doorbell version 3. Sounds like a cool project. Next is ADCC. Hello. Hello. So I did more tracing on the Sonoma problem last week and produced what I hope to be the definitive trace of the problem. And sadly, I also determined that greater than 8 megabyte file systems don't actually resolve the underlying problem. And that's the late writing of the directory and FAT table entries. I've added both traces to the issue. Also, I've put the tracing code on a branch. So that's easily accessible at my GitHub. And early tracing results for iOS indicate that it is not affected, but tracing iOS is a bit problematic. I think I'll have a clearer trace later this week. And that's it. Thank you. That's very highly technical stuff that I think most people would shy away at taking on. So really excited to see that info coming in. Next up is Tim. All right. Over the past week, I've been continuing to work on SirCup Web workflow refactoring. As part of that, I noticed Scott made some improvements in the web workflow. So I went and grabbed the latest and greatest build and tested that out alongside of it. I did get stuck for a while because I managed to fill up the storage on my device. So I had a bit of a face palm moment where I was not being able to do anything because I actually just had no room left on my device. But eventually we made it past that and have kept going. I did some other reviews and testing on submissions for mini-MQTT and request libraries. Outside of CircuitPython, I've been enjoying the challenges for Advent of Code 2023 as well as TriHackMe's Advent of Cybersecurity. I've had lots of fun solving the challenges that have popped up so far. And it got me thinking about potentially trying to make a CircuitPython-based Advent event for next year. I'm curious to see if anyone else is interested in something like that, especially if there's any people interested in helping to write challenges or helping to write story or people who are perhaps interested in participating. Feel free to reach out and I'll gauge interest on that. And the other thing that I have gotten into this morning was running the patch with Adabot in order to fix an issue for the Sphinx builds specifically inside Read the Docs. And it also unpins Sphinx in the same change. And then I have been working through the ones that were not able to go automatically. There was a couple of them that the patch didn't apply to because there were slight variations in the file and then there were a couple that didn't push because there are different permissions on the repo. So I've been working through those and I'll put together a list of all of the repos that have different configuration as well. And that is what I've got for now. Thanks. Thank you. Next, it's maker Melissa. Hello. So last week I worked on... I updated the Quality Guide with Backlight Info or Arduino Library Installation and another example. I worked on the Quality Helper Library Guide and I worked on some GitHub issues in PRs. This week, while I was working on the Quality Helper Library Guide I found a bug in Secret Python that seems to have been introduced sometime between Alpha 2 and Alpha 5 which causes an intermittent delay in reading capacitive touches that I need to narrow down some more. And then I need to finish up the Quality Library Guide and I need to add the bar displays to the Quality Guide and Quality Library and then take a look at some of the Raspberry Pi issues. And that's where I'm at. All right. Sounds like a full plate. Next, I have a note from Paul Cutler who writes, the new episode of The Circuit Python Show is out today featuring Max Lupo. Max shares how he uses Circuit Python in his art pieces and installations. Next is Scott. Hello. Thanks, Jeff. I updated the ESP IDF to 5.1.2, merged in hoping it fixes some issues and also just kind of wanting to do some churn before we start to stabilize 9.0. Dan suggested I look at the release notes and I noticed pretty quickly that it includes the support for dynamic BLE services which is what blocked me when I was originally adding BLE support to ESP. So that's super exciting, but I'm not letting myself get distracted. So we should be unblocked on the expressive side which is really cool. So I'm circling back. I was working on making SD cards available over the web workflow. This is kind of like a sub-task of getting file sizes showing up or free space sizes showing up in the basic file manager. And then there's a number of bugs for the ESP for 9.0 that I'm going to look at later. My mom who's sick is going to be staying at our house Wednesday and probably Thursday nights as well. So I may not be around as much when she's over because it's important to spend time with her. And that's my week. Thank you, Scott. And last up, I have a note from Todd Bot who writes, Fun hobby this month is doing adventofcode.com in Python. Mostly circuit Python compatible Python since that's what I know. And that rounds up status updates. The next section is in the weeds and our first and only topic is from Justin. So take it away, Justin. Yeah, thanks. I'm so excited to be here. I've been using SufferMater fruit for a really long time. I've been a Python developer for a long time and finally got to the point where I'm switching over and starting to do a lot of work in circuit Python, which I'm loving and trying to just help out where I can. And so, you know, as DJ Devon 3 noted, you know, he was struggling with an issue and we spent quite a bit of time kind of looking into it. And it just started making me think, right? We're going to, you know, we have this, you know, very limited architecture that we can use and lots of new users who aren't going to necessarily realize that, you know, things like requests and MQTT and things like that are all going to, you know, use the sockets a little bit different and everything like that and have the thought of, you know, is there a way to make a more generic session library that would then allow everything and even additional things that people add to connect to the Internet through your guys' devices and other devices to kind of use a shared pool and really kind of track what's going on as opposed to them being separate. Often when I've done things in shared environments like ate a fruit and things, you know, you go open up a pull request and then the people that are reviewing it have a particular structure or different thought processes. And so before just kind of digging into something and spending a lot of time to build something, I kind of wanted to get feedback and see if this was a good idea, a way that ate a fruit wanted to go and CircuitPython wanted to go with, you know, kind of making some of these things kind of simpler. So that's kind of my high-level pitch and would love to hear some thoughts and comments and maybe there's other places this is already going that I don't know about. The first thing that I'm thinking of is like with the new memory changes that we just did in 9.0, it might be possible for us to just support more dynamic sockets. I haven't looked in great detail. That's only un-expressive. But it's, I don't know, it sounds like reusing sockets is, you're talking about creating a shared library for managing reusing sockets and that is less important if we can just have more of them. But I haven't really looked into that as well. Generally, I like the idea of splitting things out and sharing it. But memory use is also a thing to think about. I like the idea because I keep running into issues where if you put the wrong line in in a while true loop and it's failing, the errors are not generally helpful. So it would be nice if it does it all like within Adifurt requests or in many MQTT where it can handle all the exceptions and gracefully fail because it doesn't do that right now. You have to manually add in your exception handlers in your script and then your script gains like 200 lines just trying to get the thing to gracefully fail over and over and over. So I'd like to see that kind of thing built into the library to make it easier and I'm sure that was the original intent but it just doesn't quite work. That sounds like something separate to what I assume Justin was talking about. It is but I think that kind of thing needs to be part of that. And I would totally agree with that and I'm all for a very stepped approach, right? Like not just changing the way requests works today but adding things and kind of doing it small pieces at a time. I love small PRs that people can review versus this huge like, oh, we just changed how we do sessions and error handling and things like that. Like other random things having there is like using context and things like that. And so even if you do use in the loop it automatically cleans itself up and you don't have to worry about like the self-replacing and everything like that. And potentially even some updated documentation to say even right now with requests, make sure to initiate your request session at the very top of your file and never do it again. Like there's a lot of low-hanging that could kind of go through this process of changing requests and making a little bit more user friendly for newer people. Yeah, I mean, I'm all for that and I really appreciate you coming here and asking about it up front, like you said. I definitely don't feel, I think, you know, I request has a long, a different request has a long history because it started from micro Python code and then I did a lot of work on it at some point as well. I don't feel particularly attached to it, so feel free to improve it with the caution that I think after the session is created it should work the same as like the regular Python requests. And I think that's a, I think there's a challenge about where the boundary for error, network error handling is and that could be part of it, which is really tricky. Yeah, and I agree. I've used regular Python requests for very long so I'm super familiar with that and I definitely wouldn't want to, you know, love to be at how things were, you know, someone writes a library for regular Python and it's super easy to port it over, you know, because request works the same way and so that type of thing is really important to me. Yeah, and that's usually, yeah, that's usually the barrier where I'll like pump the brakes on people's work. It's like, wait, wait, wait, wait, like you're making this super custom and now you're breaking compatibility with CPython. So that's a big no-no for me, but if you can work within those parameters, it's fine. I just want to read a note from Anecdata as well that says it's been a recurring support issue when multiple socket-using network libraries are used in a project. Each reserves one or a set of sockets independently depleting the limited supply. Yeah, and that's kind of the exact thing I'm trying to figure out a way to alleviate, you know, and so if they're all using one, you know, one major, you know, handler that goes through and goes, okay, this is when one's been released and whatnot and so now I can grab it and I even saw, you know, some examples of, you know, finding out how many sockets are available still, like potentially been building some of that stuff in as well so people could look and even test before they connect to actually have a socket available before I even try to connect to something. So really just trying to streamline. So for a month I'm hearing, it sounds like I'm good to go to start working on something on a high level and then, you know, open a first level PR or something and get some high level, you know, comments on it and if, you know, people think it looks good, just kind of run with it. Yeah, and early and often as you're doing already is great. Yeah, the only other thing I would say is like there hasn't been a lot of work done to see if we can't just have more sockets. So that is something worth considering as well. It's just trying to tune internally how many sockets we can support. But with that I still see this you, right? Kind of like I forgot who mentioned that, right? Ran out of a hard drive space, right? Like no matter how high you make that number, potentially, you know, unoptimized code will still hit that limit at some point. Right, and we're all about good error messages too. So if you can improve error messaging and stuff, be really proactive or suggesting really proactive things for folks, that's great. Awesome, thank you so much. I have a script that runs through seven different APIs in one script and it worked when I wrote it. So you're free to try and use that because that one is a juggernaut. It just goes through seven different APIs. Twitter has since broken, Twitch has since broken. That's the one bad thing about working with APIs is their APIs can change and break at any second. That's very true. Yeah, if you can send me which one that is, I've seen some of your stuff, but if you can help direct me to which one that is, I'd be happy to kind of use that as a benchmark. Does anyone happen to know in the core implementation of our socket pool, does our socket object have a finalizer so that when it becomes garbage, it will be closed and release all those resources? And if not, is that something we need to add? I don't know. I haven't looked enough into it. I know one of the issues specifically is, like the way the fruit request session works is when it finishes, it calls close, but then it actually doesn't close. It holds it open, which it should be, because it's for request, right? In case you try to hit the same site again. But then if that particular thing is like re-nitted, all of that data is lost at that point, you know, which is the issue that DJDLM3 was having. So I know there's some places that do some automatic cleanup, but potentially not all places. So that would definitely be a place I would go look into and see, which may potentially even be digging into some of the C code as well. I don't think socket pool does that. Do you think that would be a good addition? So socket pool doesn't actually reuse sockets. So it might be that just sockets need to close automatically. Yeah, there's certainly a world where we're not, that we're leaking sockets as possible. Yeah, I was just imagining that, like, assuming that, say, DJ Devon's code wasn't keeping around 100 session objects, it only had one at a time. And the other session should have been an object that could be GC collected. Making sure that that actually freed the socket objects could make it able to limp along. It still wouldn't be ideal code. It'd be great if we could offer people a better way of structuring their code. But the discussion made me wonder if there was something like a finalizer missing that could improve things. That's all. I'll definitely dig into that. Like, that was one of my questions that I hadn't passed when we were troubleshooting to see if a garbage collect would fix anything. And so I will definitely have that on my list. That was one of the changes that I made was I removed the garbage collection from the script and then it started bailing. I was doing too much too fast, but the garbage collection, I think, was working. And then when I explicitly tried to close the sockets, they were not closing without GC. I don't know why. Yeah. All right. It looks like socket pool does have, is registered with a finalizer, but I'm not sure it actually is hooked up. Okay. So Justin, if you don't mind summarizing like any of the things that folks said that they didn't write in the document, just as we continue and close out the meeting, that would be helpful. And then otherwise I will take us to the wrap up section. So this has been the Circuit Python Weekly Meeting for December 4th, 2023. If you want to, thank you to everyone who participated. If you want to support Adafruit and Circuit Python and those of us that work on Circuit Python, consider purchasing 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 is available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. Visit AdafruitDaily.com to subscribe. The next meeting will be held next Monday at 2 p.m. Eastern 11 a.m. Pacific as usual. That's Monday, December 11th. It is held on the Adafruit Discord, which you can join by going to adafru.it slash discord. 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. We hope to see you all next week. Thanks, everybody.