Skip to content
TrackPodcasts
technologySep 29, 202633:17

#498 A Tiny Episode

Python Bytes

Get every episode summarized

Each time Python Bytes publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.

Email me new episodes

Free for 3 shows. No card needed.

About this episode

“This is unbelievably episode 498 coming up on episode 500 recorded September 29th, 2026. I'm Michael Kennedy and I'm Calvin Inderick's Parker. We put all the links if you want to interact with us there at the top of the show.”From the transcript

Topics covered in this episode:
Watch on YouTube

About the show

Sponsored by us! Support our work through:

Connect with the hosts

Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesday at 7am PT. Older video versions available there too.

Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it.

Calvin #1: MemTensor / MemoryOS PyPI package hijacked via a malicious build backend

  • On Sept 23 an attacker published backdoored MemoryOS 2.0.34 on PyPI and three bad versions (0.1.21, 0.1.23, 0.1.25) of MemTensor's OpenClaw plugin on npm. PyPI had no clean release that day, so 2.0.34 was the newest.
  • They pushed commits to MemTensor's own GitHub Actions release pipelines. On PyPI that was a custom Poetry build backend, and on npm a tweaked validation script. Both used BASH_ENV to hand the publish token to the attacker before the real publish ran. SafeDep couldn't confirm how the attacker got push access.
  • Runs on import, not install: A Go implant called sckit starts when the library loads, so --ignore-scripts won't save you.
  • It harvests credentials from your home directory (npm and PyPI tokens, GitHub tokens, SSH keys, cloud CLI tokens, .env files) and sends them to skyleen[.]fr servers.
  • It's a worm: It uses stolen tokens to copy itself into other repos and packages, so the victim list could grow.
  • If you installed it: Downgrade to MemoryOS 2.0.33 (plugin 0.1.20) and rotate every credential reachable from $HOME. Also kill any running sckit stage0 process and check repos you can push to for a stray runtime-update.yml workflow or .sckit/ directory.

Michael #2: TinyMongo

  • Want to use a MongoDB data interface, but swap out the storage engine?
    • Memory for testing/caching
    • JSON/TinyDB simple JSON files
    • SQLite for durable, high-perf reads with WAL
    • SQLIte shared for high write apps
    • DuckDB + Parquet for analytics apps
    • Postgres + MariaDB for multi-machine client/server
  • Great for teaching, examples, and simple deployments
  • Amazing story of paired AI development
    • Will completely run talkpython.fm after weeks of shared work together (in SQLite mode).

