 Hello, everyone. This is the CircuitPython Weekly for Monday, December 18, 2023, is the last CircuitPython Weekly for the year as well. This is the time of the week where we get together to talk about all things CircuitPython. I'm Liz, and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support Adafruit and CircuitPython, consider purchasing hardware from adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.it slash discord. We hold the meeting in the CircuitPython dev text channel and the CircuitPython voice channel. This meeting typically happens on Mondays at 2 p.m. U.S. Eastern Time, 11 a.m. Pacific, except when it coincides with the U.S. holiday. In the note stock there's a link to the calendar you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you would like to receive these notifications, ask us to add you to the CircuitPython Nisa's Discord role. There's a notes document that accompanies the meeting and recording. You can contribute to this document beforehand. The final notes document includes time stamps to go along with the video, so you can use the doc to skip around and view parts of the video that interest you most. The meeting tends to run 30 to 60 minutes. After each meeting, we post a link for the next meeting's notes document in the CircuitPython dev channel on the Adafruit Discord. Check the pin messages finally as notes doc so you can add your notes for the following meeting. If you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. This meeting is held in five parts. The first is community news. This will look at all things CircuitPython and Python on hardware in the community. It's a chosen set of items from our Python on microcontrollers newsletter. Second part is the state of CircuitPython libraries and Blinka. This is a quantitative overview of the entire project. It's a chance to look at the project by the numbers separate from our status updates. And the third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. Fourth part is status updates. Status updates is an opportunity to report on what we've been up to. Take a couple of minutes, talk about what you've been doing last week since last meeting and what you'll be up to over the next week. Fifth part is in the weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or be something you've identified ahead of time as too long for status updates. And that covers how the meeting will go. And with that, we'll get started with community news. So, big news. CircuitPython 9.0 alpha 6 released. CircuitPython 9.0 alpha 6 and alpha release for 9.0 has been released. It has significant known bugs and will have further additions and fixes before the final release of 9.0. And that can be seen on the AFroot blog and GitHub release notes. Always appreciate folks testing it out. I've been using it as well. And then the second editions of two favorite books are going to be released. Programming the Pico book has been updated to a second edition with a new chapter on the Pico W. Programming mainly in MicroPython with a couple of examples in CircuitPython. That's by Simon Monk. And then making embedded systems is getting a second edition refresh. That's by Alicia White. And they'll have new chapters about motors, managing network sensors, IoT, debugging hard faults and more. It's scheduled for a March release and can be preordered from booksellers now. And then Project of the Week detecting ghost aircraft with Python. Angelina Suboy has created what she calls Flycatcher, a Raspberry Pi powered system that can detect false aircraft using automatic dependent surveillance. Flycatcher works by monitoring the 1090 megahertz frequency and can determine whether or not a potential aircraft is genuine thanks to a neural network developed just for this project with the app coded in Python. This and more is available in our weekly Python for microcontrollers newsletter which goes out via email on Monday mornings. Visit AdafruitDaily.com to subscribe to the newsletter. Thanks to Ann for putting the newsletter together. If you have any Python on hardware projects to share or find content you'd like to see included, please consider contributing to the newsletter. You can open a PR on GitHub, mention Ann Engineer on Twitter with hashtag CircuitPython, or email cpnews at Adafruit.com with a link. And that is community news. Next up is the state of CircuitPython libraries and Bollinka. And so this is the quantitative overview of the entire project. It gives us a chance to look at the health of the project separate from our stats updates. We'll talk about the project overall and then separately discuss the core libraries in Bollinka. First up overall, there were 15 pull requests merged by 11 authors. That is W. Tumura, Jepler, FOMI guy, Dan Halbert, how to flow, PR, PLZ, Michael Pakusa, LCMC, NINCH, Vladek, Bill88T, and Maker Melissa, five reviewers, Jepler, FOMI guy, Dan Halbert, Tanute, Maker Melissa, and 16 closed issues by 11 people, 22 open by 20 people. And now we'll hear about the core from our own Jeff. Hello. So in the core, which is the part of CircuitPython that is written in C that you might load with a UF2 file, it was a pretty quiet week. We had five pull requests merged from five authors. Thanks to, I think we pronounced your name as purples. I'm not sure. You're a less frequent contributor and it's nice to see you were working with us this week. Reviewers wise, we had two reviewers. We have 18 open pull requests, which is below that kind of panic threshold of 25 that we like to keep things under. About, it looks like three quarters of those are draft. If you have a draft pull request, we would really encourage you to either move that towards completion or close it if you're not going to be able to work on it right now. And as far as the other PRs that are open, please, if you're waiting on somebody else, please give a ping so that we can move those pull requests along. The oldest one has been open for 531 days. So it is getting a little long in the tooth. Issues wise, we had five closed issues by four people and seven open by seven people. So again, a quiet week turning upwards a little bit on issues that leaves us with 671 open issues. We welcome folks who want to work on any of those issues, but we tell you about what circuit Python or what Adafruit is prioritizing in circuit Python by using the milestones feature. And our main focus right now is on the 9.0.0 milestone, which when we get down to zero open issues will feel like we can make the stable release and call it 9.0.0. And for that, we've got 43 open issues that we're looking at. Another key indicator here is issues not assigned a milestone. We've got four of those as of the time this report was generated. And Adafruit people need to look at those and categorize them. But yeah, if it is something about your needs, we would love it if you picked up any of those issues, including long-term issues to work on them and submit a pull request. And that is what I've got for the core. Thank you. Excellent. Thanks so much, Jeff. And now we'll hear from Foamy Guy for the libraries. All right. Thanks, Liz. This section will cover the circuit Python libraries, which are the Python layer of code that allow you to interact and interface with various different bits of hardware, like sensors and other things, or provide helper classes just to make it easier to do your projects at higher level without worrying as much about the details. All these libraries are on GitHub under names like Adafruit underscore, circuit Python underscore, and then the name of whatever library it may be. Across all those libraries this week, we had eight pull requests merged by six authors. The name there that stood out to me as someone who was perhaps new or less frequent contributor this week was LCMCN inch. So thank you to them. And then we also had six total authors. So we had five of us who are more frequent. And then in reviewers, we had four reviewers this week, mostly the usual folks, Jeff Scott, Dan, and myself. So thank you to reviewers. And then of the pull requests that were closed this week, those eight pull requests, the oldest one was 38 days, the newest one was just one day. So mostly more on the newer side this week. After that, that leaves us with 63 open pull requests of which the oldest is 487 days, the newest is just one day. I will echo essentially Jeff's sentiment from before, if you have got any open pull requests in library land and you think they are in need of attention from somebody on our side, please feel free to ping me or circuit Python librarians or something on there. And we will take a look. And for anybody else, if you want to help with reviews or testing or anything like that, you can learn more about doing that at circuitpython.org slash contributing. We're always looking for more folks who want to get involved in the project. And reviewing is one of the best ways to get started. So check that out. And if you need help with Git or GitHub, we have guides for that. We also have folks around on Discord who can help you contribute no matter what skill level you have. Let's see, back into the stats, we did have nine closed issues this week by six people and 11 new issues opened up by 10 people. That leaves us with 703 issues open. And there are 19 of those that are labeled good first issues, which you will be able to find on that page at circuitpython.org slash contributing. If you click on over to the issues tab and then use the drop down filter that's near the top to search for good first issues. Those ones have been identified as best for folks who don't necessarily have as much experience with Python or even programming in general sometimes. So that's a great place if you are brand new, but want to jump in. In the library, PyPI stats this week, we had 149,600 PyPI downloads across those 323 libraries. There is a top 10 list here, if you're interested in the breakdown of those stats to check out in the note stock. And then for the updated libraries this week, it looks like many MQTT, Py Camera, and then from the community bundle as well, the micro OSC from Todd Bot got some updates this week. So thanks, Liz, and that's what we've got for libraries. Thank you very much. And now we'll hear from maker Melissa on the status of Blinka. Oh, so Blinka is our circuit Python compatibility layer for MicroPython, Raspberry Pi, and other single board computers. And this week we had two pull requests merged by one author and one reviewer. They're apparently six up and pull requests amongst other repositories. There were two closed issues by two people and four opened by four people leaving a net of 84 open issues. There were 17,484 PyPI downloads in the last week, 9,399 PyWheels downloads in the last month, and we are at 128 supported boards now. That's it. Great. Thank you. And that is the state of circuit Python, the libraries, and Blinka. Next up is Huggerports. Huggerports is a chance to highlight folks in the circuit Python community and beyond for doing awesome things. I will start and then we'll go down the list alphabetically to give everyone a chance to participate. If you're a text only or are missing the meeting, I'll read your notes when I get to them in the list. And I would like to kick things off with a group hug. And then in hearing Melissa's stats, I'd also like to give a hug report to Melissa for excellent documentation on how to get up and running with Blinka on a Raspberry Pi 5. I had been putting it off and then last week finally got around to it and had zero issues because following her update guide. And now I will read for anecdote who is missing, the meeting hug report to ADCC for all the work on Raspberry Pi, Wi-Fi access point starting and stopping. And then C Grover who is text only, Paul Cutler for being a gracious podcast host and expert editor. He kept me on track during recording and made the results coherent. And to the community and the team for amazing progress on the next version. And then we will go to Dan. Okay, so a community hug or group hug, whatever you call it to everybody. I really appreciate all the help that people give in discord to people. It saves up me time not having to give help. And I just appreciate everyone contributing to Circuit Pi 5. And then thanks to FOMI guy for some quick reviews of some pull requests I made this morning that updated display IO usage. So that was compatible with vote 8XN900. All right. Thank you. Then I don't see DJ Devin. So I will read for him. Jay Posada for adding fork awesome bitmap symbol font support to the bitmap fonts library in 2021. They're very handy for GUI design. Then next is David Glaude who's text only. Dan for huge help on getting up to speed with my ESP32 C6 DevKit C1N8. And then ADCC who is also text only. Big hug to Anecdata for helping out with the AP Restart bug and that was bug 8718 on RP2040. And a huge holiday hug to everyone working on this project. See you all next year. And now we'll hear from FOMI guy. All right. Thanks Liz. My hard reports for this week. Thanks to Jeff from actually a couple of weeks back for doing some work in Circuit Python build tools to add support for non Python code files into the libraries that get built into bundles. That's super cool functionality. Also another one for looking into adobots long run times and submitting improvements around that. Hugs to DJ Devin for making an awesome soft keyboard layout with Display.io that utilizes the grid layout. And as well just for working generally towards an idea for projects having the ability to be configured by their end users without the use of a PC and even with a lower technical barrier to entry than Circuit Python already has by trying to build out controls and things on the screen to be able to set important settings like Wi-Fi information. I think that's really cool. Thanks to Dan for resolving some GitHub repo settings issues from the weeds discussion last week. And another one for working on the 8x9x compatibility with the Display.io changes across several libraries. And then thanks to Justin for initially troubleshooting some issues without a socket errors in situations where people were using both requests and many MQTT together. And then also a huge hug for jumping in during the meeting to discuss it last week or I think maybe the week before and to work on proposed solutions for that. It's really cool to see somebody pop up with ideas and be interested in working on them and talking with us about them. So thanks for all of that. That's what I've got for now. Thanks. Awesome. Thank you. And now we'll hear from Jeff. Hello again. So last week I submitted a small PR to add a CPython compatible code op module with the compile command function in it. This is a building block of a custom REPL. I just noticed that this was something that we could add easily and I think there are some people who have interest around this. So we'll see what comes of it. The other thing I worked on were improvements to JPEG.io. I've got a work in progress branch. I believe I submitted that as a PR in draft mode. I'm not sure. But it can now instead of reading just the JPEG from memory view or a bytes or a byte array, it can read it from anything that can be read such as a file probably from a socket. I've still only tested it on like the circuit Python build process where we can run tests of modules that don't interact with hardware. But you know, it should work. What I'm working on is now is to support bitmap tools.blit style arguments for how to combine the JPEG data with the existing bitmap. So you will be able to, for instance, just select a rectangular part out of the JPEG. You'll be able to put it in your bitmap at an arbitrary position. And then there's the support for skipping a color index which is support-basic compositing. The caveat for that would be that because JPEGs are a lossy format, you can't depend on like having a green color key, depending on having all those pixels exactly that same shade of green. So it's not really going to work very well. But we'll start with that. Yeah. I think you're reading your status update rather than HuggerPorts. I am really sorry. That is what I'm doing. So HuggerPort to Fummy Guy for, yeah, I was scrolled to the wrong portion of the document. Okay, HuggerPorts. Give me a second here. Liz, one for you for working on some cool product guides. Dan, thank you for releasing circuit Python on a regular basis. Scott, thank you for coming by when you can and taking the time away as you need to as you go through this difficult time. One for Neradoc for seeding an idea in my brain with the way you created the keyboard layout bundle. For click on Ben on GitHub for bringing up a GitHub limitation that we can better document and we improve the release notes for bundle releases with this in mind. GitHub user, again, to BND Y5, notice some outdated stuff in circuit Python build tools and pitched in to make things better. And finally, I wanted to echo others in thanking ADCC for work on the RP2040 wireless, specifically the access point stuff. And those are my HuggerPorts. Thank you. Now we'll hear from maker Melissa. I just said a group hug. Thank you. And now we'll hear from Scott. Hello, how's my volume? Sounds good. Sweet. I think I messed it up, so I was guessing. For me, a group hug to everybody. You've all been a part of this wonderful circuit Python community and it's just a nice stable piece of my life as my mom is sick. So I just really, really appreciate all the support I'm good for everyone. So thank you all. Thank you, Scott. And thank you and your family during this time. And that was HuggerPorts. Jeff, I'm sorry, I think we're hearing you typing. And next up's going to be status updates. Status updates is our time to tell folks what we're up to individually. I will start and we'll go through the list alphabetically. When I call on you, take a couple minutes, talk about what you've been doing since the last meeting and what you'll be doing until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on. If the discussion becomes too long for status updates, we can move it to in the weeds. So with that, I will get started. I've been working on a compass project using the Qualia S3 and a 2.1 inch round display. I've made some good progress with it and we'll be writing up for a guide along with some photo and video of it outside, hopefully. But since Thursday, I've kind of put the compass on hold to work on some product guides and assist with Ruiz Brothers project, which I won't spoil, but you'll see that on Wednesday. You may have seen the Memento, Pi Camera, and USB host Featherwing come into the Adafruit Store last Wednesday. As a result, I'm working on those guides for both of them and want to get them done before we start napping for Christmas and New Year's break. So I've got heads down on that. Next, I will read for C Grover, who's text only. Getting closer to releasing a helper library for algorithmically generating multi-oscillator composite waveform samples for Synthio. Current version accepts a list of frequencies and relative amplitudes of multiple wave shapes, sine, square, triangle, saw, and noise, and produces a composite sample that can be used by synthio.note, synthesizer, LFO, and notes ring modulator. One of the challenges was detecting and correcting a potential loop distortion that happens when the value at the end of one sample is different from the start of the next. The first two proof-of-concept projects are a sample-driven version of the IoT Winshine project and a simulation of a Roland TR-808 top hat symbol sound with six square wave oscillators as a resonant noise source. Next steps include storing the sample into a collection folder and completing the companion playground note, and there is a link in the notes document to that note. And now we'll hear from Dan. Thanks. Okay, so as mentioned, I released Cercopython 9.00 alpha 6. It was about a month worth of changes since alpha 5, and we'll continue to do alphas or betas on an irregular schedule. And also, as I mentioned, there were several, I fixed several display libraries. It turned out they had examples that only worked in 9.00 or other minor problems having to do with 8.00 and 9.00 compatibility due to the display IO refactoring that Scott did. And this came up because someone actually was trying to use, someone in 4.00 was trying to use a 9.00 example that they found in a guide on 8.00 to X. And it didn't work. And so we really needed to fix those examples. So that's what I did. And otherwise, I've been reviewing things and working on 9.00 bug fixing. I would note that there are now no more open 8.00 to X bugs right now, which is good. There are something like 43 open 9.00 issues, which is better than it has been before. It was about in the low 60s before. So we're getting there. Okay. Excellent. Thank you. And now I'll read for DJ Devin. Added a way to display Wi-Fi network scan to a TFT display last week or find it this week to be much more reliable. Started using display IO grid layout to create a TFT touch keyboard due to the amount of labels and touch points required. The responsiveness is slow. It should suffice for changing Wi-Fi credentials, preferences, and settings. When I get it into a usable state, I'd like to make a commit to add touch keyboard layout to display IO layouts. Very cool. Next, I'll read for David Glaude, who's text only, ESP32C6. Installed circuit python alpha 9, alpha 6 on my ESP32C6 devkit C1N8. Testing web workflow because what is better than a circuit python device without mass storage to force you to try another workflow? Awesome. And now I'll read for ADCC, who's also text only. Resolved an issue that proved to be a race condition in CYW43 driver. After the new year, I'd like to visit reviving the circuit python CYW43 driver fork repository for this and possibly other issues related to implementing BLEIO. Continuing work on BLEIO, finishing up the GAT status base port from MicroPython today. Bluetooth stack doesn't have one built in. And now we will hear from FOMI guy. All right. Last week, I did another pass of refactoring inside of CIRCUP or specifically in a PR in CIRCUP that adds support for web workflow. Earlier today, I went back through and fixed up the test scripts to get them back to succeeding and handled all the remaining pre-commit failures that were in the test script. I did have to tweak a little bit of the base code while I was doing that. So I'm intending to go back and do another round of testing after the meeting sometime to make sure that I have not broken anything. But assuming that's the case, and I think that that is ready for another look, I worked on some enhancements for grid layout to allow it to correctly find which grid cells are at a given pixel location, specifically in the case where the cells span multiple rows or columns. This was already a functionality in grid layout, but it only worked for cells that were either one by one or if you happen to choose a pixel coordinate that was in the top left of a multi-spanning cell, then it would still work. But if you chose any other portion of a multi-span cell, it would not. So I added that functionality to make it work with multi-span, which was in anticipation of the next item, which is working on a soft keyboard helper library. This was built from DJ Devon 3's initial code, and I'm hoping to build it out enough to kind of contain all the complex details of the layout and things like key maps and which keys have been pressed and things like that get all of that contained inside of a helper class so the user code can have a really easy interface for just initializing it, putting it on the display, and then checking if any keys were pressed and if so they can handle it however they want. That's kind of the first idea in mind for a soft keyboard that works on a touchscreen, but while I was kind of jumping into this, I also started wandering a bit and brainstorming about other ideas like an input that uses a D-pad to move a selection around kind of like old school NES or arcades might have that could open this kind of idea of entering configuration details for devices that don't have touchscreens as well if we had something like that. That one's much further down the road, but that is what I've got for this week. Thanks. Awesome. Sounds really cool. Next we'll hear from Jeff. Hello again. During our reports, I already talked about some of the stuff that I did last week, so if you wanted to hear about that you can skip back in the video or check the note stock. Coming up next is finishing the JPEG IO improvements that I was talking about. The other thing that I did this weekend was I created something that I'm calling the font bundle, which I said in a meeting a couple of weeks ago. I had the idea, but I wasn't going to do it well. I was bored yesterday. I did it. This is a separate bundle that has currently about 300, I think modules in it, one for each different variant of a font. Right now I've got mono sans and serif, which can be normal, bold, oblique, or italic, or both. You can just say from font sans oblique 72 import font and then use it with your labels. You don't have to worry about installing a TTF file. You just install it with circup. It will be a separate bundle, but we will be moving that under the Adafruit organization when it's ready. You'll have to circup, add bundle, and then you can just install these things. If you want to try it right now, you can add the bundle from my personal GitHub area, check the note stock for how to do that, but be aware that everything is subject to change. I noticed that some of the fonts were named incorrectly. Oblique versus italic, I think it's a distinction that's important for some people, and I got that wrong. Then the final thing is this is based off of a font family called Free Fonts, which is under a GPL license with a font embedding exception. I'm looking for a different font family that is more licensed, more in line with circuit Python, which we don't usually use GPL stuff. The other thing I did was I wrote an implementation of Glob in pure Python. It is in a GitHub gist, and there's a link to that in the notes document. I used this for a little font sample display program so that it could list all of the libraries. In regular Python, you do that with Glob, and a lot of folks have done things with os.listdure, but it's just so convenient to use Glob, so I wrote it. My final thing is a noncircupython thing, but with the Adafruit USB host feather wing being released, I want to go back and update a guide that I did. I believe it was during the summer, which was a CPM emulator. That one used two microcontrollers, one to read from a USB keyboard and the other to drive a HDMI or DVI display. I want to redo that with just the one microcontroller plus this new feather wing. That's what I've got going on. Just a note, I will be around this week, but basically that week of Christmas between Christmas and New Year's, I will not be around much. That's what's up with me. Thank you. Thank you. I'm very excited to use a font bundle. If there's one thing that drives me nuts working on a display project, it's trying to find a font and going through all the conversion. So thank you for working on that. Next, we'll hear from maker Melissa. Hello. So, let's see. I updated the quality of guide with some new displays. I updated the Arduino GFX library to handle the bar displays, but here are still being updated. I updated the Cercupython quality of library with the newest displays. I added some missing boards to Cercupython.org. I updated the BlinkLive GPIOD pen to work with latest version of GPIOD, which was version two. I'm continuing to look into the Raspberry Pi 5 oddities in BlinkLive, like SPI is not working still. So just on when you use the CE0 pen, for instance. And I'm also working on a project that is an IR remote controlled seasonal lights using Cercupython. That's it. Thank you. Now I'll read for Paul Cutler. New episodes of Cercupython show out today featuring Jan Gulsby, C Grover. We chat about Cercupython community bundle using SynthIO to create WinChimes and more. Looking forward to listening. And now we'll hear from Scott. Hello. So I have one more goal before him completely off for the holidays, and that's wrapping up this SD card support in Web and Bealey Workflows PR. It's compiling, and I think I've done all the code, so I just got to test it, which I'm sure I'll find bugs, but that's where I'm at. Over the holidays, I do want to submit a proposal to PyCascades for next year, because it's in Seattle. It's quite close to my house. It makes a lot of sense to do. And then I will also be kicking off Cercupython 2024 on New Year's Day as well. So keep brainstorming ideas for Cercupython in 2024. This is going to be a chance. We do it every year, but for those of you who are new, Cercupython in the year is kind of our chance for all of us in the community to kind of present more broad thinking about where you want to take Cercupython in the year or multi-year time scale rather than this bug or that bug or this small thing or that small thing. It's going to be a bigger sort of planning exercise for us as a community. So start thinking about that. And if you want to see what we did last year, you should be able to find it by just searching for Cercupython 2023. I know that's where I always start is looking back. So expect to do that in January. And I hope everybody has great holidays and enjoys their time with family. Thank you, Scott. And that was status updates. Next up is in the weeds. In the weeds is an opportunity for long-form discussions that either come up status updates or that folks have identified ahead of time. If you have any in the weeds topics, please make sure they get added while we're discussing other things. So we're not waiting around to see if anyone has topics. And we do have a topic today from Justin who is text only but is in the meeting. A follow-up from two weeks ago after playing around with things. He has come up with the following steps. Move socket specific code from request.session to request.sockethandler and there's a draft PR. Make request.sockethandler a singleton. Add some methods for better key socket handling and helpers like get open keys. Add tests for new methods and changes. Make sure docs look good. At this point, mark the above PR as ready for review. Update Adafruit ESP32 spy socket.py to Adafruit ESP32 spy socket pool.py. And since Adafruit ESP32 spy socket returns a fake socket pool, it would be easier to follow code with more correct naming. Update Adafruit circuit python mini MQTT to sockethandler in init and use it. Add something like sockethandler.lock socket which would make sure that you could always open a socket for a particular key. For example, io.adafruit.com 1883 MQTT so you can always connect to Adafruit IO. More update thoughts to come. I'm also happy to tackle issue 128 on circuit python requests and move the handling of fake SSL socket into socket handler for when is SSL is true and SSL context is none. And Justin, I'm not sure if there's things you want to add or if anyone else wants to discuss. Yeah, I'll just bring up. So I talked about this two weeks ago and kind of dug into things and this was basically kind of where I thought things could go and kind of as brought up last time I don't want to spend a whole bunch of time opening this crazy PR if this isn't a way that people wanted to go. All these steps are actually listed in the PR as well. So I think at this point would love just kind of feedback on that draft PR to see if this is a positive way to go forward. I can also draft out the one specifically for the mini MQTT. I've used that one. I've been able to toggle through a bunch of requests and things like that, not have, haven't had any issues or anything like that. Even took it to using DJ7 theories thing that originally brought up this issue going back a couple commits to where it was having some issues and it was kind of, for the most part, worked as his code was originally written with the bug without any issues, which was really awesome to see. So yeah, would just be curious. You know, there's anything people want to talk about here. I'm happy to or people can just go straight to that PR and look at it, make comments, check it out. However, people would like to do it. Go ahead. I was going to say is soccer handler a thing that the regular Python request library handles? It isn't. But at that point, when you are thinking of regular Python, there's really no, the limits are very different, right? So like on my laptop, I can have, I've had 200 plus sockets open at a time and it doesn't have any issues. It really becomes an issue when you're looking at microcontrollers and things like that. So I mean, I think I definitely feel like it may be a better as a third library, especially if MQTT is going to be using it too. And I do wonder if what you need out of it is better served by making soccer pool natively smarter as well. But yeah, I guess it just seems a bit far field for to take a fruit request that direction. Not saying you shouldn't do it. I'm just saying maybe not in requests. And the reason I put it there was one. So a big chunk of that code that got moved exists in a fruit request. So in certified on request, it also exists in many MQTT, right? So it's, it's the same code's been kind of copy and pasted everywhere. And I think lots of people make the complaints of, oh, now I got to import something else as well. And so it felt awkward to duplicate that code again, and put it in another library. And then the session one gets updated and things like that. So that's kind of why I took that approach. But again, happy to make it a third party or just write it out myself and use it when I need it too as well. So well, I think in the world I'm envisioning it's both a request and MQTT that use it. It just feels weird to me if MQTT is going to be using requests because I know that it's like not HTTP protocol. And we could just set you up with a repo for it. A third Adafruit repo as well is one way to do it too. So I think you're doing, I think what you're doing is right. It's like, we should give you more feedback on that request. We are involved in one place. And then if we decide to do it in a certain form, we can then put it out. Okay. That sounds awesome. And to reemphasize what Scott said also, if there's something that you want from Native Socket Pool that would be helpful in the API that would simplify things or make it easier, well, simplify things, then that certainly would want to consider that. Right. Yeah. Yeah, I guess I, yeah. I'll have to see what it's actually doing, but it might be better native as well. Because ideally we'd like you to be able to treat it as if you could do 200 sockets, but I know you can wrap in practice. Like another thing to look at, and I think we talked about those two weeks ago is just like figuring out like if we can raise those limits. True. I think the other part that makes it complicated and I don't know where this is going specifically is when you have things like, you know, one of the tests I did was, you know, with an M4 with an airlift feather on top, right, which doesn't have the native at that point socket pool. So it can't, right. So part of this was to support anything, right, that however you're adding your, you know, whether it's Wi-Fi or Ethernet or whatnot, which I assume is why it was originally built into requests and also MQTT. So well, it could be that the ESP through to SPI library should look even more like native Wi-Fi or look more like socket pool also because right now it's somewhat more ad hoc. I mean, we made it better. We made it more transparent, but it still has peculiarities. So, you know, I think our ultimate goal is to make it look, to make requests look, make it a fruit request look more like CPython requests and to make things that if a request needs to call on, look more uniform across the different ways of using it. So, yeah. So I, yeah, we did, we do have, as Scott said, we just need to review what you did. We're carefully and maybe if we have some ideas about refactoring to make it look more common, then that would be great. And we'll look at that. Yeah. And if you do look at the PR, one of my last comments was basically using the airlift feather weighing and an S2, basically the same way. You know, obviously the pools imported differently and whatnot and the SSL context is created differently. But at that point you're, you can just use it a fruit request session and things like that. The other part of making the socket handler as a singleton was at that point we would need to pass it in, which would make it look and act more like regular requests and things like that. So. Okay. Well, we'll look at this more carefully. Mostly I've been leaving it to the, to the request people to test, but this is, this is a lower level than that. So. Okay. Well, I will look forward to feedback. If I don't hear too much, I understand it's the holiday. If I don't hear too much over the holiday or whatever, I'll probably bring stuff back up in early January and, you know, if I can help move this along, I will. And if it seems like it's not something you guys want to do right now, I'm totally understanding that as well. Okay. Thanks. Awesome. So with that, I'm going to wrap up. This has been the Circle Python Weekly for Monday, December 18th, 2023. Thank you to everyone who participated. If you want to support Adafruit and Circle Python and those of us that work on Circle 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 will be available on major podcast services. It'll also be featured in the Python for Microcontroller newsletter. Visit adafruitdaily.com to subscribe. Now the next meeting is moved. We will not have a meeting next week and the next meeting will be Tuesday, January 2nd, 2024. This meeting is held on the Adafruit Discord, which you can join by going to adafruit.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 Circle Python thesis roll on Discord, and we hope to see you all next year. Thanks everyone and happy new year. Have a good holiday season.