Calvin #3: Jev: what to know

  • What it is: Jev is a model from TypeSafe AI that answers with typed results (yes/no probabilities, scores, picks from your options) instead of prose. Real Python published a hands-on tutorial on 2026-09-24 and the buzz on hacker news is almost deafening.
  • It's proprietary: Jev is a hosted, closed-weight model. There are no weights to download and no self-hosting. Everything called "open Jev" is an independent reimplementation, not TypeSafe's model.
  • Your data leaves your machine: Every call sends your input text to a third-party API. In the tutorial that path goes through OpenRouter to TypeSafe. Think twice before sending customer messages, tickets or anything sensitive.
  • Cost and stability are open questions: The tutorial calls Jev "cheap, but not free" and says it's fast and cheap "at the moment." It also says whether that stays true is "something to keep an eye on."
  • Credit to Real Python: It's a good, practical intro. It shows the Noul, Score and Choice primitives, and its point that instruction wording matters more than thresholds is useful advice for any model. The tutorial itself says similar results are possible with a well-prompted LLM.
  • Open options to look at instead:
    • JevK5 (https://github.com/allebee/jevk5): Apache-2.0 weights and code, 4B or 9B parameters, and it accepts TypeSafe-style requests.
    • SemIf, formerly OpenJev (https://github.com/TheoLeeCJ/openjev): MIT-licensed, small models, and it can run CPU-only.
    • openjev-sglang (https://github.com/ekzhang/openjev-sglang): a Jev-compatible endpoint running Qwen3.6-35B-A3B, but no license is stated, so check before commercial use.
  • The catch: These copy Jev's interface, not its model or training. Results will differ, and I haven't run any of them. Benchmarks are self-reported, and JevK5 is English-only.

Michael #4: One innocent dict read makes attribute access permanently slower

Timofei Ivankov benchmarks a CPython internals surprise: since 3.11, attribute access skips the instance dict entirely. A specialized opcode reads the attri.bute at a fixed byte offset in the object's inline values array. Read obj.__dict__ once, though, and the dict gets materialized, the object loses that specialized path for the rest of its life, and a million-iteration loop goes from 33 ms to 51 ms on CPython 3.14. vars() and copy.copy() trigger the same thing, so a debugging print or a shallow copy in code touching your hot objects quietly makes every later attribute access roughly 1.5x slower.

  • The slowdown is permanent and nothing about it looks like a performance decision: ordinary code far from the hot loop can trigger it, and the function that gets slower never changes.
  • Materializing dict produces a split table, and the LOAD_ATTR_WITH_HINT fallback declines split tables, so the object ends up with no specialization at all
  • vars(), 'x' in o.dict, and copy.copy() all materialize it; copy.copy is the realistic trap since nobody treats a shallow copy as a performance decision
  • slots instances read attributes at exactly the same speed and cannot fall into the trap since there is no dict to materialize
  • On the free-threaded build both effects grow: atomic incref on reads plus an object lock on writes push the penalty from 17.6 to 25.4 ns
  • Credit: this item was surfaced by the PyCoder's Weekly newsletter

Extras

Calvin:

  • whatsnewt - a TUI text adventure through what's new in Python 3.15; playful but niche.

Joke: Shipping a button in 2026…

Hosts & guests

Transcript ready

653 searchable segments. Every word is indexed and playable.

#498 A Tiny Episode

Python Bytes

0:00
33:17

Full transcript

Python Bytes — #498 A Tiny Episode. Machine-transcribed; use the interactive transcript above to jump the player to any line.

Hello and welcome to Python Bites where we deliver Python news and headlines directly to your buds. This is unbelievably episode 498 coming up on episode 500 recorded September 29th, 2026. I'm Michael Kennedy and I'm Calvin Inderick's Parker. Check us out on all the socials. We put all the links if you want to interact with us there at the top of the show. The subset is brought to you by us. So be sure to check out six feet up if you have an amazing you would like. Who've done a lot of problems solving the Python space for many, many years reach out to Calvin and when learning about Python, got some courses over at talk Python and new things coming, not nothing to announce yet, but a lot of a lot of work has been going lightly on a new thing over there. So I'm very excited. Check out the newsletter, just visit homepage like newsletter. We got lots of cool things to send to you there. And with that, you've scary news. Are you going to scare us? Hopefully not too much. It's not it's not quite October, although I do see lots and lots of decorations out in the stores these days for Halloween.

But there is a good jump scare, right? It little bit. Yeah, there's been a supply chain attack and there's no shortage of these over the last couple of years, probably due to the proliferation of AI and the tools that attackers can use to build these, these different exploits. This one is around MimTensor and memory OS. So some people may not be affected by this, but I think the real true story here is to follow how it's done and to protect your CI pipelines ultimately. So on September 23rd, an attacker published a backdoor into memory OS. So if you're using open claw or if you have installed a memory OS skill into your agentic harness, it could be susceptible to this. So look for these various versions, 0.1.21 on the plug-in. That's the bad versions and 0.1.23 and 25. And then the memory OS version 0.2, sorry, 2.0.34, the newest one that was released last week.

Those are problematic. They are going to launch a go process in the background, even working around like the import path stuff won't get around this because it will launch this. What looks like a legitimate named thing SCKIT. You may miss, view it as scikit, but it's actually SCKIT gets a go library, the loads in the background and what it does. Scalars your system for credentials, post them to a command and controls are kind of the standard play there. And then it attempts to inject itself into other CI pipelines as a worm. So this one's not just an exploit that's going to exaltrate your credentials. They're actually looking to exaltrate them, exploit them and then turn them into a worm to gather more and more of them. Whatever project you're basically working on. So it traverses your home directory looking for Pi PI tokens, GitHub tokens, you name it and it sends them to a nefarious server someplace. Those then locate itself and try and go again. So if you are on the these various versions of these various packages,

make sure you downgrade to the safe versions, those 2.0.33 of memory OS and O.1.20 of the plugin and rotate every possible credential. You have this reachable from your home directory. Make sure you kill any SCKIT processes that are running because that is where it is talking to the command and control server. So unfortunate news, no fun. The right up from safe depth, which is linked to from the show notes here has a really good take on basically how they got in. They're the couple spots where they don't know how they got some of the tokens. They assume maybe social engineering or a leak of a GitHub token someplace. But the the various projects have put in some fixes into their CI pipelines to hopefully prevent future attacks like this from happening. And you probably could learn something a thing or two for your own CI pipelines to harden your processes as well. That is a jump scare. Yeah, I don't like it. Less than fun. No one no one loves to hear that news on a Tuesday morning.

But I think everyone needs to be aware and protect their CI pipelines because that again, this is how they got in. They basically use the GitHub actions pipelines, not the GitHub actions is in itself vulnerable to these things. It just enables these kinds of things. It's the other practices that are what made this possible. I remember how scary it was that there were worms on the internet, especially back when firewalls was a firewall. That's what company. That's what giant companies do. Yeah. So there's on the web page, they also link into the issue from the memory of us folks and the open club login repositories. Again, I think it's a good response right up of what happened. The repositories themselves don't have a lot of information on them, but this article does. Yeah, it's just it's scary, you know, having very cool what we can do as developers, but at the same time, the responsibility of, oh my gosh, something, something got through and it didn't just affect me. Yeah, it's just affect my users, but everybody who might have used something I created now, it's like taking over all of their music.

Oh my gosh, that's a serious fire. I mean, it's a common complaint like why can't we just dump files into a webber like we used to and deploy CGI applications? Well, because that was very dangerous, we just didn't know it yet because of the various vectors for exploit and attack. Deploying software safely requires a thoughtful and intentional process. Yeah. And to some degree, safety and isolation of your computer that makes that software. Very true. So yeah, pay attention to the sandboxing and containers and things like that that help you with those processes. Would you say you got to pay attention to like tiny little issues? Tiny things could be an interesting way to go. I want to talk about tiny manga. Are you familiar with this? I am not actually I'm quite curious. My son actually was in a MongoDB hackathon over the weekend. So maybe he might just would have been absolutely. Yeah, awesome for that. I mean, maybe if it was about MongoDB, no, but I've covered this before actually gives me a chance to highlight a cool little search feature of our if you search for them, you can actually say only show me the episodes that exactly covered this.

So way back in 2017, nine years ago, we covered tiny Mongo. So the guy behind this Stephen, I had posted way back when I posted some issue saying this thing is cool. So let me tell you what tiny Mongo is. And then I'll tell you the why it's back on the show after nine years. So tiny Mongo is what SQLite is to Postgres tiny Mongo is to MongoDB in process local file, but it goes. It goes a little farther than SQLite as you'll see and some really interesting ways, but it uses well known durable back ends for the most part. So you you can choose a really well known well tested well trusted again for this. But basically think in process, I want something without a server now as part of this news item is very, very fast. So Stephen reached or Stephen looked at this get up issue and decided, all right, I'm going to fix it. So the issue I filed while ago was this is really cool. It supports a subset of MongoDB, but not enough.

Okay. So I was using when I posted the issue, I think I was using Mongo engine. When he replied to the issue, I was using what was it using a gigantic base one, Bini. And then by the time he actually got got the thing working, I was using just raw MongoDB queries, but I said, look, this is cool, but I can't use it with anything based on these ORMs because the ORMs have a certain set of like startup things they do like ensure these collections exist, ensure this index exists. You know, it's like testing different things as just part of the standard setup you set up, you know, like it scaffolds the index automatically and stuff. And those things weren't working. So I said, would you be willing to put in enough structure, maybe even if there are no ops that I could actually run a quote real application on top of tiny Mongo? Because there's all sorts of cool reasons you might want this. Like if you're doing a tutorial or a workshop, you don't want to have to start out and go now kids. The first thing we're going to start is by setting up a network server and securing it. Like, no, no, I just want.

Yep, there goes the day. You're like, okay, well, we're not doing the workshop anymore, right? Like, but if you have something like SQLite, you can just say, this is the connection string. This is the UV pip install command. Now let's keep going. And it's, but it's the same program. You just change the connection string basically to get like a real server, right? Like to switch over to real Mongo or whatever. So Stephen took that idea and just totally ran with it and came back to me and said, hey, look, what do I need? How about this? You know, this, this last question was asked in the time of AI, the time of really smart coding agents. There's the before times and there's now. Exactly. So I think this actually represents a really super interesting collaboration between me and Stephen. So, Stefan, sorry. So he said, well, what do I need? So we'll have about this. Why don't I just see if I can get talk Python to run on top of this just as it is. And I just said, all right, well, I'm going to take Mongo out. I'm going to stop talking to the real Mongo and I'm going to put tiny Mongo in and get it to run.

And there were all these issues like, yeah, it technically works, but this thing is a thousand times slower in this way. Is it okay? I wasn't expecting that. Yeah. Well, it almost worked. And once we got it working, it was like, okay, now it works, but it's like these five things are insanely slow. Or this, this type of query is not actually supported or limit doesn't actually limit it in the DB. It pulls it all back and then it like limits it in memory. You know, those kind of weird little, like it's fine, but if you've got hundreds of thousands or real data records, you're like, no, this is not going to fly or this is out of control. So we went through all those. And now it's, it's like really quite close to MongoDB performance. Michael, would you recommend this for production usage or is it still more for exploring, playing, teaching? I would recommend it. I think it's safe. I don't, I'll tell you why. I'll tell you why. I think it's, I would recommend it. If you would consider SQLite as your back end for production, which I think actually, I think that's very, very, very, very safe. I think that's very safe. It has restrictions on like parallel writers and stuff, but I do think it's quite safe.

I agree. If you would consider SQLite as a back end, then I think this, I would recommend this as a back end. Yes. As, as we'll see. Okay. So let's go. To the, I mean, the way, what's cool about it is the way you write is you just like write regular code and just import tiny Mongo as pi Mongo, which is the, the bait, like the standard way of creating a thing and you give it, you know, a connection string sort of deal that is like this file instead of this database. And then you just write regular queries against it. All right. So what's really neat down here somewhere is they all the different back ends it has. So like SQLite, it might probably even use the SQLite version for this. I'm not sure is you have an in memory version. So it never even writes the disk like I'm doing unit tests or I'm just firing up this code. This data might think about it and then throw it away, right? That's pretty cool. It has this JSON back end, which is it's sort of default way. I haven't done it. This was not really able to totally solve the talk Python runtime. I think or it was like two slow or something, but switching to SQLite.

So basically it uses SQLite with all of the SQLite transactions, right ahead log stuff and all that kind of stuff. And that's a really good production story. And then look at this Calvin sharded SQLite. I'm more curious about the next one, which is duck DB. Yeah. And so so you're going to ask yeah, because there you got real JSON support possibly. Yes, definitely a huge fan of duck DB. Nice. And those kinds of things. So this is duck DB and parquet files as the back end, which is pretty interesting. So if you're doing data sciencey things and you were doing mango type of queries, this, this is the way. This is a pretty good one. And then also it has a way to say like you know, point that over at Postgres and Marina DB. If you'd rather have something that's I like mango, but you don't actually run mango. I mean, you literally talk to it as if it was mango. Yeah, I'm unsure about that use case. Think of I just run mango. I would too. I would totally too. But I think the SQLite one really good. We got it really, really dialed. So I actually linked to one of the issues. There's a bunch of issues over there.

So I had some issues, Stephen added them and sort of referenced me and we just went back and forth. And I would say, Hey, Claude, I'd open up. I had a branch for talk Python. I'd open it up and said, Hey, Claude, check out this GitHub issue. Can you, can you trying to do implemented on top of this thing? You would do it. And so well, I found all these issues. I said, okay, file some issues. Then Stephen would have codex look at it, fix it up, reply. And I would just, we would just like pass it back and forth. And the reason that's interesting is I'm not giving him the talk Python code base. And I ended up running on talk Python training, which is like 300,000 lines of Python code and got it working there as well. But I'm not giving him that code, but he was able to literally prototype both from performance and correctness perspective, running on both those code bases by just bouncing back and forth. Well, my AI did your spike and it did. It found that it ran like this and this worked and this didn't. And so, okay, I fixed this, tried again. We just went back and forth for like over and over for days and got it really, really dialed. And I thought that was that that itself is worth covering here.

Yeah, like the word the phone. Yeah. Yeah. It's very interesting. Obviously my prompts were like, you will not put any proprietary information, any secrets, any source code example. You will put all generic, you know what I mean, but at the same time, it totally worked. And it was, it was really cool. But I think this, this is a super interesting thing because until this recent work, this version one dot three dot one that got released, there was no sequel light equivalent for MongoDB. And now I think they're legitimately yes. It's not 100% coverage, but it's, it's quite high. It runs multiple real time apps. Yeah, like that. Well, especially for the education market, being able to teach someone really quickly without having to install and serve. And that's a huge barrier for a lot of people. Yeah, it looks really good. I'm really excited about it. Thank you, Stefan, for doing this work. And there might be a follow up at some point as well. And what a great like story for open source. Yeah, exactly. Like a really cool way to get some actual hands on experience on real projects by sort of ping pong in.

Get up and choose back and forth. There's crazy. Speaking of crazy. I heard this, this, this is the top of this topic is set in the world on fire. Well, and I wanted to bring it to light to get some people some exposure to it. If you've not heard of Jev yet, you're probably living under a rock someplace. And that's okay. But the folks over real Python did a tutorial over how to get started with Jev and Python. For those of you who don't know, Jev is a model from a company called type safe AI that answers type results like yes, knows, probabilities, scores and pick from options instead of you talking with it. So you don't chat with Jev. You don't come into Jev and say, hey, build me an app or tell me a bear story or whatever the thing you may want. Propose to Jev sets of information, evaluation, the kind of result you want. And then Jev can in parallel evaluate those things either scoring them, giving them yes, knows. I mean, the docs from the tutorial are basically a customer service example where the customer says,

I've tried contacting support like three times. Can I please get escalated? And so then the Jev for that basically is, here's how you know if the person is telling a truth or not. So they have a yes, no or true fall. And there's some custom various data types to go along with it. So what's nice is that the real Python article will get you started with Jev. So you'll understand the data types. You'll understand like what Jev's about that you can't just chat with it. But I think the buzz is real. Like I've heard tons and tons of people talking about it. Looks like the invites are back open again. I was actually able to sign up for Jev this morning and try it out. But it is proprietary. Jev is a hosted closed weight model. There are no weights down there. There's no self hosting of this thing. Everything called open Jev is an implement is an independent implementation and not type safes model, which means your data leaves your machine. So I don't know how much you trust type safe AI who we don't know. I don't know who they are where they're posted. What their business models are. Obviously, it's not free.

You have to use you have to put a credit card down to use this model and try it out. But every call sends your input to the text input text you put in there to a third party. So be careful. Like much like you just mentioned how you were sanitizing your inputs for working back and forth on the tiny Mongo project with Stefan. Be careful what you send into this one because you don't control it just as much as you control what you send to Anthropic or OpenAI. Those are pretty well established companies with a good business model and they seem to be running on credibility and reputation. You have to do your research and know what you're going to be sending over there. So think twice before sending customer messages, tickets are any sensitive. The other thing is like costs and stability are a question. So basically, Jev builds themselves very cheap and it is very cheap. You can and very fast. You can have it sort through. I heard someone tell me an example. Like look through my inbox of a million messages. Categorizing them for like needs immediate attention is about a customer, etc, etc.

and it can build you a table and sort that table in just milliseconds. It's that fast. I want to give people an option here. It's a good practical intro. It shows how to use the null, the score, the choice primitives. But there are open options out there. I know I keep caviating this like episode. This section of the episode. There are some open options to look at instead. For example, Jev K5. It's an Apache 20 licensed weights and code. So that's kind of my front runner right now. I've not tried it. But it does accept type safe style requests. These are API compatible, but they are not the Jev model. So you're going to get different potential results. There's also one called SimF, which was formerly called Open Jev. I'm sure lots of take down notices came flying back and forth. There's all these alternatives came out that were also called something, something Jev. Another one's open Jev SGLANG. Again, the catch here is these are not the Jev model. They are close. There was actually a really interesting Jev in 25 lines of Python,

a little bit tongue and cheek post that also came out about this. But what they did here was use the Quinn 3 model and told it to act like Jev. And for most things, I think it gave reasonable results, but also at the very end. This was a real tongue and cheek post, the kind of poking fun at the hype that is Jev right now. So I wanted to put that out there for folks to be just mostly aware of the fact that you're sending your data to a proprietary company. And be careful what you're sending to it. Unless you totally trust it and have a business agreement with that organization beyond putting your credit card into a credit card field. So I hope folks are vigilant as they go forth and try these things. The hype is real. Oh my gosh, you couldn't, again, move last week without hearing about Jev. In some meaning, in some some article and some some topic. It's a very interesting way and a very interesting usage. It's a very, I think it's a great, great pattern for reducing token spend and usage on other models and collaboration

and combination with other models. But you need to understand what it really means in action. It's, it's a super cool thing. You're right. It's absolutely blowing. Jev was blowing up. I'm, I had to watch some YouTube videos. Right. I'm missing something because there's a lot of this thing I've never heard of going on around and around. But when you sign up for a Jev account, it makes you take a pop quiz to ask you whether or not you can chat with Jev. I won't give you the answer because if you keep you don't know, you shouldn't probably be using Jev. If you got to ask, it's not for you. Yeah, I was going to say that there's never been a time, I think, where we're sending as much detailed information to other companies and other places as the last couple of years. Mm-hmm. Be careful out there, folks. It's, it's, it's real. Yeah. The reason we're doing this is because it's so productive and so useful, right? It is. I mean, the pattern. I think in looking at some of those open-weight options, there, if you can put in place, again, I'll stress, otherwise, stress thing, last week was around eVals. Building good eVals for your CI pipeline to run against these models,

whether they're classifiers like Jev or whether they're LLMs, like the Quinn or other open-weight models, means you can swap back and forth with confidence. And if you can do that, you can use one of these open-weight models, open source, even versions of these models with more confidence on your own GPUs. These things will run on even very small CPU GPU. I think there was a Quinn 306B model that they're using in the parody article. That runs on it, like a Raspberry Pi. You can get those anywhere. Nice. But I'm not using Anthropic for something. I've been using the GLM53 Flash, and that's been super, super neat. But I want to talk about an age of innocence that may be over here. This is an article. I don't typically cover articles, I typically more. But it kind of pulls out. It highlights a really important thing that the reason I pull it up is because it kind of broke my understanding of Python performance tips if for one particular axis. So, this is by Timothy Ivankov. So, cool to write this up. I think it might have had a little writing help, but that's okay. So, here's the headline.

It's reading dunderdicked once one time. Reading dunderdicked of an object permanently de-optimizes attribute access. What? Why is that? Why is that not good? I also wonder which point of this comes from PyCoder. The permanence of it is the striking bit. Permanently, for the rest of that object's life cycle, its performance is broken. Okay. So, here's an old performance tip. And I'll tell you the one that I used that I thought was amazing. And it was amazing. If I have a loop and in this hot, let's call it a hot loop here, there's just an example. A million times the framework is going to do the same thing. We're going to say creating an attribute, self-dot value, access self-dot value, in the loop increment plus equals on the self-dot value. Well, traditionally, that would go into the dunderdicked, find the value, pull that value out, change it, store it back into the dunderdicked. That was the backing store for its fields, which was weird, but that's how it worked. So, here's what you do. Instead of doing that interchange over and over and over, do it on a local variable.

Pre-value, do all your work on a local variable in the function, and at the end, set the value to the class. Right? Pre-value then eventually say self-dot value equals value. Right? Super simple. That used to make a big, big difference. And now, it does still a little bit, does a little bit, so it technically works. However, if you do this enough times, it turns out that the new specializing adaptive interpreter notices that and it drops the load adder, which is the byte code instruction that reads the field from the dictionary. Eventually, it drops it and it starts processing it different. Right? And so, what it does is it actually starts to look at, just where in the offset, like a fixed byte offset into the objects storage for this, which is like, wow, okay. Pretty cool. So that's, I think, since 13, really interesting. And you can see the different aspects. It turns out that it's even more significant, the change of the problem

that's suggesting or pointing out or that's not really a problem. It's just a breaks an optimization. That the breakage is stronger in a free-threaded world and the article goes into why. So check this out. If you just say, like maybe this is like a debugging thing or whatever, you just say print, dunderdict of the object, and then you go have that function run. All of a sudden, it's 50 milliseconds instead of 30 milliseconds. 1.5 times slower. What do you think? It's intense to get down to that level. It is, but there's a bunch of little simple things that you're like, what, you know, I could read the fields or I could just say star star dunderdict and do this in that. And it turns out that that actually, it didn't used to make any difference. But because of the specializing adaptive interpreter, now it does. Right? So like if you just ask bars of an object or if you ask if a field is in the dictionary, well, here's the really tricky one, a shallow copy. All right. Well, that's totally a reasonable thing. I'm going to make, I'm going to clone this before I hand it back or something.

Well, that clone that you did, it can actually be accessed. It can access it. Yeah, it makes it 50% slower. I've definitely done that. Mostly when I'm debugging your triaging code or kind of walking through with the interpreter, because it's easy to access. I can't. Yeah, I get to many times where I would have tried to do it in code. You could see how it's an easy workaround. It's like, oh, it's just right there. I'll let her reach for it. Yeah, exactly. So these, the first three are kind of debugging ones. But this last shallow copy, this is the legitimate thing, right? That you might do. And so here's the, this is the part that I didn't get because the world has changed. And I haven't been like, sort of typing everything at that level. I'm a big fan of dunderslots. It means you can't dynamically add stuff to your class. But more importantly, used to mean that this whole dictionary mechanism was no longer used. And it basically used an offset into a list that was just in each instance. So it honestly made things a lot better in terms of memory. Yeah. In terms of attribute access was significantly faster.

Well, apparently, slots makes no difference anymore. Yeah. Because the specializing adaptive interpreter, at least in this use case, right? This is like a, I'm accessing the same thing a lot of times, right? It could be a profile lens tricky performance is tricky. But basically the specializing adaptive interpreter for hot pass slots versus not didn't really matter. And I didn't know about slots until I read Luciano's book, fluent Python. That's where I discovered that. And now he's saying it really doesn't matter anymore because of the new bits in there. Yeah, exactly. So I believe I might have learned about it as well from Luciano's book. So yeah, 311 and beyond. There's a lot of the faster CPython thing, change some of these things. And it changed how this, especially with the specializing adaptive interpreter, changed a lot about how this dictionary and access, and that's that's a whole story. Slots, dictionary access, optimizing or not optimizing it. And so I thought this was an interesting dive into something that's, you know,

everyone uses classes objects. Even if they're not big, oh, the folks, you still create objects. I mean, do you have a number? You know what I mean? Well, it's just, and it's convenient. But I think if you were, again, performance debugging, triaging, and you ran into this, you've been surprised. Yes, I would certainly say so. I would say so. Michael, would you want an interesting way to find out what's new or what's new in Python? So I get this extra here. I wanted to share. This is cool. I've seen this now. I thought I had Nazi. I've seen this is cool. Okay. This is like, it's a dungeon crawler called what's newt. And it, but what it does is it runs you through the what's new in Python. And this, this version is specific for 315. So you can't run it with prior versions because it actually uses the features in 315 to check that you've completed the challenge in the dungeon. So I've got the dungeon up right here. So I'll just read off real quick. So this one starts off with the first room of the interpreter and the one nobody sees.

Slips a paper are wedged into every crack of the machinery. PTH files hundreds of them each one adding a directory to the path. A few begin with the words import. And those have scorch marks rightfully so a brass plaque is bolted to the wall. A new file sits on the lectern beneath it. Unwritten. And so at this point, you have a puzzle, which is what runs before your program does. And it has a link actually in the terminal. That is a hyperlink. It's a nice little TUI app. And when you click on that, it'll open up the related pep to basically give you a hint for it. So if you want to solve it, you just type solve. By clicking here, I'll type solve. It'll open up an editor. First time to kick my butt because it does not have VI key bindings in there. So I have to use my arrow keys. You probably had to almost just like a caveman. And so based on the pep829, it added in the new namespace. A callable syntax for bringing in a callable into your KTH file or the new sys.path, for example.

So the deprecating the word import. And now, 315 ends this file format that can only name a callable. Here's how you write it. And when you click check, it's like solved. A reader can now see what starts up without executing it. The site modules batches every static sys.path extension first. And then only runs the start of callables so that a dot start file can rely on the path being complete. Police press enter when you're finished reading. And then it takes you into, do you want to go north, south, east, west, on your journey and learn more and tracks your progress. So you can see what scores I've gotten, how many puzzles I've solved. This is fun. If you go east, it's a very lazy path. Yeah, so that's super fun. I've not spent enough time reading the what's new in newer versions of Python. Kind of like you alluded to in the last article. Because we just use Python. And a lot of times I'm not leveraging some of these new features, but this is a fun way to learn what they are. I've very I've done that in there. Oh, it is very fun. This is from Barry Warsaw, right? I believe so. Uh, that's a good question. I did. I believe so. What's new?

It is. You're right. It is Barry Warsaw. Yep. Good job, Barry. Nice work, Barry. I love it. I'm here for it. And especially with the hype around dungeon crawler carol right now, this is a very appropriate. Briefing back to the days of buds. I used to get them. Yeah, to use your dungeons. I mean, my friends, we would spend tons of time in these places back in high school. People got to remember when I was in high school, there literally was no web. Not like it was bad. We're dying. We're throwing wide web. I know the whole thing was created in 1993 when I was in college. So before that, you're like, well, we got tell net. What are we going to do, folks? Yep. Muds. That's what we're going to do. We're going to use go for a lot like this. Yeah, go for Archie. Yep. Tell net. Oh my gosh. News stories. Like, yeah, you should newsreader out. What's so ironic is it was so amazing and it seems so futuristic. I bought things off of news groups, like going in through town net and then getting the news groups and I bought an expansion card for my HP 48 GX.

Correct. All right. Well, from the past to the future, well, to the present, which feels actually, I'm about to tell you about the future. Things used to be so simple. You mentioned throwing just a set of files to a folder and maybe buying a C panel so you can add them in your website. I don't know. Well, that's almost two modern for me. A C panel. Yeah. Yeah, just FTP. I'm sorry. Not even SFTV. Just straight up. Straight up. Just open. FTP. So I want to come back and do one more, Kyland, Lintit. Because I couldn't help myself, Calvin. I saw, oh my god, I saw. This one when we talked about the big data video. So here's more homework for folks. This is the perfect encapsulation of just how stuff gets so complicated for such a simple thing. So here's this, this 10 minute video tells the story of multiple many personas throughout that we experience as software developers and data scientists and so on. Trying to build tools.

Just a simple thing. You know, it starts with, okay, I need you to build a dashboard with a single button that does, I don't know, you know, whatever the button does, right? Pretty soon there's this guy over the shoulder and says, what are you doing with a regular database? You need a graph database because I don't need a graph database for 200,000 because users, he goes, what if we had 200,000 and one users, he goes, gosh. His delivery is genius in this one. It's so good. So good. My highlight was the pearl guy. Pearl, pearl, you know, devil shows up on a shoulder. Yeah, it does. Yeah, there's this, this other guy is like, well, we need a DDD, you know, domain-driven design-bounded context for the button. We need Docker builds for the button. It just goes on and on and just, oh, it is absolutely good. And the pearl guy, somewhere farther it is like, I could have built this with a single pearl script and a cron job back in, you know, whatever.

But you portray them perfectly. I mean, if you've been around any amount of time in this world, you're gonna laugh. Yeah, yeah, yeah. It's so good. So everyone, I leave you with a delightful, too realistic look at how software is built these days. Yeah. Well, this was really, really a good episode, Calvin. You knew. What do you say? Yeah, catch you later.

More episodes

More from Python Bytes

View all episodes →