Podcasts about PyPy

In this episode, Pablo's avoiding the topic of garbage collection by talking about his latest PEP, which allows unprecedented interaction with a running Python process. We also resolve the bet about reference counting semantics, mention some notable changes in Python since the last episode, and discuss syntax highlighting in PyREPL and why it's bad, actually.## Timestamps(00:00:00) INTRO(00:02:16) PART 1: PABLO'S LATEST PEP(00:04:34) gdb is IMPOSSIBLE(00:12:49) Make the process run code for you(00:14:14) This already works on PyPy(00:15:13) How does it work?(00:25:38) Why a file?(00:31:15) What if you don't trust Pablo?(00:32:57) sys.remote_exec()(00:36:09) Less obvious use cases(00:46:56) PART 2: BETS(00:55:44) PART 3: PR OF THE WEEK(00:55:50) Łukasz: syntax highlighting in PyREPL(01:10:14) Pablo's PR: allow the parser to activate future imports on the fly(01:20:11) PART 4: WHAT'S GOING ON IN CPYTHON(01:20:22) Free threading(01:23:30) Performance(01:34:41) PEP 765 implemented(01:36:08) concurrent.futures.Executor.map(buffersize=)(01:36:57) io.Reader and io.Writer(01:38:40) Pabluco's linecache fetching interactive source code(01:41:25) ast.unparse() roundtrip with semicolons(01:41:59) OUTRO

An airhacks.fm conversation with Christian Humer (@grashalm_) about: early programming experiences with DOS text Adventures and Captain Comic, transition from graphics design to computer science, work on Java Server Pages (JSPs) and point-of-sale systems, development of Swing GUI for touchscreens, introduction to GraalVM and Truffle framework, ActionScript, Adobe Flash and Adobe Flex, explanation of Futamura projections and partial evaluation in Truffle, discussion on the challenges of implementing dynamic language runtimes, de-optimization in JIT compilers, Nashorn JavaScript engine vs. GraalJS, language interoperability in GraalVM, reuse of libraries across different programming languages, embedding of JavaScript and React in Java applications, comparison with PyPy in the python ecosystem, current work on bytecode DSL for generating bytecode interpreters, the importance of math in computer science and its relation to programming concepts Christian Humer on twitter: @grashalm_

Applications for the 2025 AI Engineer Summit are up, and you can save the date for AIE Singapore in April and AIE World's Fair 2025 in June.Happy new year, and thanks for 100 great episodes! Please let us know what you want to see/hear for the next 100!Full YouTube Episode with Slides/ChartsLike and subscribe and hit that bell to get notifs!Timestamps* 00:00 Welcome to the 100th Episode!* 00:19 Reflecting on the Journey* 00:47 AI Engineering: The Rise and Impact* 03:15 Latent Space Live and AI Conferences* 09:44 The Competitive AI Landscape* 21:45 Synthetic Data and Future Trends* 35:53 Creative Writing with AI* 36:12 Legal and Ethical Issues in AI* 38:18 The Data War: GPU Poor vs. GPU Rich* 39:12 The Rise of GPU Ultra Rich* 40:47 Emerging Trends in AI Models* 45:31 The Multi-Modality War* 01:05:31 The Future of AI Benchmarks* 01:13:17 Pionote and Frontier Models* 01:13:47 Niche Models and Base Models* 01:14:30 State Space Models and RWKB* 01:15:48 Inference Race and Price Wars* 01:22:16 Major AI Themes of the Year* 01:22:48 AI Rewind: January to March* 01:26:42 AI Rewind: April to June* 01:33:12 AI Rewind: July to September* 01:34:59 AI Rewind: October to December* 01:39:53 Year-End Reflections and PredictionsTranscript[00:00:00] Welcome to the 100th Episode![00:00:00] Alessio: Hey everyone, welcome to the Latent Space Podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co host Swyx for the 100th time today.[00:00:12] swyx: Yay, um, and we're so glad that, yeah, you know, everyone has, uh, followed us in this journey. How do you feel about it? 100 episodes.[00:00:19] Alessio: Yeah, I know.[00:00:19] Reflecting on the Journey[00:00:19] Alessio: Almost two years that we've been doing this. We've had four different studios. Uh, we've had a lot of changes. You know, we used to do this lightning round. When we first started that we didn't like, and we tried to change the question. The answer[00:00:32] swyx: was cursor and perplexity.[00:00:34] Alessio: Yeah, I love mid journey. It's like, do you really not like anything else?[00:00:38] Alessio: Like what's, what's the unique thing? And I think, yeah, we, we've also had a lot more research driven content. You know, we had like 3DAO, we had, you know. Jeremy Howard, we had more folks like that.[00:00:47] AI Engineering: The Rise and Impact[00:00:47] Alessio: I think we want to do more of that too in the new year, like having, uh, some of the Gemini folks, both on the research and the applied side.[00:00:54] Alessio: Yeah, but it's been a ton of fun. I think we both started, I wouldn't say as a joke, we were kind of like, Oh, we [00:01:00] should do a podcast. And I think we kind of caught the right wave, obviously. And I think your rise of the AI engineer posts just kind of get people. Sombra to congregate, and then the AI engineer summit.[00:01:11] Alessio: And that's why when I look at our growth chart, it's kind of like a proxy for like the AI engineering industry as a whole, which is almost like, like, even if we don't do that much, we keep growing just because there's so many more AI engineers. So did you expect that growth or did you expect that would take longer for like the AI engineer thing to kind of like become, you know, everybody talks about it today.[00:01:32] swyx: So, the sign of that, that we have won is that Gartner puts it at the top of the hype curve right now. So Gartner has called the peak in AI engineering. I did not expect, um, to what level. I knew that I was correct when I called it because I did like two months of work going into that. But I didn't know, You know, how quickly it could happen, and obviously there's a chance that I could be wrong.[00:01:52] swyx: But I think, like, most people have come around to that concept. Hacker News hates it, which is a good sign. But there's enough people that have defined it, you know, GitHub, when [00:02:00] they launched GitHub Models, which is the Hugging Face clone, they put AI engineers in the banner, like, above the fold, like, in big So I think it's like kind of arrived as a meaningful and useful definition.[00:02:12] swyx: I think people are trying to figure out where the boundaries are. I think that was a lot of the quote unquote drama that happens behind the scenes at the World's Fair in June. Because I think there's a lot of doubt or questions about where ML engineering stops and AI engineering starts. That's a useful debate to be had.[00:02:29] swyx: In some sense, I actually anticipated that as well. So I intentionally did not. Put a firm definition there because most of the successful definitions are necessarily underspecified and it's actually useful to have different perspectives and you don't have to specify everything from the outset.[00:02:45] Alessio: Yeah, I was at um, AWS reInvent and the line to get into like the AI engineering talk, so to speak, which is, you know, applied AI and whatnot was like, there are like hundreds of people just in line to go in.[00:02:56] Alessio: I think that's kind of what enabled me. People, right? Which is what [00:03:00] you kind of talked about. It's like, Hey, look, you don't actually need a PhD, just, yeah, just use the model. And then maybe we'll talk about some of the blind spots that you get as an engineer with the earlier posts that we also had on on the sub stack.[00:03:11] Alessio: But yeah, it's been a heck of a heck of a two years.[00:03:14] swyx: Yeah.[00:03:15] Latent Space Live and AI Conferences[00:03:15] swyx: You know, I was, I was trying to view the conference as like, so NeurIPS is I think like 16, 17, 000 people. And the Latent Space Live event that we held there was 950 signups. I think. The AI world, the ML world is still very much research heavy. And that's as it should be because ML is very much in a research phase.[00:03:34] swyx: But as we move this entire field into production, I think that ratio inverts into becoming more engineering heavy. So at least I think engineering should be on the same level, even if it's never as prestigious, like it'll always be low status because at the end of the day, you're manipulating APIs or whatever.[00:03:51] swyx: But Yeah, wrapping GPTs, but there's going to be an increasing stack and an art to doing these, these things well. And I, you know, I [00:04:00] think that's what we're focusing on for the podcast, the conference and basically everything I do seems to make sense. And I think we'll, we'll talk about the trends here that apply.[00:04:09] swyx: It's, it's just very strange. So, like, there's a mix of, like, keeping on top of research while not being a researcher and then putting that research into production. So, like, people always ask me, like, why are you covering Neuralibs? Like, this is a ML research conference and I'm like, well, yeah, I mean, we're not going to, to like, understand everything Or reproduce every single paper, but the stuff that is being found here is going to make it through into production at some point, you hope.[00:04:32] swyx: And then actually like when I talk to the researchers, they actually get very excited because they're like, oh, you guys are actually caring about how this goes into production and that's what they really really want. The measure of success is previously just peer review, right? Getting 7s and 8s on their um, Academic review conferences and stuff like citations is one metric, but money is a better metric.[00:04:51] Alessio: Money is a better metric. Yeah, and there were about 2200 people on the live stream or something like that. Yeah, yeah. Hundred on the live stream. So [00:05:00] I try my best to moderate, but it was a lot spicier in person with Jonathan and, and Dylan. Yeah, that it was in the chat on YouTube.[00:05:06] swyx: I would say that I actually also created.[00:05:09] swyx: Layen Space Live in order to address flaws that are perceived in academic conferences. This is not NeurIPS specific, it's ICML, NeurIPS. Basically, it's very sort of oriented towards the PhD student, uh, market, job market, right? Like literally all, basically everyone's there to advertise their research and skills and get jobs.[00:05:28] swyx: And then obviously all the, the companies go there to hire them. And I think that's great for the individual researchers, but for people going there to get info is not great because you have to read between the lines, bring a ton of context in order to understand every single paper. So what is missing is effectively what I ended up doing, which is domain by domain, go through and recap the best of the year.[00:05:48] swyx: Survey the field. And there are, like NeurIPS had a, uh, I think ICML had a like a position paper track, NeurIPS added a benchmarks, uh, datasets track. These are ways in which to address that [00:06:00] issue. Uh, there's always workshops as well. Every, every conference has, you know, a last day of workshops and stuff that provide more of an overview.[00:06:06] swyx: But they're not specifically prompted to do so. And I think really, uh, Organizing a conference is just about getting good speakers and giving them the correct prompts. And then they will just go and do that thing and they do a very good job of it. So I think Sarah did a fantastic job with the startups prompt.[00:06:21] swyx: I can't list everybody, but we did best of 2024 in startups, vision, open models. Post transformers, synthetic data, small models, and agents. And then the last one was the, uh, and then we also did a quick one on reasoning with Nathan Lambert. And then the last one, obviously, was the debate that people were very hyped about.[00:06:39] swyx: It was very awkward. And I'm really, really thankful for John Franco, basically, who stepped up to challenge Dylan. Because Dylan was like, yeah, I'll do it. But He was pro scaling. And I think everyone who is like in AI is pro scaling, right? So you need somebody who's ready to publicly say, no, we've hit a wall.[00:06:57] swyx: So that means you're saying Sam Altman's wrong. [00:07:00] You're saying, um, you know, everyone else is wrong. It helps that this was the day before Ilya went on, went up on stage and then said pre training has hit a wall. And data has hit a wall. So actually Jonathan ended up winning, and then Ilya supported that statement, and then Noam Brown on the last day further supported that statement as well.[00:07:17] swyx: So it's kind of interesting that I think the consensus kind of going in was that we're not done scaling, like you should believe in a better lesson. And then, four straight days in a row, you had Sepp Hochreiter, who is the creator of the LSTM, along with everyone's favorite OG in AI, which is Juergen Schmidhuber.[00:07:34] swyx: He said that, um, we're pre trading inside a wall, or like, we've run into a different kind of wall. And then we have, you know John Frankel, Ilya, and then Noam Brown are all saying variations of the same thing, that we have hit some kind of wall in the status quo of what pre trained, scaling large pre trained models has looked like, and we need a new thing.[00:07:54] swyx: And obviously the new thing for people is some make, either people are calling it inference time compute or test time [00:08:00] compute. I think the collective terminology has been inference time, and I think that makes sense because test time, calling it test, meaning, has a very pre trained bias, meaning that the only reason for running inference at all is to test your model.[00:08:11] swyx: That is not true. Right. Yeah. So, so, I quite agree that. OpenAI seems to have adopted, or the community seems to have adopted this terminology of ITC instead of TTC. And that, that makes a lot of sense because like now we care about inference, even right down to compute optimality. Like I actually interviewed this author who recovered or reviewed the Chinchilla paper.[00:08:31] swyx: Chinchilla paper is compute optimal training, but what is not stated in there is it's pre trained compute optimal training. And once you start caring about inference, compute optimal training, you have a different scaling law. And in a way that we did not know last year.[00:08:45] Alessio: I wonder, because John is, he's also on the side of attention is all you need.[00:08:49] Alessio: Like he had the bet with Sasha. So I'm curious, like he doesn't believe in scaling, but he thinks the transformer, I wonder if he's still. So, so,[00:08:56] swyx: so he, obviously everything is nuanced and you know, I told him to play a character [00:09:00] for this debate, right? So he actually does. Yeah. He still, he still believes that we can scale more.[00:09:04] swyx: Uh, he just assumed the character to be very game for, for playing this debate. So even more kudos to him that he assumed a position that he didn't believe in and still won the debate.[00:09:16] Alessio: Get rekt, Dylan. Um, do you just want to quickly run through some of these things? Like, uh, Sarah's presentation, just the highlights.[00:09:24] swyx: Yeah, we can't go through everyone's slides, but I pulled out some things as a factor of, like, stuff that we were going to talk about. And we'll[00:09:30] Alessio: publish[00:09:31] swyx: the rest. Yeah, we'll publish on this feed the best of 2024 in those domains. And hopefully people can benefit from the work that our speakers have done.[00:09:39] swyx: But I think it's, uh, these are just good slides. And I've been, I've been looking for a sort of end of year recaps from, from people.[00:09:44] The Competitive AI Landscape[00:09:44] swyx: The field has progressed a lot. You know, I think the max ELO in 2023 on LMSys used to be 1200 for LMSys ELOs. And now everyone is at least at, uh, 1275 in their ELOs, and this is across Gemini, Chadjibuti, [00:10:00] Grok, O1.[00:10:01] swyx: ai, which with their E Large model, and Enthopic, of course. It's a very, very competitive race. There are multiple Frontier labs all racing, but there is a clear tier zero Frontier. And then there's like a tier one. It's like, I wish I had everything else. Tier zero is extremely competitive. It's effectively now three horse race between Gemini, uh, Anthropic and OpenAI.[00:10:21] swyx: I would say that people are still holding out a candle for XAI. XAI, I think, for some reason, because their API was very slow to roll out, is not included in these metrics. So it's actually quite hard to put on there. As someone who also does charts, XAI is continually snubbed because they don't work well with the benchmarking people.[00:10:42] swyx: Yeah, yeah, yeah. It's a little trivia for why XAI always gets ignored. The other thing is market share. So these are slides from Sarah. We have it up on the screen. It has gone from very heavily open AI. So we have some numbers and estimates. These are from RAMP. Estimates of open AI market share in [00:11:00] December 2023.[00:11:01] swyx: And this is basically, what is it, GPT being 95 percent of production traffic. And I think if you correlate that with stuff that we asked. Harrison Chase on the LangChain episode, it was true. And then CLAUD 3 launched mid middle of this year. I think CLAUD 3 launched in March, CLAUD 3. 5 Sonnet was in June ish.[00:11:23] swyx: And you can start seeing the market share shift towards opening, uh, towards that topic, uh, very, very aggressively. The more recent one is Gemini. So if I scroll down a little bit, this is an even more recent dataset. So RAM's dataset ends in September 2 2. 2024. Gemini has basically launched a price war at the low end, uh, with Gemini Flash, uh, being basically free for personal use.[00:11:44] swyx: Like, I think people don't understand the free tier. It's something like a billion tokens per day. Unless you're trying to abuse it, you cannot really exhaust your free tier on Gemini. They're really trying to get you to use it. They know they're in like third place, um, fourth place, depending how you, how you count.[00:11:58] swyx: And so they're going after [00:12:00] the Lower tier first, and then, you know, maybe the upper tier later, but yeah, Gemini Flash, according to OpenRouter, is now 50 percent of their OpenRouter requests. Obviously, these are the small requests. These are small, cheap requests that are mathematically going to be more.[00:12:15] swyx: The smart ones obviously are still going to OpenAI. But, you know, it's a very, very big shift in the market. Like basically 2023, 2022, To going into 2024 opening has gone from nine five market share to Yeah. Reasonably somewhere between 50 to 75 market share.[00:12:29] Alessio: Yeah. I'm really curious how ramped does the attribution to the model?[00:12:32] Alessio: If it's API, because I think it's all credit card spin. . Well, but it's all, the credit card doesn't say maybe. Maybe the, maybe when they do expenses, they upload the PDF, but yeah, the, the German I think makes sense. I think that was one of my main 2024 takeaways that like. The best small model companies are the large labs, which is not something I would have thought that the open source kind of like long tail would be like the small model.[00:12:53] swyx: Yeah, different sizes of small models we're talking about here, right? Like so small model here for Gemini is AB, [00:13:00] right? Uh, mini. We don't know what the small model size is, but yeah, it's probably in the double digits or maybe single digits, but probably double digits. The open source community has kind of focused on the one to three B size.[00:13:11] swyx: Mm-hmm . Yeah. Maybe[00:13:12] swyx: zero, maybe 0.5 B uh, that's moon dream and that is small for you then, then that's great. It makes sense that we, we have a range for small now, which is like, may, maybe one to five B. Yeah. I'll even put that at, at, at the high end. And so this includes Gemma from Gemini as well. But also includes the Apple Foundation models, which I think Apple Foundation is 3B.[00:13:32] Alessio: Yeah. No, that's great. I mean, I think in the start small just meant cheap. I think today small is actually a more nuanced discussion, you know, that people weren't really having before.[00:13:43] swyx: Yeah, we can keep going. This is a slide that I smiley disagree with Sarah. She's pointing to the scale SEAL leaderboard. I think the Researchers that I talked with at NeurIPS were kind of positive on this because basically you need private test [00:14:00] sets to prevent contamination.[00:14:02] swyx: And Scale is one of maybe three or four people this year that has really made an effort in doing a credible private test set leaderboard. Llama405B does well compared to Gemini and GPT 40. And I think that's good. I would say that. You know, it's good to have an open model that is that big, that does well on those metrics.[00:14:23] swyx: But anyone putting 405B in production will tell you, if you scroll down a little bit to the artificial analysis numbers, that it is very slow and very expensive to infer. Um, it doesn't even fit on like one node. of, uh, of H100s. Cerebras will be happy to tell you they can serve 4 or 5B on their super large chips.[00:14:42] swyx: But, um, you know, if you need to do anything custom to it, you're still kind of constrained. So, is 4 or 5B really that relevant? Like, I think most people are basically saying that they only use 4 or 5B as a teacher model to distill down to something. Even Meta is doing it. So with Lama 3. [00:15:00] 3 launched, they only launched the 70B because they use 4 or 5B to distill the 70B.[00:15:03] swyx: So I don't know if like open source is keeping up. I think they're the, the open source industrial complex is very invested in telling you that the, if the gap is narrowing, I kind of disagree. I think that the gap is widening with O1. I think there are very, very smart people trying to narrow that gap and they should.[00:15:22] swyx: I really wish them success, but you cannot use a chart that is nearing 100 in your saturation chart. And look, the distance between open source and closed source is narrowing. Of course it's going to narrow because you're near 100. This is stupid. But in metrics that matter, is open source narrowing?[00:15:38] swyx: Probably not for O1 for a while. And it's really up to the open source guys to figure out if they can match O1 or not.[00:15:46] Alessio: I think inference time compute is bad for open source just because, you know, Doc can donate the flops at training time, but he cannot donate the flops at inference time. So it's really hard to like actually keep up on that axis.[00:15:59] Alessio: Big, big business [00:16:00] model shift. So I don't know what that means for the GPU clouds. I don't know what that means for the hyperscalers, but obviously the big labs have a lot of advantage. Because, like, it's not a static artifact that you're putting the compute in. You're kind of doing that still, but then you're putting a lot of computed inference too.[00:16:17] swyx: Yeah, yeah, yeah. Um, I mean, Llama4 will be reasoning oriented. We talked with Thomas Shalom. Um, kudos for getting that episode together. That was really nice. Good, well timed. Actually, I connected with the AI meta guy, uh, at NeurIPS, and, um, yeah, we're going to coordinate something for Llama4. Yeah, yeah,[00:16:32] Alessio: and our friend, yeah.[00:16:33] Alessio: Clara Shi just joined to lead the business agent side. So I'm sure we'll have her on in the new year.[00:16:39] swyx: Yeah. So, um, my comment on, on the business model shift, this is super interesting. Apparently it is wide knowledge that OpenAI wanted more than 6. 6 billion dollars for their fundraise. They wanted to raise, you know, higher, and they did not.[00:16:51] swyx: And what that means is basically like, it's very convenient that we're not getting GPT 5, which would have been a larger pre train. We should have a lot of upfront money. And [00:17:00] instead we're, we're converting fixed costs into variable costs, right. And passing it on effectively to the customer. And it's so much easier to take margin there because you can directly attribute it to like, Oh, you're using this more.[00:17:12] swyx: Therefore you, you pay more of the cost and I'll just slap a margin in there. So like that lets you control your growth margin and like tie your. Your spend, or your sort of inference spend, accordingly. And it's just really interesting to, that this change in the sort of inference paradigm has arrived exactly at the same time that the funding environment for pre training is effectively drying up, kind of.[00:17:36] swyx: I feel like maybe the VCs are very in tune with research anyway, so like, they would have noticed this, but, um, it's just interesting.[00:17:43] Alessio: Yeah, and I was looking back at our yearly recap of last year. Yeah. And the big thing was like the mixed trial price fights, you know, and I think now it's almost like there's nowhere to go, like, you know, Gemini Flash is like basically giving it away for free.[00:17:55] Alessio: So I think this is a good way for the labs to generate more revenue and pass down [00:18:00] some of the compute to the customer. I think they're going to[00:18:02] swyx: keep going. I think that 2, will come.[00:18:05] Alessio: Yeah, I know. Totally. I mean, next year, the first thing I'm doing is signing up for Devin. Signing up for the pro chat GBT.[00:18:12] Alessio: Just to try. I just want to see what does it look like to spend a thousand dollars a month on AI?[00:18:17] swyx: Yes. Yes. I think if your, if your, your job is a, at least AI content creator or VC or, you know, someone who, whose job it is to stay on, stay on top of things, you should already be spending like a thousand dollars a month on, on stuff.[00:18:28] swyx: And then obviously easy to spend, hard to use. You have to actually use. The good thing is that actually Google lets you do a lot of stuff for free now. So like deep research. That they just launched. Uses a ton of inference and it's, it's free while it's in preview.[00:18:45] Alessio: Yeah. They need to put that in Lindy.[00:18:47] Alessio: I've been using Lindy lately. I've been a built a bunch of things once we had flow because I liked the new thing. It's pretty good. I even did a phone call assistant. Um, yeah, they just launched Lindy voice. Yeah, I think once [00:19:00] they get advanced voice mode like capability today, still like speech to text, you can kind of tell.[00:19:06] Alessio: Um, but it's good for like reservations and things like that. So I have a meeting prepper thing. And so[00:19:13] swyx: it's good. Okay. I feel like we've, we've covered a lot of stuff. Uh, I, yeah, I, you know, I think We will go over the individual, uh, talks in a separate episode. Uh, I don't want to take too much time with, uh, this stuff, but that suffice to say that there is a lot of progress in each field.[00:19:28] swyx: Uh, we covered vision. Basically this is all like the audience voting for what they wanted. And then I just invited the best people I could find in each audience, especially agents. Um, Graham, who I talked to at ICML in Vienna, he is currently still number one. It's very hard to stay on top of SweetBench.[00:19:45] swyx: OpenHand is currently still number one. switchbench full, which is the hardest one. He had very good thoughts on agents, which I, which I'll highlight for people. Everyone is saying 2025 is the year of agents, just like they said last year. And, uh, but he had [00:20:00] thoughts on like eight parts of what are the frontier problems to solve in agents.[00:20:03] swyx: And so I'll highlight that talk as well.[00:20:05] Alessio: Yeah. The number six, which is the Hacken agents learn more about the environment, has been a Super interesting to us as well, just to think through, because, yeah, how do you put an agent in an enterprise where most things in an enterprise have never been public, you know, a lot of the tooling, like the code bases and things like that.[00:20:23] Alessio: So, yeah, there's not indexing and reg. Well, yeah, but it's more like. You can't really rag things that are not documented. But people know them based on how they've been doing it. You know, so I think there's almost this like, you know, Oh, institutional knowledge. Yeah, the boring word is kind of like a business process extraction.[00:20:38] Alessio: Yeah yeah, I see. It's like, how do you actually understand how these things are done? I see. Um, and I think today the, the problem is that, Yeah, the agents are, that most people are building are good at following instruction, but are not as good as like extracting them from you. Um, so I think that will be a big unlock just to touch quickly on the Jeff Dean thing.[00:20:55] Alessio: I thought it was pretty, I mean, we'll link it in the, in the things, but. I think the main [00:21:00] focus was like, how do you use ML to optimize the systems instead of just focusing on ML to do something else? Yeah, I think speculative decoding, we had, you know, Eugene from RWKB on the podcast before, like he's doing a lot of that with Fetterless AI.[00:21:12] swyx: Everyone is. I would say it's the norm. I'm a little bit uncomfortable with how much it costs, because it does use more of the GPU per call. But because everyone is so keen on fast inference, then yeah, makes sense.[00:21:24] Alessio: Exactly. Um, yeah, but we'll link that. Obviously Jeff is great.[00:21:30] swyx: Jeff is, Jeff's talk was more, it wasn't focused on Gemini.[00:21:33] swyx: I think people got the wrong impression from my tweet. It's more about how Google approaches ML and uses ML to design systems and then systems feedback into ML. And I think this ties in with Lubna's talk.[00:21:45] Synthetic Data and Future Trends[00:21:45] swyx: on synthetic data where it's basically the story of bootstrapping of humans and AI in AI research or AI in production.[00:21:53] swyx: So her talk was on synthetic data, where like how much synthetic data has grown in 2024 in the pre training side, the post training side, [00:22:00] and the eval side. And I think Jeff then also extended it basically to chips, uh, to chip design. So he'd spend a lot of time talking about alpha chip. And most of us in the audience are like, we're not working on hardware, man.[00:22:11] swyx: Like you guys are great. TPU is great. Okay. We'll buy TPUs.[00:22:14] Alessio: And then there was the earlier talk. Yeah. But, and then we have, uh, I don't know if we're calling them essays. What are we calling these? But[00:22:23] swyx: for me, it's just like bonus for late in space supporters, because I feel like they haven't been getting anything.[00:22:29] swyx: And then I wanted a more high frequency way to write stuff. Like that one I wrote in an afternoon. I think basically we now have an answer to what Ilya saw. It's one year since. The blip. And we know what he saw in 2014. We know what he saw in 2024. We think we know what he sees in 2024. He gave some hints and then we have vague indications of what he saw in 2023.[00:22:54] swyx: So that was the Oh, and then 2016 as well, because of this lawsuit with Elon, OpenAI [00:23:00] is publishing emails from Sam's, like, his personal text messages to Siobhan, Zelis, or whatever. So, like, we have emails from Ilya saying, this is what we're seeing in OpenAI, and this is why we need to scale up GPUs. And I think it's very prescient in 2016 to write that.[00:23:16] swyx: And so, like, it is exactly, like, basically his insights. It's him and Greg, basically just kind of driving the scaling up of OpenAI, while they're still playing Dota. They're like, no, like, we see the path here.[00:23:30] Alessio: Yeah, and it's funny, yeah, they even mention, you know, we can only train on 1v1 Dota. We need to train on 5v5, and that takes too many GPUs.[00:23:37] Alessio: Yeah,[00:23:37] swyx: and at least for me, I can speak for myself, like, I didn't see the path from Dota to where we are today. I think even, maybe if you ask them, like, they wouldn't necessarily draw a straight line. Yeah,[00:23:47] Alessio: no, definitely. But I think like that was like the whole idea of almost like the RL and we talked about this with Nathan on his podcast.[00:23:55] Alessio: It's like with RL, you can get very good at specific things, but then you can't really like generalize as much. And I [00:24:00] think the language models are like the opposite, which is like, you're going to throw all this data at them and scale them up, but then you really need to drive them home on a specific task later on.[00:24:08] Alessio: And we'll talk about the open AI reinforcement, fine tuning, um, announcement too, and all of that. But yeah, I think like scale is all you need. That's kind of what Elia will be remembered for. And I think just maybe to clarify on like the pre training is over thing that people love to tweet. I think the point of the talk was like everybody, we're scaling these chips, we're scaling the compute, but like the second ingredient which is data is not scaling at the same rate.[00:24:35] Alessio: So it's not necessarily pre training is over. It's kind of like What got us here won't get us there. In his email, he predicted like 10x growth every two years or something like that. And I think maybe now it's like, you know, you can 10x the chips again, but[00:24:49] swyx: I think it's 10x per year. Was it? I don't know.[00:24:52] Alessio: Exactly. And Moore's law is like 2x. So it's like, you know, much faster than that. And yeah, I like the fossil fuel of AI [00:25:00] analogy. It's kind of like, you know, the little background tokens thing. So the OpenAI reinforcement fine tuning is basically like, instead of fine tuning on data, you fine tune on a reward model.[00:25:09] Alessio: So it's basically like, instead of being data driven, it's like task driven. And I think people have tasks to do, they don't really have a lot of data. So I'm curious to see how that changes, how many people fine tune, because I think this is what people run into. It's like, Oh, you can fine tune llama. And it's like, okay, where do I get the data?[00:25:27] Alessio: To fine tune it on, you know, so it's great that we're moving the thing. And then I really like he had this chart where like, you know, the brain mass and the body mass thing is basically like mammals that scaled linearly by brain and body size, and then humans kind of like broke off the slope. So it's almost like maybe the mammal slope is like the pre training slope.[00:25:46] Alessio: And then the post training slope is like the, the human one.[00:25:49] swyx: Yeah. I wonder what the. I mean, we'll know in 10 years, but I wonder what the y axis is for, for Ilya's SSI. We'll try to get them on.[00:25:57] Alessio: Ilya, if you're listening, you're [00:26:00] welcome here. Yeah, and then he had, you know, what comes next, like agent, synthetic data, inference, compute, I thought all of that was like that.[00:26:05] Alessio: I don't[00:26:05] swyx: think he was dropping any alpha there. Yeah, yeah, yeah.[00:26:07] Alessio: Yeah. Any other new reps? Highlights?[00:26:10] swyx: I think that there was comparatively a lot more work. Oh, by the way, I need to plug that, uh, my friend Yi made this, like, little nice paper. Yeah, that was really[00:26:20] swyx: nice.[00:26:20] swyx: Uh, of, uh, of, like, all the, he's, she called it must read papers of 2024.[00:26:26] swyx: So I laid out some of these at NeurIPS, and it was just gone. Like, everyone just picked it up. Because people are dying for, like, little guidance and visualizations And so, uh, I thought it was really super nice that we got there.[00:26:38] Alessio: Should we do a late in space book for each year? Uh, I thought about it. For each year we should.[00:26:42] Alessio: Coffee table book. Yeah. Yeah. Okay. Put it in the will. Hi, Will. By the way, we haven't introduced you. He's our new, you know, general organist, Jamie. You need to[00:26:52] swyx: pull up more things. One thing I saw that, uh, Okay, one fun one, and then one [00:27:00] more general one. So the fun one is this paper on agent collusion. This is a paper on steganography.[00:27:06] swyx: This is secret collusion among AI agents, multi agent deception via steganography. I tried to go to NeurIPS in order to find these kinds of papers because the real reason Like NeurIPS this year has a lottery system. A lot of people actually even go and don't buy tickets because they just go and attend the side events.[00:27:22] swyx: And then also the people who go and end up crowding around the most popular papers, which you already know and already read them before you showed up to NeurIPS. So the only reason you go there is to talk to the paper authors, but there's like something like 10, 000 other. All these papers out there that, you know, are just people's work that they, that they did on the air and they failed to get attention for one reason or another.[00:27:42] swyx: And this was one of them. Uh, it was like all the way at the back. And this is a deep mind paper that actually focuses on collusion between AI agents, uh, by hiding messages in the text that they generate. Uh, so that's what steganography is. So a very simple example would be the first letter of every word.[00:27:57] swyx: If you Pick that out, you know, and the code sends a [00:28:00] different message than that. But something I've always emphasized is to LLMs, we read left to right. LLMs can read up, down, sideways, you know, in random character order. And it's the same to them as it is to us. So if we were ever to get You know, self motivated, underlined LLMs that we're trying to collaborate to take over the planet.[00:28:19] swyx: This would be how they do it. They spread messages among us in the messages that we generate. And he developed a scaling law for that. So he marked, I'm showing it on screen right now, the emergence of this phenomenon. Basically, for example, for Cypher encoding, GPT 2, Lama 2, mixed trial, GPT 3. 5, zero capabilities, and sudden 4.[00:28:40] swyx: And this is the kind of Jason Wei type emergence properties that people kind of look for. I think what made this paper stand out as well, so he developed the benchmark for steganography collusion, and he also focused on shelling point collusion, which is very low coordination. For agreeing on a decoding encoding format, you kind of need to have some [00:29:00] agreement on that.[00:29:00] swyx: But, but shelling point means like very, very low or almost no coordination. So for example, if I, if I ask someone, if the only message I give you is meet me in New York and you're not aware. Or when you would probably meet me at Grand Central Station. That is the Grand Central Station is a shelling point.[00:29:16] swyx: And it's probably somewhere, somewhere during the day. That is the shelling point of New York is Grand Central. To that extent, shelling points for steganography are things like the, the, the common decoding methods that we talked about. It will be interesting at some point in the future when we are worried about alignment.[00:29:30] swyx: It is not interesting today, but it's interesting that DeepMind is already thinking about this.[00:29:36] Alessio: I think that's like one of the hardest things about NeurIPS. It's like the long tail. I[00:29:41] swyx: found a pricing guy. I'm going to feature him on the podcast. Basically, this guy from NVIDIA worked out the optimal pricing for language models.[00:29:51] swyx: It's basically an econometrics paper at NeurIPS, where everyone else is talking about GPUs. And the guy with the GPUs is[00:29:57] Alessio: talking[00:29:57] swyx: about economics instead. [00:30:00] That was the sort of fun one. So the focus I saw is that model papers at NeurIPS are kind of dead. No one really presents models anymore. It's just data sets.[00:30:12] swyx: This is all the grad students are working on. So like there was a data sets track and then I was looking around like, I was like, you don't need a data sets track because every paper is a data sets paper. And so data sets and benchmarks, they're kind of flip sides of the same thing. So Yeah. Cool. Yeah, if you're a grad student, you're a GPU boy, you kind of work on that.[00:30:30] swyx: And then the, the sort of big model that people walk around and pick the ones that they like, and then they use it in their models. And that's, that's kind of how it develops. I, I feel like, um, like, like you didn't last year, you had people like Hao Tian who worked on Lava, which is take Lama and add Vision.[00:30:47] swyx: And then obviously actually I hired him and he added Vision to Grok. Now he's the Vision Grok guy. This year, I don't think there was any of those.[00:30:55] Alessio: What were the most popular, like, orals? Last year it was like the [00:31:00] Mixed Monarch, I think, was like the most attended. Yeah, uh, I need to look it up. Yeah, I mean, if nothing comes to mind, that's also kind of like an answer in a way.[00:31:10] Alessio: But I think last year there was a lot of interest in, like, furthering models and, like, different architectures and all of that.[00:31:16] swyx: I will say that I felt the orals, oral picks this year were not very good. Either that or maybe it's just a So that's the highlight of how I have changed in terms of how I view papers.[00:31:29] swyx: So like, in my estimation, two of the best papers in this year for datasets or data comp and refined web or fine web. These are two actually industrially used papers, not highlighted for a while. I think DCLM got the spotlight, FineWeb didn't even get the spotlight. So like, it's just that the picks were different.[00:31:48] swyx: But one thing that does get a lot of play that a lot of people are debating is the role that's scheduled. This is the schedule free optimizer paper from Meta from Aaron DeFazio. And this [00:32:00] year in the ML community, there's been a lot of chat about shampoo, soap, all the bathroom amenities for optimizing your learning rates.[00:32:08] swyx: And, uh, most people at the big labs are. Who I asked about this, um, say that it's cute, but it's not something that matters. I don't know, but it's something that was discussed and very, very popular. 4Wars[00:32:19] Alessio: of AI recap maybe, just quickly. Um, where do you want to start? Data?[00:32:26] swyx: So to remind people, this is the 4Wars piece that we did as one of our earlier recaps of this year.[00:32:31] swyx: And the belligerents are on the left, journalists, writers, artists, anyone who owns IP basically, New York Times, Stack Overflow, Reddit, Getty, Sarah Silverman, George RR Martin. Yeah, and I think this year we can add Scarlett Johansson to that side of the fence. So anyone suing, open the eye, basically. I actually wanted to get a snapshot of all the lawsuits.[00:32:52] swyx: I'm sure some lawyer can do it. That's the data quality war. On the right hand side, we have the synthetic data people, and I think we talked about Lumna's talk, you know, [00:33:00] really showing how much synthetic data has come along this year. I think there was a bit of a fight between scale. ai and the synthetic data community, because scale.[00:33:09] swyx: ai published a paper saying that synthetic data doesn't work. Surprise, surprise, scale. ai is the leading vendor of non synthetic data. Only[00:33:17] Alessio: cage free annotated data is useful.[00:33:21] swyx: So I think there's some debate going on there, but I don't think it's much debate anymore that at least synthetic data, for the reasons that are blessed in Luna's talk, Makes sense.[00:33:32] swyx: I don't know if you have any perspectives there.[00:33:34] Alessio: I think, again, going back to the reinforcement fine tuning, I think that will change a little bit how people think about it. I think today people mostly use synthetic data, yeah, for distillation and kind of like fine tuning a smaller model from like a larger model.[00:33:46] Alessio: I'm not super aware of how the frontier labs use it outside of like the rephrase, the web thing that Apple also did. But yeah, I think it'll be. Useful. I think like whether or not that gets us the big [00:34:00] next step, I think that's maybe like TBD, you know, I think people love talking about data because it's like a GPU poor, you know, I think, uh, synthetic data is like something that people can do, you know, so they feel more opinionated about it compared to, yeah, the optimizers stuff, which is like,[00:34:17] swyx: they don't[00:34:17] Alessio: really work[00:34:18] swyx: on.[00:34:18] swyx: I think that there is an angle to the reasoning synthetic data. So this year, we covered in the paper club, the star series of papers. So that's star, Q star, V star. It basically helps you to synthesize reasoning steps, or at least distill reasoning steps from a verifier. And if you look at the OpenAI RFT, API that they released, or that they announced, basically they're asking you to submit graders, or they choose from a preset list of graders.[00:34:49] swyx: Basically It feels like a way to create valid synthetic data for them to fine tune their reasoning paths on. Um, so I think that is another angle where it starts to make sense. And [00:35:00] so like, it's very funny that basically all the data quality wars between Let's say the music industry or like the newspaper publishing industry or the textbooks industry on the big labs.[00:35:11] swyx: It's all of the pre training era. And then like the new era, like the reasoning era, like nobody has any problem with all the reasoning, especially because it's all like sort of math and science oriented with, with very reasonable graders. I think the more interesting next step is how does it generalize beyond STEM?[00:35:27] swyx: We've been using O1 for And I would say like for summarization and creative writing and instruction following, I think it's underrated. I started using O1 in our intro songs before we killed the intro songs, but it's very good at writing lyrics. You know, I can actually say like, I think one of the O1 pro demos.[00:35:46] swyx: All of these things that Noam was showing was that, you know, you can write an entire paragraph or three paragraphs without using the letter A, right?[00:35:53] Creative Writing with AI[00:35:53] swyx: So like, like literally just anything instead of token, like not even token level, character level manipulation and [00:36:00] counting and instruction following. It's, uh, it's very, very strong.[00:36:02] swyx: And so no surprises when I ask it to rhyme, uh, and to, to create song lyrics, it's going to do that very much better than in previous models. So I think it's underrated for creative writing.[00:36:11] Alessio: Yeah.[00:36:12] Legal and Ethical Issues in AI[00:36:12] Alessio: What do you think is the rationale that they're going to have in court when they don't show you the thinking traces of O1, but then they want us to, like, they're getting sued for using other publishers data, you know, but then on their end, they're like, well, you shouldn't be using my data to then train your model.[00:36:29] Alessio: So I'm curious to see how that kind of comes. Yeah, I mean, OPA has[00:36:32] swyx: many ways to publish, to punish people without bringing, taking them to court. Already banned ByteDance for distilling their, their info. And so anyone caught distilling the chain of thought will be just disallowed to continue on, on, on the API.[00:36:44] swyx: And it's fine. It's no big deal. Like, I don't even think that's an issue at all, just because the chain of thoughts are pretty well hidden. Like you have to work very, very hard to, to get it to leak. And then even when it leaks the chain of thought, you don't know if it's, if it's [00:37:00] The bigger concern is actually that there's not that much IP hiding behind it, that Cosign, which we talked about, we talked to him on Dev Day, can just fine tune 4.[00:37:13] swyx: 0 to beat 0. 1 Cloud SONET so far is beating O1 on coding tasks without, at least O1 preview, without being a reasoning model, same for Gemini Pro or Gemini 2. 0. So like, how much is reasoning important? How much of a moat is there in this, like, All of these are proprietary sort of training data that they've presumably accomplished.[00:37:34] swyx: Because even DeepSeek was able to do it. And they had, you know, two months notice to do this, to do R1. So, it's actually unclear how much moat there is. Obviously, you know, if you talk to the Strawberry team, they'll be like, yeah, I mean, we spent the last two years doing this. So, we don't know. And it's going to be Interesting because there'll be a lot of noise from people who say they have inference time compute and actually don't because they just have fancy chain of thought.[00:38:00][00:38:00] swyx: And then there's other people who actually do have very good chain of thought. And you will not see them on the same level as OpenAI because OpenAI has invested a lot in building up the mythology of their team. Um, which makes sense. Like the real answer is somewhere in between.[00:38:13] Alessio: Yeah, I think that's kind of like the main data war story developing.[00:38:18] The Data War: GPU Poor vs. GPU Rich[00:38:18] Alessio: GPU poor versus GPU rich. Yeah. Where do you think we are? I think there was, again, going back to like the small model thing, there was like a time in which the GPU poor were kind of like the rebel faction working on like these models that were like open and small and cheap. And I think today people don't really care as much about GPUs anymore.[00:38:37] Alessio: You also see it in the price of the GPUs. Like, you know, that market is kind of like plummeted because there's people don't want to be, they want to be GPU free. They don't even want to be poor. They just want to be, you know, completely without them. Yeah. How do you think about this war? You[00:38:52] swyx: can tell me about this, but like, I feel like the, the appetite for GPU rich startups, like the, you know, the, the funding plan is we will raise 60 million and [00:39:00] we'll give 50 of that to NVIDIA.[00:39:01] swyx: That is gone, right? Like, no one's, no one's pitching that. This was literally the plan, the exact plan of like, I can name like four or five startups, you know, this time last year. So yeah, GPU rich startups gone.[00:39:12] The Rise of GPU Ultra Rich[00:39:12] swyx: But I think like, The GPU ultra rich, the GPU ultra high net worth is still going. So, um, now we're, you know, we had Leopold's essay on the trillion dollar cluster.[00:39:23] swyx: We're not quite there yet. We have multiple labs, um, you know, XAI very famously, you know, Jensen Huang praising them for being. Best boy number one in spinning up 100, 000 GPU cluster in like 12 days or something. So likewise at Meta, likewise at OpenAI, likewise at the other labs as well. So like the GPU ultra rich are going to keep doing that because I think partially it's an article of faith now that you just need it.[00:39:46] swyx: Like you don't even know what it's going to, what you're going to use it for. You just, you just need it. And it makes sense that if, especially if we're going into. More researchy territory than we are. So let's say 2020 to 2023 was [00:40:00] let's scale big models territory because we had GPT 3 in 2020 and we were like, okay, we'll go from 1.[00:40:05] swyx: 75b to 1. 8b, 1. 8t. And that was GPT 3 to GPT 4. Okay, that's done. As far as everyone is concerned, Opus 3. 5 is not coming out, GPT 4. 5 is not coming out, and Gemini 2, we don't have Pro, whatever. We've hit that wall. Maybe I'll call it the 2 trillion perimeter wall. We're not going to 10 trillion. No one thinks it's a good idea, at least from training costs, from the amount of data, or at least the inference.[00:40:36] swyx: Would you pay 10x the price of GPT Probably not. Like, like you want something else that, that is at least more useful. So it makes sense that people are pivoting in terms of their inference paradigm.[00:40:47] Emerging Trends in AI Models[00:40:47] swyx: And so when it's more researchy, then you actually need more just general purpose compute to mess around with, uh, at the exact same time that production deployments of the old, the previous paradigm is still ramping up,[00:40:58] swyx: um,[00:40:58] swyx: uh, pretty aggressively.[00:40:59] swyx: So [00:41:00] it makes sense that the GPU rich are growing. We have now interviewed both together and fireworks and replicates. Uh, we haven't done any scale yet. But I think Amazon, maybe kind of a sleeper one, Amazon, in a sense of like they, at reInvent, I wasn't expecting them to do so well, but they are now a foundation model lab.[00:41:18] swyx: It's kind of interesting. Um, I think, uh, you know, David went over there and started just creating models.[00:41:25] Alessio: Yeah, I mean, that's the power of prepaid contracts. I think like a lot of AWS customers, you know, they do this big reserve instance contracts and now they got to use their money. That's why so many startups.[00:41:37] Alessio: Get bought through the AWS marketplace so they can kind of bundle them together and prefer pricing.[00:41:42] swyx: Okay, so maybe GPU super rich doing very well, GPU middle class dead, and then GPU[00:41:48] Alessio: poor. I mean, my thing is like, everybody should just be GPU rich. There shouldn't really be, even the GPU poorest, it's like, does it really make sense to be GPU poor?[00:41:57] Alessio: Like, if you're GPU poor, you should just use the [00:42:00] cloud. Yes, you know, and I think there might be a future once we kind of like figure out what the size and shape of these models is where like the tiny box and these things come to fruition where like you can be GPU poor at home. But I think today is like, why are you working so hard to like get these models to run on like very small clusters where it's like, It's so cheap to run them.[00:42:21] Alessio: Yeah, yeah,[00:42:22] swyx: yeah. I think mostly people think it's cool. People think it's a stepping stone to scaling up. So they aspire to be GPU rich one day and they're working on new methods. Like news research, like probably the most deep tech thing they've done this year is Distro or whatever the new name is.[00:42:38] swyx: There's a lot of interest in heterogeneous computing, distributed computing. I tend generally to de emphasize that historically, but it may be coming to a time where it is starting to be relevant. I don't know. You know, SF compute launched their compute marketplace this year, and like, who's really using that?[00:42:53] swyx: Like, it's a bunch of small clusters, disparate types of compute, and if you can make that [00:43:00] useful, then that will be very beneficial to the broader community, but maybe still not the source of frontier models. It's just going to be a second tier of compute that is unlocked for people, and that's fine. But yeah, I mean, I think this year, I would say a lot more on device, We are, I now have Apple intelligence on my phone.[00:43:19] swyx: Doesn't do anything apart from summarize my notifications. But still, not bad. Like, it's multi modal.[00:43:25] Alessio: Yeah, the notification summaries are so and so in my experience.[00:43:29] swyx: Yeah, but they add, they add juice to life. And then, um, Chrome Nano, uh, Gemini Nano is coming out in Chrome. Uh, they're still feature flagged, but you can, you can try it now if you, if you use the, uh, the alpha.[00:43:40] swyx: And so, like, I, I think, like, you know, We're getting the sort of GPU poor version of a lot of these things coming out, and I think it's like quite useful. Like Windows as well, rolling out RWKB in sort of every Windows department is super cool. And I think the last thing that I never put in this GPU poor war, that I think I should now, [00:44:00] is the number of startups that are GPU poor but still scaling very well, as sort of wrappers on top of either a foundation model lab, or GPU Cloud.[00:44:10] swyx: GPU Cloud, it would be Suno. Suno, Ramp has rated as one of the top ranked, fastest growing startups of the year. Um, I think the last public number is like zero to 20 million this year in ARR and Suno runs on Moto. So Suno itself is not GPU rich, but they're just doing the training on, on Moto, uh, who we've also talked to on, on the podcast.[00:44:31] swyx: The other one would be Bolt, straight cloud wrapper. And, and, um, Again, another, now they've announced 20 million ARR, which is another step up from our 8 million that we put on the title. So yeah, I mean, it's crazy that all these GPU pores are finding a way while the GPU riches are also finding a way. And then the only failures, I kind of call this the GPU smiling curve, where the edges do well, because you're either close to the machines, and you're like [00:45:00] number one on the machines, or you're like close to the customers, and you're number one on the customer side.[00:45:03] swyx: And the people who are in the middle. Inflection, um, character, didn't do that great. I think character did the best of all of them. Like, you have a note in here that we apparently said that character's price tag was[00:45:15] Alessio: 1B.[00:45:15] swyx: Did I say that?[00:45:16] Alessio: Yeah. You said Google should just buy them for 1B. I thought it was a crazy number.[00:45:20] Alessio: Then they paid 2. 7 billion. I mean, for like,[00:45:22] swyx: yeah.[00:45:22] Alessio: What do you pay for node? Like, I don't know what the game world was like. Maybe the starting price was 1B. I mean, whatever it was, it worked out for everybody involved.[00:45:31] The Multi-Modality War[00:45:31] Alessio: Multimodality war. And this one, we never had text to video in the first version, which now is the hottest.[00:45:37] swyx: Yeah, I would say it's a subset of image, but yes.[00:45:40] Alessio: Yeah, well, but I think at the time it wasn't really something people were doing, and now we had VO2 just came out yesterday. Uh, Sora was released last month, last week. I've not tried Sora, because the day that I tried, it wasn't, yeah. I[00:45:54] swyx: think it's generally available now, you can go to Sora.[00:45:56] swyx: com and try it. Yeah, they had[00:45:58] Alessio: the outage. Which I [00:46:00] think also played a part into it. Small things. Yeah. What's the other model that you posted today that was on Replicate? Video or OneLive?[00:46:08] swyx: Yeah. Very, very nondescript name, but it is from Minimax, which I think is a Chinese lab. The Chinese labs do surprisingly well at the video models.[00:46:20] swyx: I'm not sure it's actually Chinese. I don't know. Hold me up to that. Yep. China. It's good. Yeah, the Chinese love video. What can I say? They have a lot of training data for video. Or a more relaxed regulatory environment.[00:46:37] Alessio: Uh, well, sure, in some way. Yeah, I don't think there's much else there. I think like, you know, on the image side, I think it's still open.[00:46:45] Alessio: Yeah, I mean,[00:46:46] swyx: 11labs is now a unicorn. So basically, what is multi modality war? Multi modality war is, do you specialize in a single modality, right? Or do you have GodModel that does all the modalities? So this is [00:47:00] definitely still going, in a sense of 11 labs, you know, now Unicorn, PicoLabs doing well, they launched Pico 2.[00:47:06] swyx: 0 recently, HeyGen, I think has reached 100 million ARR, Assembly, I don't know, but they have billboards all over the place, so I assume they're doing very, very well. So these are all specialist models, specialist models and specialist startups. And then there's the big labs who are doing the sort of all in one play.[00:47:24] swyx: And then here I would highlight Gemini 2 for having native image output. Have you seen the demos? Um, yeah, it's, it's hard to keep up. Literally they launched this last week and a shout out to Paige Bailey, who came to the Latent Space event to demo on the day of launch. And she wasn't prepared. She was just like, I'm just going to show you.[00:47:43] swyx: So they have voice. They have, you know, obviously image input, and then they obviously can code gen and all that. But the new one that OpenAI and Meta both have but they haven't launched yet is image output. So you can literally, um, I think their demo video was that you put in an image of a [00:48:00] car, and you ask for minor modifications to that car.[00:48:02] swyx: They can generate you that modification exactly as you asked. So there's no need for the stable diffusion or comfy UI workflow of like mask here and then like infill there in paint there and all that, all that stuff. This is small model nonsense. Big model people are like, huh, we got you in as everything in the transformer.[00:48:21] swyx: This is the multimodality war, which is, do you, do you bet on the God model or do you string together a whole bunch of, uh, Small models like a, like a chump. Yeah,[00:48:29] Alessio: I don't know, man. Yeah, that would be interesting. I mean, obviously I use Midjourney for all of our thumbnails. Um, they've been doing a ton on the product, I would say.[00:48:38] Alessio: They launched a new Midjourney editor thing. They've been doing a ton. Because I think, yeah, the motto is kind of like, Maybe, you know, people say black forest, the black forest models are better than mid journey on a pixel by pixel basis. But I think when you put it, put it together, have you tried[00:48:53] swyx: the same problems on black forest?[00:48:55] Alessio: Yes. But the problem is just like, you know, on black forest, it generates one image. And then it's like, you got to [00:49:00] regenerate. You don't have all these like UI things. Like what I do, no, but it's like time issue, you know, it's like a mid[00:49:06] swyx: journey. Call the API four times.[00:49:08] Alessio: No, but then there's no like variate.[00:49:10] Alessio: Like the good thing about mid journey is like, you just go in there and you're cooking. There's a lot of stuff that just makes it really easy. And I think people underestimate that. Like, it's not really a skill issue, because I'm paying mid journey, so it's a Black Forest skill issue, because I'm not paying them, you know?[00:49:24] Alessio: Yeah,[00:49:25] swyx: so, okay, so, uh, this is a UX thing, right? Like, you, you, you understand that, at least, we think that Black Forest should be able to do all that stuff. I will also shout out, ReCraft has come out, uh, on top of the image arena that, uh, artificial analysis has done, has apparently, uh, Flux's place. Is this still true?[00:49:41] swyx: So, Artificial Analysis is now a company. I highlighted them I think in one of the early AI Newses of the year. And they have launched a whole bunch of arenas. So, they're trying to take on LM Arena, Anastasios and crew. And they have an image arena. Oh yeah, Recraft v3 is now beating Flux 1. 1. Which is very surprising [00:50:00] because Flux And Black Forest Labs are the old stable diffusion crew who left stability after, um, the management issues.[00:50:06] swyx: So Recurve has come from nowhere to be the top image model. Uh, very, very strange. I would also highlight that Grok has now launched Aurora, which is, it's very interesting dynamics between Grok and Black Forest Labs because Grok's images were originally launched, uh, in partnership with Black Forest Labs as a, as a thin wrapper.[00:50:24] swyx: And then Grok was like, no, we'll make our own. And so they've made their own. I don't know, there are no APIs or benchmarks about it. They just announced it. So yeah, that's the multi modality war. I would say that so far, the small model, the dedicated model people are winning, because they are just focused on their tasks.[00:50:42] swyx: But the big model, People are always catching up. And the moment I saw the Gemini 2 demo of image editing, where I can put in an image and just request it and it does, that's how AI should work. Not like a whole bunch of complicated steps. So it really is something. And I think one frontier that we haven't [00:51:00] seen this year, like obviously video has done very well, and it will continue to grow.[00:51:03] swyx: You know, we only have Sora Turbo today, but at some point we'll get full Sora. Oh, at least the Hollywood Labs will get Fulsora. We haven't seen video to audio, or video synced to audio. And so the researchers that I talked to are already starting to talk about that as the next frontier. But there's still maybe like five more years of video left to actually be Soda.[00:51:23] swyx: I would say that Gemini's approach Compared to OpenAI, Gemini seems, or DeepMind's approach to video seems a lot more fully fledged than OpenAI. Because if you look at the ICML recap that I published that so far nobody has listened to, um, that people have listened to it. It's just a different, definitely different audience.[00:51:43] swyx: It's only seven hours long. Why are people not listening? It's like everything in Uh, so, so DeepMind has, is working on Genie. They also launched Genie 2 and VideoPoet. So, like, they have maybe four years advantage on world modeling that OpenAI does not have. Because OpenAI basically only started [00:52:00] Diffusion Transformers last year, you know, when they hired, uh, Bill Peebles.[00:52:03] swyx: So, DeepMind has, has a bit of advantage here, I would say, in, in, in showing, like, the reason that VO2, while one, They cherry pick their videos. So obviously it looks better than Sora, but the reason I would believe that VO2, uh, when it's fully launched will do very well is because they have all this background work in video that they've done for years.[00:52:22] swyx: Like, like last year's NeurIPS, I already was interviewing some of their video people. I forget their model name, but for, for people who are dedicated fans, they can go to NeurIPS 2023 and see, see that paper.[00:52:32] Alessio: And then last but not least, the LLMOS. We renamed it to Ragops, formerly known as[00:52:39] swyx: Ragops War. I put the latest chart on the Braintrust episode.[00:52:43] swyx: I think I'm going to separate these essays from the episode notes. So the reason I used to do that, by the way, is because I wanted to show up on Hacker News. I wanted the podcast to show up on Hacker News. So I always put an essay inside of there because Hacker News people like to read and not listen.[00:52:58] Alessio: So episode essays,[00:52:59] swyx: I remember [00:53:00] purchasing them separately. You say Lanchain Llama Index is still growing.[00:53:03] Alessio: Yeah, so I looked at the PyPy stats, you know. I don't care about stars. On PyPy you see Do you want to share your screen? Yes. I prefer to look at actual downloads, not at stars on GitHub. So if you look at, you know, Lanchain still growing.[00:53:20] Alessio: These are the last six months. Llama Index still growing. What I've basically seen is like things that, One, obviously these things have A commercial product. So there's like people buying this and sticking with it versus kind of hopping in between things versus, you know, for example, crew AI, not really growing as much.[00:53:38] Alessio: The stars are growing. If you look on GitHub, like the stars are growing, but kind of like the usage is kind of like flat. In the last six months, have they done some[00:53:4

Happy holidays! We'll be sharing snippets from Latent Space LIVE! through the break bringing you the best of 2024! We want to express our deepest appreciation to event sponsors AWS, Daylight Computer, Thoth.ai, StrongCompute, Notable Capital, and most of all all our LS supporters who helped fund the gorgeous venue and A/V production!For NeurIPS last year we did our standard conference podcast coverage interviewing selected papers (that we have now also done for ICLR and ICML), however we felt that we could be doing more to help AI Engineers 1) get more industry-relevant content, and 2) recap 2024 year in review from experts. As a result, we organized the first Latent Space LIVE!, our first in person miniconference, at NeurIPS 2024 in Vancouver.Our next keynote covers The State of LLM Agents, with the triumphant return of Professor Graham Neubig's return to the pod (his ICLR episode here!). OpenDevin is now a startup known as AllHands! The renamed OpenHands has done extremely well this year, as they end the year sitting comfortably at number 1 on the hardest SWE-Bench Full leaderboard at 29%, though on the smaller SWE-Bench Verified, they are at 53%, behind Amazon Q, devlo, and OpenAI's self reported o3 results at 71.7%.Many are saying that 2025 is going to be the year of agents, with OpenAI, DeepMind and Anthropic setting their sights on consumer and coding agents, vision based computer-using agents and multi agent systems. There has been so much progress on the practical reliability and applications of agents in all domains, from the huge launch of Cognition AI's Devin this year, to the sleeper hit of Cursor Composer and Codeium's Windsurf Cascade in the IDE arena, to the explosive revenue growth of Stackblitz's Bolt, Lovable, and Vercel's v0, and the unicorn rounds and high profile movements of customer support agents like Sierra (now worth $4 billion) and search agents like Perplexity (now worth $9 billion). We wanted to take a little step back to understand the most notable papers of the year in Agents, and Graham indulged with his list of 8 perennial problems in building agents in 2024.Must-Read Papers for the 8 Problems of Agents* The agent-computer interface: CodeAct: Executable Code Actions Elicit Better LLM Agents. Minimial viable tools: Execution Sandbox, File Editor, Web Browsing* The human-agent interface: Chat UI, GitHub Plugin, Remote runtime, …?* Choosing an LLM: See Evaluation of LLMs as Coding Agents on SWE-Bench at 30x - must understand instructions, tools, code, environment, error recovery* Planning: Single Agent Systems vs Multi Agent (CoAct: A Global-Local Hierarchy for Autonomous Agent Collaboration) - Explicit vs Implicit, Curated vs Generated* Reusable common workflows: SteP: Stacked LLM Policies for Web Actions and Agent Workflow Memory - Manual prompting vs Learning from Experience* Exploration: Agentless: Demystifying LLM-based Software Engineering Agents and BAGEL: Bootstrapping Agents by Guiding Exploration with Language* Search: Tree Search for Language Model Agents - explore paths and rewind* Evaluation: Fast Sanity Checks (miniWoB and Aider) and Highly Realistic (WebArena, SWE-Bench) and SWE-Gym: An Open Environment for Training Software Engineering Agents & VerifiersFull Talk on YouTubePlease like and subscribe!Timestamps* 00:00 Welcome to Latent Space Live at NeurIPS 2024* 00:29 State of LLM Agents in 2024* 02:20 Professor Graham Newbig's Insights on Agents* 03:57 Live Demo: Coding Agents in Action* 08:20 Designing Effective Agents* 14:13 Choosing the Right Language Model for Agents* 16:24 Planning and Workflow for Agents* 22:21 Evaluation and Future Predictions for Agents* 25:31 Future of Agent Development* 25:56 Human-Agent Interaction Challenges* 26:48 Expanding Agent Use Beyond Programming* 27:25 Redesigning Systems for Agent Efficiency* 28:03 Accelerating Progress with Agent Technology* 28:28 Call to Action for Open Source Contributions* 30:36 Q&A: Agent Performance and Benchmarks* 33:23 Q&A: Web Agents and Interaction Methods* 37:16 Q&A: Agent Architectures and Improvements* 43:09 Q&A: Self-Improving Agents and Authentication* 47:31 Live Demonstration and Closing RemarksTranscript[00:00:29] State of LLM Agents in 2024[00:00:29] Speaker 9: Our next keynote covers the state of LLM agents. With the triumphant return of Professor Graham Newbig of CMU and OpenDevon, now a startup known as AllHands. The renamed OpenHands has done extremely well this year, as they end the year sitting comfortably at number one on the hardest SWE Benchful leaderboard at 29%.[00:00:53] Speaker 9: Though, on the smaller SWE bench verified, they are at 53 percent behind Amazon Q [00:01:00] Devlo and OpenAI's self reported O3 results at 71. 7%. Many are saying that 2025 is going to be the year of agents, with OpenAI, DeepMind, and Anthropic setting their sights on consumer and coding agents. Vision based computer using agents and multi agent systems.[00:01:22] Speaker 9: There has been so much progress on the practical reliability and applications of agents in all domains, from the huge launch of Cognition AI's Devon this year, to the sleeper hit of Cursor Composer and recent guest Codium's Windsurf Cascade in the IDE arena. To the explosive revenue growth of recent guests StackBlitz's Bolt, Lovable, and Vercel's vZero.[00:01:44] Speaker 9: And the unicorn rounds and high profile movements of customer support agents like Sierra, now worth 4 billion, and search agents like Perplexity, now worth 9 billion. We wanted to take a little step back to understand the most notable papers of the year in [00:02:00] agents, and Graham indulged with his list of eight perennial problems in building agents.[00:02:06] Speaker 9: As always, don't forget to check our show notes for all the selected best papers of 2024, and for the YouTube link to their talk. Graham's slides were especially popular online, and we are honoured to have him. Watch out and take care![00:02:20] Professor Graham Newbig's Insights on Agents[00:02:20] Speaker: Okay hi everyone. So I was given the task of talking about agents in 2024, and this is An impossible task because there are so many agents, so many agents in 2024. So this is going to be strongly covered by like my personal experience and what I think is interesting and important, but I think it's an important topic.[00:02:41] Speaker: So let's go ahead. So the first thing I'd like to think about is let's say I gave you you know, a highly competent human, some tools. Let's say I gave you a web browser and a terminal or a file system. And the ability to [00:03:00] edit text or code. What could you do with that? Everything. Yeah.[00:03:07] Speaker: Probably a lot of things. This is like 99 percent of my, you know, daily daily life, I guess. When I'm, when I'm working. So, I think this is a pretty powerful tool set, and I am trying to do, and what I think some other people are trying to do, is come up with agents that are able to, you know, manipulate these things.[00:03:26] Speaker: Web browsing, coding, running code in successful ways. So there was a little bit about my profile. I'm a professor at CMU, chief scientist at All Hands AI, building open source coding agents. I'm maintainer of OpenHands, which is an open source coding agent framework. And I'm also a software developer and I, I like doing lots of coding and, and, you know, shipping new features and stuff like this.[00:03:51] Speaker: So building agents that help me to do this, you know, is kind of an interesting thing, very close to me.[00:03:57] Live Demo: Coding Agents in Action[00:03:57] Speaker: So the first thing I'd like to do is I'd like to try [00:04:00] some things that I haven't actually tried before. If anybody has, you know, tried to give a live demo, you know, this is, you know very, very scary whenever you do it and it might not work.[00:04:09] Speaker: So it might not work this time either. But I want to show you like three things that I typically do with coding agents in my everyday work. I use coding agents maybe five to 10 times a day to help me solve my own problems. And so this is a first one. This is a data science task. Which says I want to create scatter plots that show the increase of the SWE bench score over time.[00:04:34] Speaker: And so I, I wrote a kind of concrete prompt about this. Agents work better with like somewhat concrete prompts. And I'm gonna throw this into open hands and let it work. And I'll, I'll go back to that in a second. Another thing that I do is I create new software. And I, I've been using a [00:05:00] service a particular service.[00:05:01] Speaker: I won't name it for sending emails and I'm not very happy with it. So I want to switch over to this new service called resend. com, which makes it easier to send emails. And so I'm going to ask it to read the docs for the resend. com API and come up with a script that allows me to send emails. The input to the script should be a CSV file and the subject and body should be provided in Jinja2 templates.[00:05:24] Speaker: So I'll start another agent and and try to get it to do that for me.[00:05:35] Speaker: And let's go with the last one. The last one I do is. This is improving existing software and in order, you know, once you write software, you usually don't throw it away. You go in and, like, actually improve it iteratively. This software that I have is something I created without writing any code.[00:05:52] Speaker: It's basically software to monitor how much our our agents are contributing to the OpenHance repository. [00:06:00] And on the, let me make that a little bit bigger, on the left side, I have the number of issues where it like sent a pull request. I have the number of issues where it like sent a pull request, whether it was merged in purple, closed in red, or is still open in green. And so these are like, you know, it's helping us monitor, but one thing it doesn't tell me is the total number. And I kind of want that feature added to this software.[00:06:33] Speaker: So I'm going to try to add that too. So. I'll take this, I'll take this prompt,[00:06:46] Speaker: and here I want to open up specifically that GitHub repo. So I'll open up that repo and paste in the prompt asking it. I asked it to make a pie chart for each of these and give me the total over the entire time period that I'm [00:07:00] monitoring. So we'll do that. And so now I have let's see, I have some agents.[00:07:05] Speaker: Oh, this one already finished. Let's see. So this one already finished. You can see it finished analyzing the Swebench repository. It wrote a demonstration of, yeah, I'm trying to do that now, actually.[00:07:30] Speaker: It wrote a demonstration of how much each of the systems have improved over time. And I asked it to label the top three for each of the data sets. And so it labeled OpenHands as being the best one for SWE Bench Normal. For SWE Bench Verified, it has like the Amazon QAgent and OpenHands. For the SWE Bench Lite, it has three here over three over here.[00:07:53] Speaker: So you can see like. That's pretty useful, right? If you're a researcher, you do data analysis all the time. I did it while I was talking to all [00:08:00] of you and making a presentation. So that's, that's pretty nice. I, I doubt the other two are finished yet. That would be impressive if the, yeah. So I think they're still working.[00:08:09] Speaker: So maybe we'll get back to them at the end of the presentation. But so these are the kinds of the, these are the kinds of things that I do every day with coding agents now. And it's or software development agents. It's pretty impressive.[00:08:20] Designing Effective Agents[00:08:20] Speaker: The next thing I'd like to talk about a little bit is things I worry about when designing agents.[00:08:24] Speaker: So we're designing agents to, you know, do a very difficult task of like navigating websites writing code, other things like this. And within 2024, there's been like a huge improvement in the methodology that we use to do this. But there's a bunch of things we think about. There's a bunch of interesting papers, and I'd like to introduce a few of them.[00:08:46] Speaker: So the first thing I worry about is the agent computer interface. Like, how do we get an agent to interact with computers? And, How do we provide agents with the tools to do the job? And [00:09:00] within OpenHands we are doing the thing on the right, but there's also a lot of agents that do the thing on the left.[00:09:05] Speaker: So the thing on the left is you give like agents kind of granular tools. You give them tools like or let's say your instruction is I want to determine the most cost effective country to purchase the smartphone model, Kodak one the countries to consider are the USA, Japan, Germany, and India. And you have a bunch of available APIs.[00:09:26] Speaker: And. So what you do for some agents is you provide them all of these tools APIs as tools that they can call. And so in this particular case in order to solve this problem, you'd have to make about like 30 tool calls, right? You'd have to call lookup rates for Germany, you'd have to look it up for the US, Japan, and India.[00:09:44] Speaker: That's four tool goals. And then you go through and do all of these things separately. And the method that we adopt in OpenHands instead is we provide these tools, but we provide them by just giving a coding agent, the ability to call [00:10:00] arbitrary Python code. And. In the arbitrary Python code, it can call these tools.[00:10:05] Speaker: We expose these tools as APIs that the model can call. And what that allows us to do is instead of writing 20 tool calls, making 20 LLM calls, you write a program that runs all of these all at once, and it gets the result. And of course it can execute that program. It can, you know, make a mistake. It can get errors back and fix things.[00:10:23] Speaker: But that makes our job a lot easier. And this has been really like instrumental to our success, I think. Another part of this is what tools does the agent need? And I, I think this depends on your use case, we're kind of extreme and we're only giving the agent five tools or maybe six tools.[00:10:40] Speaker: And what, what are they? The first one is program execution. So it can execute bash programs, and it can execute Jupyter notebooks. It can execute cells in Jupyter notebooks. So that, those are two tools. Another one is a file editing tool. And the file editing tool allows you to browse parts of files.[00:11:00][00:11:00] Speaker: And kind of read them, overwrite them, other stuff like this. And then we have another global search and replace tool. So it's actually two tools for file editing. And then a final one is web browsing, web browsing. I'm kind of cheating when I call it only one tool. You actually have like scroll and text input and click and other stuff like that.[00:11:18] Speaker: But these are basically the only things we allow the agent to do. What, then the question is, like, what if we wanted to allow it to do something else? And the answer is, well, you know, human programmers already have a bunch of things that they use. They have the requests PyPy library, they have the PDF to text PyPy library, they have, like, all these other libraries in the Python ecosystem that they could use.[00:11:41] Speaker: And so if we provide a coding agent with all these libraries, it can do things like data visualization and other stuff that I just showed you. So it can also get clone repositories and, and other things like this. The agents are super good at using the GitHub API also. So they can do, you know, things on GitHub, like finding all of the, you know, [00:12:00] comments on your issues or checking GitHub actions and stuff.[00:12:02] Speaker: The second thing I think about is the human agent interface. So this is like how do we get humans to interact with agents? Bye. I already showed you one variety of our human agent interface. It's basically a chat window where you can browse through the agent's results and things like this. This is very, very difficult.[00:12:18] Speaker: I, I don't think anybody has a good answer to this, and I don't think we have a good answer to this, but the, the guiding principles that I'm trying to follow are we want to present enough info to the user. So we want to present them with, you know, what the agent is doing in the form of a kind of.[00:12:36] Speaker: English descriptions. So you can see here you can see here every time it takes an action, it says like, I will help you create a script for sending emails. When it runs a bash command. Sorry, that's a little small. When it runs a bash command, it will say ran a bash command. It won't actually show you the whole bash command or the whole Jupyter notebook because it can be really large, but you can open it up and see if you [00:13:00] want to, by clicking on this.[00:13:01] Speaker: So like if you want to explore more, you can click over to the Jupyter notebook and see what's displayed in the Jupyter notebook. And you get like lots and lots of information. So that's one thing.[00:13:16] Speaker: Another thing is go where the user is. So like if the user's already interacting in a particular setting then I'd like to, you know, integrate into that setting, but only to a point. So at OpenHands, we have a chat UI for interaction. We have a GitHub plugin for tagging and resolving issues. So basically what you do is you Do at open hands agent and the open hands agent will like see that comment and be able to go in and fix things.[00:13:42] Speaker: So if you say at open hands agent tests are failing on this PR, please fix the tests. It will go in and fix the test for you and stuff like this. Another thing we have is a remote runtime for launching headless jobs. So if you want to launch like a fleet of agents to solve, you know five different problems at once, you can also do [00:14:00] that through an API.[00:14:00] Speaker: So we have we have these interfaces and this probably depends on the use case. So like, depending if you're a coding agent, you want to do things one way. If you're a like insurance auditing agent, you'll want to do things other ways, obviously.[00:14:13] Choosing the Right Language Model for Agents[00:14:13] Speaker: Another thing I think about a lot is choosing a language model.[00:14:16] Speaker: And for agentic LMs we have to have a bunch of things work really well. The first thing is really, really good instruction following ability. And if you have really good instruction following ability, it opens up like a ton of possible applications for you. Tool use and coding ability. So if you provide tools, it needs to be able to use them well.[00:14:38] Speaker: Environment understanding. So it needs, like, if you're building a web agent, it needs to be able to understand web pages either through vision or through text. And error awareness and recovery ability. So, if it makes a mistake, it needs to be able to, you know, figure out why it made a mistake, come up with alternative strategies, and other things like this.[00:14:58] Speaker: [00:15:00] Under the hood, in all of the demos that I did now Cloud, we're using Cloud. Cloud has all of these abilities very good, not perfect, but very good. Most others don't have these abilities quite as much. So like GPT 4. 0 doesn't have very good error recovery ability. And so because of this, it will go into loops and do the same thing over and over and over again.[00:15:22] Speaker: Whereas Claude does not do this. Claude, if you, if you use the agents enough, you get used to their kind of like personality. And Claude says, Hmm, let me try a different approach a lot. So, you know, obviously it's been trained in some way to, you know, elicit this ability. We did an evaluation. This is old.[00:15:40] Speaker: And we need to update this basically, but we evaluated CLOD, mini LLAMA 405B, DeepSeq 2. 5 on being a good code agent within our framework. And CLOD was kind of head and shoulders above the rest. GPT 40 was kind of okay. The best open source model was LLAMA [00:16:00] 3. 1 405B. This needs to be updated because this is like a few months old by now and, you know, things are moving really, really fast.[00:16:05] Speaker: But I still am under the impression that Claude is the best. The other closed models are, you know, not quite as good. And then the open models are a little bit behind that. Grok, I, we haven't tried Grok at all, actually. So, it's a good question. If you want to try it I'd be happy to help.[00:16:24] Speaker: Cool.[00:16:24] Planning and Workflow for Agents[00:16:24] Speaker: Another thing is planning. And so there's a few considerations for planning. The first one is whether you have a curated plan or you have it generated on the fly. And so for solving GitHub issues, you can kind of have an overall plan. Like the plan is first reproduce. If there's an issue, first write tests to reproduce the issue or to demonstrate the issue.[00:16:50] Speaker: After that, run the tests and make sure they fail. Then go in and fix the tests. Run the tests again to make sure they pass and then you're done. So that's like a pretty good workflow [00:17:00] for like solving coding issues. And you could curate that ahead of time. Another option is to let the language model basically generate its own plan.[00:17:10] Speaker: And both of these are perfectly valid. Another one is explicit structure versus implicit structure. So let's say you generate a plan. If you have explicit structure, you could like write a multi agent system, and the multi agent system would have your reproducer agent, and then it would have your your bug your test writer agent, and your bug fixer agent, and lots of different agents, and you would explicitly write this all out in code, and then then use it that way.[00:17:38] Speaker: On the other hand, you could just provide a prompt that says, please do all of these things in order. So in OpenHands, we do very light planning. We have a single prompt. We don't have any multi agent systems. But we do provide, like, instructions about, like, what to do first, what to do next, and other things like this.[00:17:56] Speaker: I'm not against doing it the other way. But I laid [00:18:00] out some kind of justification for this in this blog called Don't Sleep on Single Agent Systems. And the basic idea behind this is if you have a really, really good instruction following agent it will follow the instructions as long as things are working according to your plan.[00:18:14] Speaker: But let's say you need to deviate from your plan, you still have the flexibility to do this. And if you do explicit structure through a multi agent system, it becomes a lot harder to do that. Like, you get stuck when things deviate from your plan. There's also some other examples, and I wanted to introduce a few papers.[00:18:30] Speaker: So one paper I liked recently is this paper called CoAct where you generate plans and then go in and fix them. And so the basic idea is like, if you need to deviate from your plan, you can You know, figure out that your plan was not working and go back and deviate from it.[00:18:49] Speaker: Another thing I think about a lot is specifying common workflows. So we're trying to tackle a software development and I already showed like three use cases where we do [00:19:00] software development and when we. We do software development, we do a ton of different things, but we do them over and over and over again.[00:19:08] Speaker: So just to give an example we fix GitHub actions when GitHub actions are failing. And we do that over and over and over again. That's not the number one thing that software engineers do, but it's a, you know, high up on the list. So how can we get a list of all of, like, the workflows that people are working on?[00:19:26] Speaker: And there's a few research works that people have done in this direction. One example is manual prompting. So there's this nice paper called STEP that got state of the art on the WebArena Web Navigation Benchmark where they came up with a bunch of manual workflows for solving different web navigation tasks.[00:19:43] Speaker: And we also have a paper recently called Agent Workflow Memory where the basic idea behind this is we want to create self improving agents that learn from their past successes. And the way it works is is we have a memory that has an example of lots of the previous [00:20:00] workflows that people have used. And every time the agent finishes a task and it self judges that it did a good job at that task, you take that task, you break it down into individual workflows included in that, and then you put it back in the prompt for the agent to work next time.[00:20:16] Speaker: And this we demonstrated that this leads to a 22. 5 percent increase on WebArena after 40 examples. So that's a pretty, you know, huge increase by kind of self learning and self improvement.[00:20:31] Speaker: Another thing is exploration. Oops. And one thing I think about is like, how can agents learn more about their environment before acting? And I work on coding and web agents, and there's, you know, a few good examples of this in, in both areas. Within coding, I view this as like repository understanding, understanding the code base that you're dealing with.[00:20:55] Speaker: And there's an example of this, or a couple examples of this, one example being AgentList. [00:21:00] Where they basically create a map of the repo and based on the map of the repo, they feed that into the agent so the agent can then navigate the repo and and better know where things are. And for web agents there's an example of a paper called Bagel, and basically what they do is they have the agent just do random tasks on a website, explore the website, better understand the structure of the website, and then after that they they feed that in as part of the product.[00:21:27] Speaker: Part seven is search. Right now in open hands, we just let the agent go on a linear search path. So it's just solving the problem once. We're using a good agent that can kind of like recover from errors and try alternative things when things are not working properly, but still we only have a linear search path.[00:21:45] Speaker: But there's also some nice work in 2024 that is about exploring multiple paths. So one example of this is there's a paper called Tree Search for Language Agents. And they basically expand multiple paths check whether the paths are going well, [00:22:00] and if they aren't going well, you rewind back. And on the web, this is kind of tricky, because, like, how do you rewind when you accidentally ordered something you don't want on Amazon?[00:22:09] Speaker: It's kind of, you know, not, not the easiest thing to do. For code, it's a little bit easier, because you can just revert any changes that you made. But I, I think that's an interesting topic, too.[00:22:21] Evaluation and Future Predictions for Agents[00:22:21] Speaker: And then finally evaluation. So within our development for evaluation, we want to do a number of things. The first one is fast sanity checks.[00:22:30] Speaker: And in order to do this, we want things we can run really fast, really really cheaply. So for web, we have something called mini world of bits, which is basically these trivial kind of web navigation things. We have something called the Adder Code Editing Benchmark, where it's just about editing individual files that we use.[00:22:48] Speaker: But we also want highly realistic evaluation. So for the web, we have something called WebArena that we created at CMU. This is web navigation on real real open source websites. So it's open source [00:23:00] websites that are actually used to serve shops or like bulletin boards or other things like this.[00:23:07] Speaker: And for code, we use Swebench, which I think a lot of people may have heard of. It's basically a coding benchmark that comes from real world pull requests on GitHub. So if you can solve those, you can also probably solve other real world pull requests. I would say we still don't have benchmarks for the fur full versatility of agents.[00:23:25] Speaker: So, for example We don't have benchmarks that test whether agents can code and do web navigation. But we're working on that and hoping to release something in the next week or two. So if that sounds interesting to you, come talk to me and I, I will tell you more about it.[00:23:42] Speaker: Cool. So I don't like making predictions, but I was told that I should be somewhat controversial, I guess, so I will, I will try to do it try to do it anyway, although maybe none of these will be very controversial. Um, the first thing is agent oriented LLMs like large language models for [00:24:00] agents.[00:24:00] Speaker: My, my prediction is every large LM trainer will be focusing on training models as agents. So every large language model will be a better agent model by mid 2025. Competition will increase, prices will go down, smaller models will become competitive as agents. So right now, actually agents are somewhat expensive to run in some cases, but I expect that that won't last six months.[00:24:23] Speaker: I, I bet we'll have much better agent models in six months. Another thing is instruction following ability, specifically in agentic contexts, will increase. And what that means is we'll have to do less manual engineering of agentic workflows and be able to do more by just prompting agents in more complex ways.[00:24:44] Speaker: Cloud is already really good at this. It's not perfect, but it's already really, really good. And I expect the other models will catch up to Cloud pretty soon. Error correction ability will increase, less getting stuck in loops. Again, this is something that Cloud's already pretty good at and I expect the others will, will follow.[00:25:00][00:25:01] Speaker: Agent benchmarks. Agent benchmarks will start saturating.[00:25:05] Speaker: And Swebench I think WebArena is already too easy. It, it is, it's not super easy, but it's already a bit too easy because the tasks we do in there are ones that take like two minutes for a human. So not, not too hard. And kind of historically in 2023 our benchmarks were too easy. So we built harder benchmarks like WebArena and Swebench were both built in 2023.[00:25:31] Future of Agent Development[00:25:31] Speaker: In 2024, our agents were too bad, so we built agents and now we're building better agents. In 2025, our benchmarks will be too easy, so we'll build better benchmarks, I'm, I'm guessing. So, I would expect to see much more challenging agent benchmarks come out, and we're already seeing some of them.[00:25:49] Speaker: In 2026, I don't know. I didn't write AGI, but we'll, we'll, we'll see.[00:25:56] Human-Agent Interaction Challenges[00:25:56] Speaker: Then the human agent computer interface. I think one thing that [00:26:00] we'll want to think about is what do we do at 75 percent success rate at things that we like actually care about? Right now we have 53 percent or 55 percent on Swebench verified, which is real world GitHub PRs.[00:26:16] Speaker: My impression is that the actual. Actual ability of models is maybe closer to 30 to 40%. So 30 to 40 percent of the things that I want an agent to solve on my own repos, it just solves without any human intervention. 80 to 90 percent it can solve without me opening an IDE. But I need to give it feedback.[00:26:36] Speaker: So how do we, how do we make that interaction smooth so that humans can audit? The work of agents that are really, really good, but not perfect is going to be a big challenge.[00:26:48] Expanding Agent Use Beyond Programming[00:26:48] Speaker: How can we expose the power of programming agents to other industries? So like as programmers, I think not all of us are using agents every day in our programming, although we probably will be [00:27:00] in in months or maybe a year.[00:27:02] Speaker: But I, I think it will come very naturally to us as programmers because we know code. We know, you know. Like how to architect software and stuff like that. So I think the question is how do we put this in the hands of like a lawyer or a chemist or somebody else and have them also be able to, you know, interact with it as naturally as we can.[00:27:25] Redesigning Systems for Agent Efficiency[00:27:25] Speaker: Another interesting thing is how can we redesign our existing systems for agents? So we had a paper on API based web agents, and basically what we showed is If you take a web agent and the agent interacts not with a website, but with APIs, the accuracy goes way up just because APIs are way easier to interact with.[00:27:42] Speaker: And in fact, like when I ask the, well, our agent, our agent is able to browse websites, but whenever I want it to interact with GitHub, I tell it do not browse the GitHub website. Use the GitHub API because it's way more successful at doing that. So maybe, you know, every website is going to need to have [00:28:00] an API because we're going to be having agents interact with them.[00:28:03] Accelerating Progress with Agent Technology[00:28:03] Speaker: About progress, I think progress will get faster. It's already fast. A lot of people are already overwhelmed, but I think it will continue. The reason why is agents are building agents. And better agents will build better agents faster. So I expect that you know, if you haven't interacted with a coding agent yet, it's pretty magical, like the stuff that it can do.[00:28:24] Speaker: So yeah.[00:28:28] Call to Action for Open Source Contributions[00:28:28] Speaker: And I have a call to action. I'm honestly, like I've been working on, you know, natural language processing and, and Language models for what, 15 years now. And even for me, it's pretty impressive what like AI agents powered by strong language models can do. On the other hand, I believe that we should really make these powerful tools accessible.[00:28:49] Speaker: And what I mean by this is I don't think like, you know, We, we should have these be opaque or limited to only a set, a certain set of people. I feel like they should be [00:29:00] affordable. They shouldn't be increasing the, you know, difference in the amount of power that people have. If anything, I'd really like them to kind of make it It's possible for people who weren't able to do things before to be able to do them well.[00:29:13] Speaker: Open source is one way to do that. That's why I'm working on open source. There are other ways to do that. You know, make things cheap, make things you know, so you can serve them to people who aren't able to afford them. Easily, like Duolingo is one example where they get all the people in the US to pay them 20 a month so that they can give all the people in South America free, you know, language education, so they can learn English and become, you know like, and become, you know, More attractive on the job market, for instance.[00:29:41] Speaker: And so I think we can all think of ways that we can do that sort of thing. And if that resonates with you, please contribute. Of course, I'd be happy if you contribute to OpenHands and use it. But another way you can do that is just use open source solutions, contribute to them, research with them, and train strong open source [00:30:00] models.[00:30:00] Speaker: So I see, you know, Some people in the room who are already training models. It'd be great if you could train models for coding agents and make them cheap. And yeah yeah, please. I, I was thinking about you among others. So yeah, that's all I have. Thanks.[00:30:20] Speaker 2: Slight, slightly controversial. Tick is probably the nicest way to say hot ticks. Any hot ticks questions, actual hot ticks?[00:30:31] Speaker: Oh, I can also show the other agents that were working, if anybody's interested, but yeah, sorry, go ahead.[00:30:36] Q&A: Agent Performance and Benchmarks[00:30:36] Speaker 3: Yeah, I have a couple of questions. So they're kind of paired, maybe. The first thing is that you said that You're estimating that your your agent is successfully resolving like something like 30 to 40 percent of your issues, but that's like below what you saw in Swebench.[00:30:52] Speaker 3: So I guess I'm wondering where that discrepancy is coming from. And then I guess my other second question, which is maybe broader in scope is that [00:31:00] like, if, if you think of an agent as like a junior developer, and I say, go do something, then I expect maybe tomorrow to get a Slack message being like, Hey, I ran into this issue.[00:31:10] Speaker 3: How can I resolve it? And, and, like you said, your agent is, like, successfully solving, like, 90 percent of issues where you give it direct feedback. So, are you thinking about how to get the agent to reach out to, like, for, for planning when it's, when it's stuck or something like that? Or, like, identify when it runs into a hole like that?[00:31:30] Speaker: Yeah, so great. These are great questions. Oh,[00:31:32] Speaker 3: sorry. The third question, which is a good, so this is the first two. And if so, are you going to add a benchmark for that second question?[00:31:40] Speaker: Okay. Great. Yeah. Great questions. Okay. So the first question was why do I think it's resolving less than 50 percent of the issues on Swebench?[00:31:48] Speaker: So first Swebench is on popular open source repos, and all of these popular open source repos were included in the training data for all of the language models. And so the language [00:32:00] models already know these repos. In some cases, the language models already know the individual issues in Swebench.[00:32:06] Speaker: So basically, like, some of the training data has leaked. And so it, it definitely will overestimate with respect to that. I don't think it's like, you know, Horribly, horribly off but I think, you know, it's boosting the accuracy by a little bit. So, maybe that's the biggest reason why. In terms of asking for help, and whether we're benchmarking asking for help yes we are.[00:32:29] Speaker: So one one thing we're working on now, which we're hoping to put out soon, is we we basically made SuperVig. Sweep edge issues. Like I'm having a, I'm having a problem with the matrix multiply. Please help. Because these are like, if anybody's run a popular open source, like framework, these are what half your issues are.[00:32:49] Speaker: You're like users show up and say like, my screen doesn't work. What, what's wrong or something. And so then you need to ask them questions and how to reproduce. So yeah, we're, we're, we're working on [00:33:00] that. I think. It, my impression is that agents are not very good at asking for help, even Claude. So like when, when they ask for help, they'll ask for help when they don't need it.[00:33:11] Speaker: And then won't ask for help when they do need it. So this is definitely like an issue, I think.[00:33:20] Speaker 4: Thanks for the great talk. I also have two questions.[00:33:23] Q&A: Web Agents and Interaction Methods[00:33:23] Speaker 4: It's first one can you talk a bit more about how the web agent interacts with So is there a VLM that looks at the web page layout and then you parse the HTML and select which buttons to click on? And if so do you think there's a future where there's like, so I work at Bing Microsoft AI.[00:33:41] Speaker 4: Do you think there's a future where the same web index, but there's an agent friendly web index where all the processing is done offline so that you don't need to spend time. Cleaning up, like, cleaning up these TML and figuring out what to click online. And any thoughts on, thoughts on that?[00:33:57] Speaker: Yeah, so great question. There's a lot of work on web [00:34:00] agents. I didn't go into, like, all of the details, but I think there's There's three main ways that agents interact with websites. The first way is the simplest way and the newest way, but it doesn't work very well, which is you take a screenshot of the website and then you click on a particular pixel value on the website.[00:34:23] Speaker: And Like models are not very good at that at the moment. Like they'll misclick. There was this thing about how like clawed computer use started like looking at pictures of Yellowstone national park or something like this. I don't know if you heard about this anecdote, but like people were like, oh, it's so human, it's looking for vacation.[00:34:40] Speaker: And it was like, no, it probably just misclicked on the wrong pixels and accidentally clicked on an ad. So like this is the simplest way. The second simplest way. You take the HTML and you basically identify elements in the HTML. You don't use any vision whatsoever. And then you say, okay, I want to click on this element.[00:34:59] Speaker: I want to enter text [00:35:00] in this element or something like that. But HTML is too huge. So it actually, it usually gets condensed down into something called an accessibility tree, which was made for screen readers for visually impaired people. And So that's another way. And then the third way is kind of a hybrid where you present the screenshot, but you also present like a textual summary of the output.[00:35:18] Speaker: And that's the one that I think will probably work best. What we're using is we're just using text at the moment. And that's just an implementation issue that we haven't implemented the. Visual stuff yet, but that's kind of like we're working on it now. Another thing that I should point out is we actually have two modalities for web browsing.[00:35:35] Speaker: Very recently we implemented this. And the reason why is because if you want to interact with full websites you will need to click on all of the elements or have the ability to click on all of the elements. But most of our work that we need websites for is just web browsing and like gathering information.[00:35:50] Speaker: So we have another modality where we convert all of it to markdown because that's like way more concise and easier for the agent to deal with. And then [00:36:00] can we create an index specifically for agents, maybe a markdown index or something like that would be, you know, would make sense. Oh, how would I make a successor to Swebench?[00:36:10] Speaker: So I mean, the first thing is there's like live code bench, which live code bench is basically continuously updating to make sure it doesn't leak into language model training data. That's easy to do for Swebench because it comes from real websites and those real websites are getting new issues all the time.[00:36:27] Speaker: So you could just do it on the same benchmarks that they have there. There's also like a pretty large number of things covering various coding tasks. So like, for example, Swebunch is mainly fixing issues, but there's also like documentation, there's generating tests that actually test the functionality that you want.[00:36:47] Speaker: And there there was a paper by a student at CMU on generating tests and stuff like that. So I feel like. Swebench is one piece of the puzzle, but you could also have like 10 different other tasks and then you could have like a composite [00:37:00] benchmark where you test all of these abilities, not just that particular one.[00:37:04] Speaker: Well, lots, lots of other things too, but[00:37:11] Speaker 2: Question from across. Use your mic, it will help. Um,[00:37:15] Speaker 5: Great talk. Thank you.[00:37:16] Q&A: Agent Architectures and Improvements[00:37:16] Speaker 5: My question is about your experience designing agent architectures. Specifically how much do you have to separate concerns in terms of tasks specific agents versus having one agent to do three or five things with a gigantic prompt with conditional paths and so on.[00:37:35] Speaker: Yeah, so that's a great question. So we have a basic coding and browsing agent. And I won't say basic, like it's a good, you know, it's a good agent, but it does coding and browsing. And it has instructions about how to do coding and browsing. That is enough for most things. Especially given a strong language model that has a lot of background knowledge about how to solve different types of tasks and how to use different APIs and stuff like that.[00:37:58] Speaker: We do have [00:38:00] a mechanism for something called micro agents. And micro agents are basically something that gets added to the prompt when a trigger is triggered. Right now it's very, very rudimentary. It's like if you detect the word GitHub anywhere, you get instructions about how to interact with GitHub, like use the API and don't browse.[00:38:17] Speaker: Also another one that I just added is for NPM, the like JavaScript package manager. And NPM, when it runs and it hits a failure, it Like hits in interactive terminals where it says, would you like to quit? Yep. Enter yes. And if that does it, it like stalls our agent for the time out until like two minutes.[00:38:36] Speaker: So like I added a new microagent whenever it started using NPM, it would Like get instructions about how to not use interactive terminal and stuff like that. So that's our current solution. Honestly, I like it a lot. It's simple. It's easy to maintain. It works really well and stuff like that. But I think there is a world where you would want something more complex than that.[00:38:55] Speaker 5: Got it. Thank you.[00:38:59] Speaker 6: I got a [00:39:00] question about MCP. I feel like this is the Anthropic Model Context Protocol. It seems like the most successful type of this, like, standardization of interactions between computers and agents. Are you guys adopting it? Is there any other competing standard?[00:39:16] Speaker 6: Anything, anything thought about it?[00:39:17] Speaker: Yeah, I think the Anth, so the Anthropic MCP is like, a way to It, it's essentially a collection of APIs that you can use to interact with different things on the internet. I, I think it's not a bad idea, but it, it's like, there's a few things that bug me a little bit about it.[00:39:40] Speaker: It's like we already have an API for GitHub, so why do we need an MCP for GitHub? Right. You know, like GitHub has an API, the GitHub API is evolving. We can look up the GitHub API documentation. So it seems like kind of duplicated a little bit. And also they have a setting where [00:40:00] it's like you have to spin up a server to serve your GitHub stuff.[00:40:04] Speaker: And you have to spin up a server to serve your like, you know, other stuff. And so I think it makes, it makes sense if you really care about like separation of concerns and security and like other things like this, but right now we haven't seen, we haven't seen that. To have a lot more value than interacting directly with the tools that are already provided.[00:40:26] Speaker: And that kind of goes into my general philosophy, which is we're already developing things for programmers. You know,[00:40:36] Speaker: how is an agent different than from a programmer? And it is different, obviously, you know, like agents are different from programmers, but they're not that different at this point. So we can kind of interact with the interfaces we create for, for programmers. Yeah. I might change my mind later though.[00:40:51] Speaker: So we'll see.[00:40:54] Speaker 7: Yeah. Hi. Thanks. Very interesting talk. You were saying that the agents you have right now [00:41:00] solve like maybe 30 percent of your, your issues out of the gate. I'm curious of the things that it doesn't do. Is there like a pattern that you observe? Like, Oh, like these are the sorts of things that it just seems to really struggle with, or is it just seemingly random?[00:41:15] Speaker: It's definitely not random. It's like, if you think it's more complex than it's. Like, just intuitively, it's more likely to fail. I've gotten a bit better at prompting also, so like, just to give an example it, it will sometimes fail to fix a GitHub workflow because it will not look at the GitHub workflow and understand what the GitHub workflow is doing before it solves the problem.[00:41:43] Speaker: So I, I think actually probably the biggest thing that it fails at is, um, er, that our, our agent plus Claude fails at is insufficient information gathering before trying to solve the task. And so if you provide all, if you provide instructions that it should do information [00:42:00] gathering beforehand, it tends to do well.[00:42:01] Speaker: If you don't provide sufficient instructions, it will try to solve the task without, like, fully understanding the task first, and then fail, and then you need to go back and give feedback. You know, additional feedback. Another example, like, I, I love this example. While I was developing the the monitor website that I, I showed here, we hit a really tricky bug where it was writing out a cache file to a different directory than it was reading the cache file from.[00:42:26] Speaker: And I had no idea what to do. I had no idea what was going on. I, I thought the bug was in a different part of the code, but what I asked it to do was come up with five possible reasons why this could be failing and decreasing order of likelihood and examine all of them. And that worked and it could just go in and like do that.[00:42:44] Speaker: So like I think a certain level of like scaffolding about like how it should sufficiently Gather all the information that's necessary in order to solve a task is like, if that's missing, then that's probably the biggest failure point at the moment. [00:43:00][00:43:01] Speaker 7: Thanks.[00:43:01] Speaker 6: Yeah.[00:43:06] Speaker 6: I'm just, I'm just using this as a chance to ask you all my questions.[00:43:09] Q&A: Self-Improving Agents and Authentication[00:43:09] Speaker 6: You had a, you had a slide on here about like self improving agents or something like that with memory. It's like a really throwaway slide for like a super powerful idea. It got me thinking about how I would do it. I have no idea how.[00:43:21] Speaker 6: So I just wanted you to chain a thought more on this.[00:43:25] Speaker: Yeah, self, self improving. So I think the biggest reason, like the simplest possible way to create a self improving agent. The problem with that is to have a really, really strong language model that with infinite context, and it can just go back and look at like all of its past experiences and, you know, learn from them.[00:43:46] Speaker: You might also want to remove the bad stuff just so it doesn't over index on it's like failed past experiences. But the problem is a really powerful language model is large. Infinite context is expensive. We don't have a good way to [00:44:00] index into it because like rag, Okay. At least in my experience, RAG from language to code doesn't work super well.[00:44:08] Speaker: So I think in the end, it's like, that's the way I would like to solve this problem. I'd like to have an infinite context and somehow be able to index into it appropriately. And I think that would mostly solve it. Another thing you can do is fine tuning. So I think like RAG is one way to get information into your model.[00:44:23] Speaker: Fine tuning is another way to get information into your model. So. That might be another way of continuously improving. Like you identify when you did a good job and then just add all of the good examples into your model.[00:44:34] Speaker 6: Yeah. So, you know, how like Voyager tries to write code into a skill library and then you reuse as a skill library, right?[00:44:40] Speaker 6: So that it improves in the sense that it just builds up the skill library over time.[00:44:44] Speaker: Yep.[00:44:44] Speaker 6: One thing I was like thinking about and there's this idea of, from, from Devin, your, your arch nemesis of playbooks. I don't know if you've seen them.[00:44:52] Speaker: Yeah, I mean, we're calling them workflows, but they're simpler.[00:44:55] Speaker 6: Yeah, so like, basically, like, you should, like, once a workflow works, you can kind of, [00:45:00] like, persist them as a skill library. Yeah. Right? Like I, I feel like that there's a, that's like some in between, like you said, you know, it's hard to do rag between language and code, but I feel like that is ragged for, like, I've done this before, last time I did it, this, this worked.[00:45:14] Speaker 6: So I'm just going to shortcut. All the stuff that failed before.[00:45:18] Speaker: Yeah, I totally, I think it's possible. It's just, you know, not, not trivial at the same time. I'll explain the two curves. So basically, the base, the baseline is just an agent that does it from scratch every time. And this curve up here is agent workflow memory where it's like adding the successful experiences back into the prompt.[00:45:39] Speaker: Why is this improving? The reason why is because just it failed on the first few examples and for the average to catch up it, it took a little bit of time. So it's not like this is actually improving it. You could just basically view the this one is constant and then this one is like improving.[00:45:56] Speaker: Like this, basically you can see it's continuing to go [00:46:00] up.[00:46:01] Speaker 8: How do you think we're going to solve the authentication problem for agents right now?[00:46:05] Speaker: When you say authentication, you mean like credentials, like, yeah.[00:46:09] Speaker 8: Yeah. Cause I've seen a few like startup solutions today, but it seems like it's limited to the amount of like websites or actual like authentication methods that it's capable of performing today.[00:46:19] Speaker: Yeah. Great questions. So. My preferred solution to this at the moment is GitHub like fine grained authentication tokens and GitHub fine grained authentication tokens allow you to specify like very free. On a very granular basis on this repo, you have permission to do this, on this repo, you have permission to do this.[00:46:41] Speaker: You also can prevent people from pushing to the main branch unless they get approved. You can do all of these other things. And I think these were all developed for human developers. Or like, the branch protection rules were developed for human developers. The fine grained authentication tokens were developed for GitHub apps.[00:46:56] Speaker: I think for GitHub, maybe [00:47:00] just pushing this like a little bit more is the way to do this. For other things, they're totally not prepared to give that sort of fine grained control. Like most APIs don't have something like a fine grained authentication token. And that goes into my like comment that we're going to need to prepare the world for agents, I think.[00:47:17] Speaker: But I think like the GitHub authentication tokens are like a good template for how you could start doing that maybe, but yeah, I don't, I don't, I don't have an answer.[00:47:25] Speaker 8: I'll let you know if I find one.[00:47:26] Speaker: Okay. Yeah.[00:47:31] Live Demonstration and Closing Remarks[00:47:31] Speaker: I'm going to finish up. Let, let me just see.[00:47:37] Speaker: Okay. So this one this one did write a script. I'm not going to actually read it for you. And then the other one, let's see.[00:47:51] Speaker: Yeah. So it sent a PR, sorry. What is, what is the PR URL?[00:48:00][00:48:02] Speaker: So I don't, I don't know if this sorry, that's taking way longer than it should. Okay, cool. Yeah. So this one sent a PR. I'll, I'll tell you later if this actually like successfully Oh, no, it's deployed on Vercel, so I can actually show you, but let's, let me try this real quick. Sorry. I know I don't have time.[00:48:24] Speaker: Yeah, there you go. I have pie charts now. So it's so fun. It's so fun to play with these things. Cause you could just do that while I'm giving a, you know, talk and things like that. So, yeah, thanks. Get full access to Latent Space at www.latent.space/subscribe

Python 3.13 (click here to comment) 12. November 2024, Jochen

Marion, Charly et Mathis vous présente yap sèche avec des découvertes musicales émergentes exentriques tout comme eux!   Liste des chansons diffusées :  She's back, Pypy Ga, Princesses Starburster, Fontaines DC Sans-toi, Passion Poire Baddy on the floor, Jamie xx Chocolat Chaud, Brown Family Messie, Zouz

Montreal-based PYPY's second album, 10 years after their first, is an exhilarating blend of psych rock and new wave, with virtuosic instrumentals and otherworldly vocals. We discuss “Sacred Times” on Episode #221 of For the Record.

Oof, no episode in April, huh? Yeah, we're getting close to Python 3.13 beta 1. PyCon US is also coming up real soon. Let's use this opportunity then to talk about a feature we're teaming up on: a better interactive interpreter! ## Outline (00:00:00)  INTRO (00:01:53)  PART 1: History of Terminals (00:03:20)  /dev/tty (00:04:51)  The first cool word (00:05:45)  Chrząszcz (00:06:20)  Control code characters in ASCII (00:11:54)  PART 2: Python REPL Today (00:12:34)  There is no REPL (00:15:28)  So what is there instead? (00:19:13)  readline (00:25:38)  Source in the REPL (00:31:13)  Implementing a REPL from scratch? Prepare to support arg: 5 (00:36:09)  PART 3: PR OF THE WEEK (00:37:09)  Introducing: Complaining Pablo (00:38:23)  Tests are always green if you skip them (00:39:57)  Getting dirty with escape sequences (00:41:28)  Typing finds bugs (00:42:29)  Shiny new features of the new REPL (00:45:55)  Contributing back to PyPy (00:48:10)  We still have two weeks, right? (00:49:59)  Is Python synthwave enough? (00:51:57)  Do we have a bug? (00:55:31)  What's lurking in pydoc? (00:59:38)  PART 4: WHAT'S HAPPENING IN CPYTHON? (01:02:39)  PEP 744: The JIT (01:06:05)  Incremental GC is now actually in (01:08:21)  Tier 2 interpreter updates (01:10:29)  Python supported on iOS with PEP 730 (01:13:11)  Better error messages for name shadowing (01:15:17)  Queue.shutdown() (01:17:14)  ctypes adopts heap types (01:18:26)  Free-threading updates (01:20:14)  Dataclass creation is faster (01:20:44)  OUTRO

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 23/12 a 05/01.

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 23/12 a 05/01.

In this episode, we are joined by Steven, the CTO of PubNub, a company that has developed an edge net messaging network with over a billion connected devices. Steven explains that while message buses like Kafka or RabbitMQ are suitable for smaller scales, PubNub focuses on the challenges of connecting mobile devices and laptops at a web scale. They aim to provide instant signal delivery at a massive scale, prioritizing low latency for a seamless user experience. To achieve this, PubNub has architected their system to be globally distributed, running on AWS with Kubernetes clusters spread across all of Amazon's zones. They utilize GeoDNS to ensure users connect to the closest region for the lowest latency possible. Steven goes on to discuss the challenges they faced in building their system, particularly in terms of memory management and cleanup. They had to deal with issues such as segmentation faults and memory leaks, which caused runtime problems, outages, and potential data loss. PubNub had to invest in additional memory to compensate for these leaks and spend time finding and fixing the problems. While C was efficient, it came with significant engineering costs. As a solution, PubNub started adopting Rust, which helped alleviate some of these challenges. When they replaced a service with Rust, they observed a 5x improvement in memory and performance. Steven also talks about choosing programming languages for their platform and the difficulties in finding and retaining C experts. They didn't consider Java due to its perceived academic nature, and Go didn't make the list of options at the time. However, they now have services in production written in Go, though rewriting part of their PubSub bus in Go performed poorly compared to their existing C system. Despite this, they are favoring Rust as their language of choice for new services, citing its popularity and impressive results. The conversation delves into performance considerations with Python and the use of PyPy as a just-in-time compiler for optimization. While PyPy improved performance, it also required a lot of memory, which could be expensive. On the other hand, Rust provided a significant boost in both memory and performance, making it a favorable choice for PubNub. They also discuss provisioning, taking into account budget and aiming to be as close to what they need as possible. Kubernetes and auto scaling with HPAs (Horizontal Pod Autoscaling) are used to dynamically adjust resources based on usage. Integrating new services into PubNub's infrastructure involves both API-based communication and event-driven approaches. They use frameworks like Axiom for API-based communication and leverage Kafka with Protobuf for event sourcing. JSON is also utilized in some cases. Steven explains that they chose Protobuf for high-traffic topics and where stability is crucial. While the primary API for customers is JSON-based, PubNub recognizes the superior performance of Protobuf and utilizes it for certain cases, especially for shrinking down large character strings like booleans. They also discuss the advantages of compression enabled with Protobuf. The team reflects on the philosophy behind exploring Rust's potential for profit and its use in infrastructure and devices like IoT. Rust's optimization for smaller binaries is highlighted, and PubNub sees it as their top choice for reliability and performance. They mention developing a Rust SDK for customers using IoT devices. The open-source nature of Rust and its ability to integrate into projects and develop open standards are also praised. While acknowledging downsides like potential instabilities and longer compilation time, they remain impressed with Rust's capabilities. The conversation covers stability and safety in Rust, with the speaker expressing confidence in the compiler's ability to handle alpha software and packages. Relying on native primitives for concurrency in Rust adds to the speaker's confidence in the compiler's safety. The Rust ecosystem is seen as providing adequate coverage, although packages like libRDKafka, which are pre-1.0, can be challenging to set up or deploy. The speaker emphasizes simplicity in code and avoiding excessive abstractions, although they acknowledge the benefits of features like generics and traits in Rust. They suggest resources like a book by David McCloyd that focuses on learning Rust without overwhelming complexity. Expanding on knowledge sharing within the team, Stephen discusses how Rust advocates within the team have encouraged its use and the possibilities it holds for AI infrastructure platforms. They believe Rust could improve performance and reduce latency, particularly for CPU tasks in AI. They mention the adoption of Rust in the data science field, such as its use in the Parquet data format. The importance of tooling improvements, setting strict standards, and eliminating unsafe code is highlighted. The speaker expresses the desire for a linter that enforces a simplified version of Rust to enhance code readability, maintainability, and testability. They discuss the balance between functional and object-oriented programming in Rust, suggesting object-oriented programming for larger-scale code structure and functional paradigms within functions. Onboarding Rust engineers is also addressed, considering whether to prioritize candidates with prior Rust experience or train individuals skilled in another language on the job. Recognizing the shortage of Rust engineers, Stephen encourages those interested in Rust to pursue a career at PubNub, pointing to resources like their website and LinkedIn page for tutorials and videos. They emphasize the importance of latency in their edge messaging technology and invite users to try it out.

Topics covered in this episode: Psycopg 3 dacite RIP: Fast, barebones pip implementation in Rust Flaky Tests follow up Extras Joke Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training The Complete pytest Course Patreon Supporters Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesdays at 11am PT. Older video versions available there too. Brian #1: Psycopg 3 Psycopg folks recommend starting with 3 for new projects 2 is still actively maintained, but no new features are planned recommend staying with 2 for legacy projects Psycopg 3 project 2 vs 3 feature comparison A few Psycopg 3 highlights native asyncio support native support for more Python types (such as Enums) and PostgreSQL types (such as multirange) Default server-side parameters binding Allows binary parameters and query results (and text, of course) Pipeline/batch mode support Static typing support Michael #2: dacite via Raymond Peck Simple creation of data classes from dictionaries Dacite supports following features: nested structures (basic) types checking optional fields (i.e. typing.Optional) unions forward references collections custom type hooks It's important to mention that dacite is not a data validation library. Type hooks are interesting too. Brian #3: RIP: Fast, barebones pip implementation in Rust list of current and planned features of RIP, the biggest are listed below: Downloading and aggressive caching of PyPI metadata. (done) Resolving of PyPI packages using Resolvo. (done) Installation of wheel files (planned) Support sdist files (planned) new project, just a couple weeks old. … “We would love to have you contribute!” Michael #4: Flaky Tests follow up by Marwan Sarieddine I was inspired by the Talk Python podcast on "Taming flaky tests" with Gregory Kapfhammer and Owain Parry so I wrote up an article on my blog titled "How not to footgun yourself when writing tests - a showcase of flaky tests” Extras Brian: Just wrapping up some personal projects, which means… Python People episodes soon Python Test episodes soon (but later) More course chapters coming Michael: PyBay 2023 was fun Switched to Spark Mail, recommended Dust (what science fiction story telling should be), try: FTL Oceanus Joke: There are more hydrogen atoms in a single molecule of water than there are stars in the entire Solar System. - mas.to/@SmudgeTheInsultCat/111174610011921264 The Big Rewrite

Tel un prisme, Josélito Michaud comprend de multiples facettes que l'émission propose de faire découvrir au grand public grâce à la richesse des parcours de vie de chacun. C'est ainsi qu'au fil des semaines, autour d'un micro, Riff Tabaracci est son équipe replongent à tour de rôle dans le récit courageux de leur processus de guérison intérieure et se livrent avec beaucoup d'émotion, d'authenticité et de courage.

Want to help define the AI Engineer stack? Have opinions on the top tools, communities and builders? We're collaborating with friends at Amplify to launch the first State of AI Engineering survey! Please fill it out (and tell your friends)!If AI is so important, why is its software so bad?This was the motivating question for Chris Lattner as he reconnected with his product counterpart on Tensorflow, Tim Davis, and started working on a modular solution to the problem of sprawling, monolithic, fragmented platforms in AI development. They announced a $30m seed in 2022 and, following their successful double launch of Modular/Mojo

What are all the different versions of Python? You may have heard of Cython, Brython, PyPy, or others and wondered where they fit into the Python landscape. This week on the show, Christopher Trudeau is here, bringing another batch of PyCoder's Weekly articles and projects.

Negli ultimi mesi abbiamo parlato di python e del suo sbarco nel mondo del browser. Questa settimana lo abbiamo fatto in modo piu strutturato con uno dei sui contributor. Abbiamo con noi Antonio Cuni direttamente da Anaconda. ## Supportaci suhttps://www.gitbar.it/support ## Paese dei balocchi - https://amzn.to/3HRClOi - https://www.youtube.com/watch?... ## Link amazon affiliatohttps://amzn.to/3XDznm1 ## Contatti @brainrepo su twitter o via mail a https://gitbar.it. ## Crediti Le sigle sono state prodotte da MondoComputazionale Le musiche da Blan Kytt - RSPN Sweet Lullaby by Agnese Valmaggia Monkeys Spinning Monkeys by Kevin MacLeod

PyPy - Just in Time 27. Januar 2023, Jochen Warum ist der Python Interpreter eigentlich nicht selbst in Python geschrieben? Vor ziemlich genau zwanzig Jahren wurde ein Projekt gestartet, um das zu ändern. Eine gute Gelegenheit für Dominik und Jochen mit Carl Friedrich, einem der Core-Entwickler von PyPy zu sprechen.Wenn ihr Lust bekommen habt, einmal selbst an PyPy herum zu schrauben, könnt ihr die Entwickler hier kontaktieren oder euch einfach direkt bei Carl Friedrich melden

Watch on YouTube About the show Sponsored by Microsoft for Startups Founders Hub. Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Michael #1: StackOverflow 2022 Developer Survey Last year we saw Git as a fundamental tool to being a developer. This year it appears that Docker is becoming a similar fundamental tool for Professional Developers, increasing from 55% to 69%. Language: Rust is […] the most loved language with 87% of developers saying they want to continue using it. JS Frameworks: Angular.js is in its third year as the most dreaded. Let me Google that for you: 62% of all respondents spend more than 30 minutes a day searching for answers or solutions to problems. 25% spending more than an hour each day. The demise of the full-stack developer is overrated. I do wish there were more women in the field. Databases: Postgres is #1 and MongoDB is still going strong. The “which web framework do you use?” question is a full on train wreck. Why is this so hard for people to write the question? Node.js or Express (built on Node) vs. FastAPI or Flask (but no Python?) Most wanted / loved language is Rust (wanted) and Python/Rust tied for most wanted. Worked with vs. want to work with has some interesting graphics. Brian #2: PePy.tech - PyPI download stats with package version breakdown Petru Rares Sincraian We've discussed pypistats.org before, which highlights daily downloads downloads per major/minor Python version downloads per OS PyPy is a bit more useful for me default shows last few versions and total for this major version “select versions” box is editable. clicking in it shows dropdown with downloads per version already there you can add * for graph of total or other major versions if you want to compare daily/weekly/monthly is nice, to round out some noise and see larger trends Oddity I noticed - daily graph isn't the same dates as the table. off by a day on both sides not a big deal, but I notice these kinds of things. Michael #3: Codon Python Compiler via Jeff Hutchins and Abdulaziz Alqasem A high-performance, zero-overhead, extensible Python compiler using LLVM You can scale performance and produce executables, even when using third party libraries such as matplotlib. It also supports writing and executing GPU kernels, which is an interesting feature. See how it works at exaloop.io BTW, really terrible licensing. Free for non-commercial (great) “Contact us” for commercial use (it's fine to charge, but give us a price) Brian #4: 8 Levels of Using Type Hints in Python Yang Zhou (yahng cho) A progression of using type hints that seems to track how I've picked them up Type Hints for Basic Data Types. x: int Define a Constant Using Final Type DB: Final = '``PostgreSQL' (ok. I haven't used this one at all yet) Adding multipe type hints to one variable. int | None Using general type hints. def func(nums: Iterable) Also using Optional Type hints for functions def func(name: str) → str: (I probably would put this at #2) Alias of type hints (not used this yet, but looks cool) PostsType = dict[int, str] new_posts: PostsType = {1: 'Python Type Hints', 2: 'Python Tricks'} Type hints for a class itself, i.e. Self type from typing import Self class ListNode: def __init__(self, prev_node: Self) -> None: pass Provide literals for a variable. (not used this yet, but looks cool) from typing import Literal weekend_day: Literal['Saturday', 'Sunday'] weekend_day = 'Saturday' weekend_day = 'Monday' # will by a type error Extras Brian: I hear a heartbeat for Test & Code, so it must not be dead yet. Michael: New article: Welcome Back RSS From this I learned about Readwise, Kustosz, and Python's reader. Year progress == 100% PyTorch discloses malicious dependency chain compromise over holidays (of course found over RSS and reeder — see article above) Joke: vim switch

There have been a number of attacks in the last few years on source code. In fact, I saw a new one this week for an e-commerce Wordpress plugin. This time hackers got access to the distribution server for the company, Fishpig, and altered the plug-ins that their customers download. A few years ago this was big news, with the SolarWinds exploit. There was also an attack on PyPy, a popular Python package that many people include in their code.  There have been no shortages of problems in npm packages as well. I'm sure this has happened in other software packages, which is scary. In the days of DevOps where we publish code from a repository, an exploit against your developers might go unnoticed. Then again, maybe not. Read the rest of Code Supply Chain Security

An airhacks.fm conversation with Fabio Niephaus (@fniephaus) about: enjoying lego mindstorms, learning python, then Java, pencils and mice, using bluej, lejos - Java for lego, building extension for PHP fusion, enjoying SmallTalk, PyPy and GraalVM, rpyhton (restricted python) toolchain, AOT compilation, Java BeanShell, bringing SmallTalk to other languages with PyPy, Java on Truffle - espresso, combining multiple interpreters in one JVM, Hasso-Plattner-Institut in Potsdam, self-sustaining programming system, Truffle Native Function Interface, TruffleSqueak, RSqueak/VM, GraalVM Dashboard, Paper on Polyglot VM built with RPython, RPython Toolchain, GraalVM Reachability Metadata Repository, using GraalVM with Github Actions. GitHub Action for GraalVM, GraalVM 22.2 release blog post, New GraalVM reachability metadata repository, source level debugging with native images, continuous native image build tracking, Embedding Truffle Languages by Kevin Menard Fabio Niephaus on twitter: @fniephaus

PyPy is a fast, compliant alternative implementation of Python. cPython is implemented in C. PyPy is implemented in Python. What does that mean? And how do you test something as huge as an alternative implementation of Python? Special Guest: Carl Friedrich Bolz-Tereick.

(収録日: 2021/11/27) # 感想はtwitterでハッシュタグ「#secure旅団 #secureLiaison」やGoogle Formにいただけると嬉しいです。 # 内容 年末に向けて経済活動回してるよって話 BIMIの話 Emotet復活の話を少々とメールというプロトコルのユースケース PyPyのパッケージ汚染(11/18) セッションごととかにセキュリティ強弱をつける話（CAEP / Shared Signals and Events WG) OSSFのAllstartとかScore Cards runtimeのauditの話: Secure Namespaced Kernel Audit for Containers Redashの脆弱性の話とGithub Security Advisory 身代金払わず2億円で新システム　徳島サイバー被害病院 ブラックフライデーの話とPS5欲しいって話 # 参加者: 名無しさん、ykyanさん, @ken5scal # BGM: "A Fool in Love" by Imprismed ジングル: @hajipion

Drive Like Jehu was an American post-hardcore band from San Diego active from 1990 to 1995. It was formed by rhythm guitarist and vocalist Rick Froberg and lead guitarist John Reis, ex-members of Pitchfork, along with bassist Mike Kennedy and drummer Mark Trombino, both from Night Soil Man, after their two bands disbanded in 1990. Drive Like Jehu's music was characterized by passionate singing, unusual song structure, indirect melodic themes, intricate guitar playing, and calculated use of tension, resulting in a distinctive sound amongst other post-hardcore acts and helped to catalyze the evolution of hardcore punk into emo. In this episode all songs by bands selected by Drive Like Jehu to play All Tomorrow's Parties 2.0 April 22-24, 2016. Lineup: Hot Snakes, The Blind Shake, Mrs. Magician, Flamin' Groovies, The King Khan & BBQ Show, The Schizophonics, Metz, Mission Of Burma, The Gories, King Khan and the Shrines, The Spits, Rocket From The Crypt, Betunizer, The Monkeywrench, Holly Golightly, Dan Sartain, Martin Rev, Tortoise, The Ex, PyPy, Gary Wilson, Claw Hammer, Wau y Los Arrrghs

Guido van Rossum is the creator of the Python programming language and a Distinguished Engineer at Microsoft. Apple Podcasts | Spotify | Google PodcastsWe discuss Guido’s new work on making CPython faster (PEP 659), Tiers of Python Interpreter Execution, and high impact, low hanging fruit performance improvements.Highlights(an edited summary)[00:21] What got you interested in working on Python performance?Guido: In some sense, it was probably a topic that was fairly comfortable to me because it means working with a core of Python, where I still feel I know my way around. When I started at Microsoft, I briefly looked at Azure but realized I never enjoyed that kind of work at Google or Dropbox. Then I looked at Machine Learning, but it would take a lot of time to do something interested with the non-Python, and even Python-related bits.[02:31] What was different about the set of Mark Shannon’s ideas on Python performance that convinced you to go after them?Guido: I liked how he was thinking about the problem. Most of the other approaches around Python performance like PyPy and Cinder are not suitable for all use cases since they aren’t backward compatible with extension modules. Mark has the perspective and experience of a CPython developer, as well as a viable approach that would maintain backward compatibility, which is the hardest problem to solve. The Python Bytecode interpreter is modified often across minor releases (for eg: 3.8 → 3.9) for various reasons like new opcodes, so modifying that is a relatively safe approach. Utsav: [09:45] Could you walk us through the idea of the tiers of execution of the Python Interpreter?Guido: When you execute a program, you don't know if it's going to crash after running a fraction of a millisecond, or whether it's going to be a three-week-long computation. Because it could be the same code, just in the first case, it has a bug. And so, if it takes three weeks to run the program, maybe it would make sense to spend half an hour ahead of time optimizing all the code that's going to be run. But obviously, especially in dynamic languages like Python, where we do as much as we can without asking the user to tell us exactly how they need it done, you just want to start executing code as quickly as you can. So that if it's a small script, or a large program that happens to fail early, or just exits early for a good reason, you don't spend any time being distracted by optimizing all that code.So, what we try to do there is keep the bytecode compiler simple so that we get to execute the beginning of the code as soon as possible. If we see that certain functions are being executed many times over, then we call that a hot function, and some definition of “hot”. For some purposes, maybe it's a hot function if it gets called more than once, or more than twice, or more than 10 times. For other purposes, you want to be more conservative, and you can say, “Well, it's only hot if it's been called 1000 times.”The specializing adaptive compiler (PEP 659) then tries to replace certain bytecodes with bytecodes that are faster, but only work if the types of the arguments are specific types. A simple hypothetical example is the plus operator in Python. It can add lots of things like integers, strings, lists, or even tuples. On the other hand, you can't add an integer to a string. So, the optimization step - often called quickening, but usually in our context, we call it specializing - is to have a separate “binary add” integer bytecode, a second-tier bytecode hidden from the user. This opcode assumes that both of its arguments are actual Python integer objects, reaches directly into those objects to find the values, adds those values together in machine registers, and pushes the result back on the stack. The binary adds integer operation still has to make a type check on the arguments. So, it's not completely free but a type check can be implemented much faster than a sort of completely generic object-oriented dispatch, like what normally happens for most generic add operations. Finally, it's always possible that a function is called millions of times with integer arguments, and then suddenly a piece of data calls it with a floating-point argument, or something worse. At that point, the interpreter will simply execute the original bytecode. That's an important part so that you still have the full Python semantics.Utsav [18:20] Generally you hear of these techniques in the context of JIT, a Just-In-Time compiler, but that’s not being implemented right now.Just-In-Time compilation has a whole bunch of emotional baggage with it at this point that we're trying to avoid. In our case, it’s unclear what and when we’re exactly compiling. At some point ahead of program execution, we compile your source code into bytecode. Then we translate the bytecode into specialized bytecode. I mean, everything happens at some point during runtime, so which part would you call Just-In-Time? Also, it’s often assumed that Just-In-Time compilation automatically makes all your code better. Unfortunately, you often can't actually predict what the performance of your code is going to be. And we have enough of that with modern CPUs and their fantastic branch prediction. For example, we write code in a way that we think will clearly reduce the number of memory accesses. When we benchmark it, we find that it runs just as fast as the old unoptimized code because the CPU figured out access patterns without any of our help. I wish I knew what went on in modern CPUs when it comes to branch prediction and inline caching because that is absolute magic. Full TranscriptUtsav: [00:14] Thank you, Guido, for joining me on another episode of the Software at Scale podcast. It's great to have you here. Guido: [00:20] Great to be here on the show. Utsav: [00:21] Yeah. And it's just fun to talk to you again. So, the last time we spoke was at Dropbox many, many years ago. And you got retired, and then you decided that you wanted to do something new. And you work on performance now at Microsoft, and that's amazing. So, to start off with, I just want to ask you, you could pick any project that you wanted to, based on some slides that I've seen. So, what got you interested in working on Python performance?Guido: [00:47] In some sense, it was probably a topic that was fairly comfortable to me because it means working with a core of Python, where I still feel I know my way around. Some other things I considered briefly in my first month at Microsoft, I looked into, “Well, what can I do with Azure?”, and I almost immediately remembered that I was not cut out to be a cloud engineer. That was never the fun part of my job at Dropbox. It wasn't the fun part of my job before that at Google either. And it wouldn't be any fun to do that at Microsoft. So, I gave up on that quickly. I looked in machine learning, which I knew absolutely nothing about when I joined Microsoft. I still know nothing, but I've at least sat through a brief course and talked to a bunch of people who know a lot about it. And my conclusion was actually that it's a huge field. It is mostly mathematics and statistics and there is very little Python content in the field. And it would take me years to do anything interesting with the non-Python part and probably even with the Python part, given that people just write very simple functions and classes, at best in their machine learning code. But at least I know a bit more about the terminology that people use. And when people say kernel, I now know what they mean. Or at least I'm not confused anymore as I was before.Utsav: [02:31] That makes sense. And that is very similar to my experience with machine learning. Okay, so then you decided that you want to work on Python performance, right? And then you are probably familiar with Mark Shannon's ideas?Guido: [02:43] Very much so. Yeah.Utsav: [02:44] Yeah. So, was there anything different about the set of ideas that you decided that this makes sense and I should work on a project to implement these ideas?Guido: [02:55] Mark Shannon's ideas are not unique, perhaps, but I know he's been working on for a long time. I remember many years ago, I went to one of the earlier Python UK conferences, where he gave a talk about his PhD work, which was also about making Python faster. And over the years, he's never stopped thinking about it. And he sort of has a holistic attitude about it. Obviously, the results remain to be seen, but I liked what he was saying about how he was thinking about it. And if you take PyPy, it has always sounded like PyPy is sort of a magical solution that only a few people in the world understand how it works. And those people built that and then decided to do other things. And then they left it to a team of engineers to solve the real problems with PyPy, which are all in the realm of compatibility with extension modules. And they never really solved that. [04:09] So you may remember that there was some usage of PyPy at Dropbox because there was one tiny process where someone had discovered that PyPy was actually so much faster that it was worth it. But it had to run in its own little process and there was no maintenance. And it was a pain, of course, to make sure that there was a version of PyPy available on every machine. Because for the main Dropbox application, we could never switch to PyPy because that depended on 100 different extension modules. And just testing all that code would take forever. [04:49] I think since we're talking about Dropbox, Pyston was also an interesting example. They've come back actually; you've probably heard that. The Pyston people were much more pragmatic, and they've learned from PyPy’s failures. [05:04] But they have always taken this attitude of, again, “we're going to start with CPython,” which is good because that way they are sort of guaranteed compatibility with extension modules. But still, they make these huge sets of changes, at least Pyston one, and they had to roll back a whole bunch of things because, again, of compatibility issues, where I think one of the things, they had a bunch of very interesting improvements to the garbage collection. I think they got rid of the reference counting, though. And because of that, the behavior of many real-world Python programs was completely changed. [05:53] So why do I think that Mark's work will be different or Mark's ideas? Well, for one, because Mark has been in Python core developer for a long time. And so, he knows what we're up against. He knows how careful we have with backwards compatibility. And he knows that we cannot just say get rid of reference counting or change the object layout. Like there was a project that was recently released by Facebook basically, was born dead, or at least it was revealed to the world in its dead form, CI Python (Cinder), which was a significantly faster Python implementation, but using sort of many of the optimizations came from changes in object layout that just aren't compatible with extension modules. And Mark has sort of carved out these ideas that work on the bytecode interpreter itself. [06:58] Now, the bytecode is something where we know that it's not going to sort of affect third-party extension modules too much if we change it, because the bytecode changes in every Python release. And internals of the interpreter of the bytecode interpreter, change in every Python release. And yes, we still run into the occasional issue. Every release, there is some esoteric hack that someone is using that breaks. And they file an issue in the bug tracker because they don't want to research or they haven't yet researched what exactly is the root cause of the problem, because all they know is their users say, “My program worked in Python 3.7, and it broke in Python 3.8. So clearly, Python 3.8 broke something.” And since it only breaks when we're using Library X, it must be maybe Library X's fault. But Library X, the maintainers don't know exactly what's going on because the user just says it doesn't work or give them a thousand-line traceback. And they bounce it back to core Python, and they say, “Python 3.8 broke our library for all our users, or 10% of our users,” or whatever. [08:16] And it takes a long time to find out, “Oh, yeah, they're just poking inside one of the standard objects, using maybe information they gleaned from internal headers, or they're calling a C API that starts with an underscore.” And you're not supposed to do that. Well, you can do that but then you pay the price, which is you have to fix your code at every next Python release. And in between, sort of for bug fix releases like if you go from 3.8.0 to 3.8.1, all the way up to 3.8.9, we guarantee a lot more - the bytecodes stay stable. But 3.9 may break all your hacks and it changes the bytecode. One thing we did I think in 3.10, was all the jumps in the bytecode are now counted in instructions rather than bytes, and instructions are two bytes. Otherwise, the instruction format is the same, but all the jumps jump a different distance if you don't update your bytecode. And of course, the Python bytecode compiler knows about this. But people who generate their own bytecode as a sort of the ultimate Python hack would suffer.Utsav: [09:30] So the biggest challenge by far is backwards compatibility.Guido: [09:34] It always is. Yeah, everybody wants their Python to be faster until they find out that making it faster also breaks some corner case in their code.Utsav: [09:45] So maybe you can walk us through the idea of the tiers of execution or tiers of the Python interpreter that have been described in some of those slides.Guido: [09:54] Yeah, so that is a fairly arbitrary set of goals that you can use for most interpreted languages. Guido: [10:02] And it's actually a useful way to think about it. And it's something that we sort of plan to implement, it's not that there are actually currently tiers like that. At best, we have two tiers, and they don't map perfectly to what you saw in that document. But the basic idea is-- I think this also is implemented in .NET Core. But again, I don't know if it's sort of something documented, or if it's just this is how their optimizer works. So, when you just start executing a program, you don't know if it's going to crash after running a fraction of a millisecond, or whether it's going to be a three-week-long computation. Because it could be the same code, just in the first case, it has a bug. And so, if it takes three weeks to run the program, maybe it would make sense to spend half an hour ahead of time optimizing all the code that's going to be run. But obviously, especially in dynamic language, and something like Python, where we do as much as we can without asking the user to tell us exactly how they need it done, you just want to start executing the code as quickly as you can. So that if it's a small script, or a large program that happens to fail early, or just exits early for a good reason, you don't spend any time being distracted by optimizing all that code. [11:38] And so if this was a statically compiled language, the user would have to specify that basically, when they run the compiler, they say, “Well, run a sort of optimize for speed or optimize for time, or O2, O3 or maybe optimized for debugging O0.” In Python, we try not to bother the user with those decisions. So, you have to generate bytecode before you can execute even the first line of code. So, what we try to do there is keep the bytecode compiler simple, keep the bytecode interpreter simple, so that we get to execute the beginning of the code as soon as possible. If we see that certain functions are being executed many times over, then we call that a hot function, and you can sort of define what's hot. For some purposes, maybe it's a hot function if it gets called more than once, or more than twice, or more than 10 times. For other purposes, you want to be more conservative, and you can say, “Well, it's only hot if it's been called 1000 times.” [12:48] But anyway, for a hot function, you want to do more work. And so, the specializing adaptive compiler, at that point, tries to replace certain bytecodes with bytecodes that are faster, but that work only if the types of the arguments are specific types. A simple example but pretty hypothetical is the plus operator in Python at least, can add lots of things. It can add integers, it can add floats, it can add strings, it can list or tuples. On the other hand, you can't add an integer to a string, for example. So, what we do there, the optimization step - and it's also called quickening, but usually in our context, we call it specializing - is we have a separate binary add integer bytecode. And it's sort of a second-tier bytecode that is hidden from the user. If the user asked for the disassembly of their function, they will never see binary add integer, they will also always see just binary add. But what the interpreter sees once the function has been quickened, the interpreter may see binary add integers. And the binary add integer just assumes that both of its arguments, that's both the numbers on the stack, are actual Python integer objects. It just reaches directly into those objects to find the values, adds those values together in machine registers, and push the result back on the stack. [14:35] Now, there are all sorts of things that make that difficult to do. For example, if the value doesn't fit in a register for the result, or either of the input values, or maybe even though you expected it was going to be adding two integers, this particular time it's going to add to an integer and a floating-point or maybe even two strings. [15:00] So the first stage of specialization is actually… I'm blanking out on the term, but there is an intermediate step where we record the types of arguments. And during that intermediate step, the bytecode actually executes slightly slower than the default bytecode. But that only happens for a few executions of a function because then it knows this place is always called with integers on the stack, this place is always called with strings on the stack, and maybe this place, we still don't know or it's a mixed bag. And so then, the one where every time it was called during this recording phase, it was two integers, we replace it with that binary add integer operation. The binary adds integer operation, then, before it reaches into the object, still has to make a type check on the arguments. So, it's not completely free but a type check can be implemented much faster than a sort of completely generic object-oriented dispatch, like what normally happens for the most generic binary add operations. [16:14] So once we've recorded the types, we specialize it based on the types, and the interpreter then puts in guards. So, the interpreter code for the specialized instruction has guards that check whether all the conditions that will make the specialized instruction work, are actually met. If one of the conditions is not met, it's not going to fail, it's just going to execute the original bytecode. So, it's going to fall back to the slow path rather than failing. That's an important part so that you still have the full Python semantics. And it's always possible that a function is called hundreds or millions of times with integer arguments, and then suddenly a piece of data calls it with a floating-point argument, or something worse. And the semantics still say, “Well, then it has to do with the floating-point way.Utsav: [17:12] It has to deoptimize, in a sense.Guido: [17:14] Yeah. And there are various counters in all the mechanisms where, if you encounter something that fails the guard once, that doesn't deoptimize the whole instruction. But if you sort of keep encountering mismatches of the guards, then eventually, the specialized instruction is just deoptimized and we go back to, “Oh, yeah, we'll just do it the slow way because the slow way is apparently the fastest, we can do.” Utsav: [17:45] It's kind of like branch prediction.Guido: [17:47] I wish I knew what went on in modern CPUs when it comes to branch prediction and inline caching because that is absolute magic. And it's actually one of the things we're up against with this project, because we write code in a way that we think will clearly reduce the number of memory accesses, for example. And when we benchmark it, we find that it runs just as fast as the old unoptimized code because the CPU figured it out without any of our help. Utsav: [18:20] Yeah. I mean, these techniques, generally you hear them in a context of JIT, a Just-In-Time compiler, but y’all are not implementing that right now.Guido: [18:30] JIT is like, yeah, in our case, it would be a misnomer. What we do expect to eventually be doing is, in addition to specialization, we may be generating machine code. That's probably going to be well past 3.11, maybe past 3.12. So, the release that we still have until October next year is going to be 3.11, and that's where the specializing interpreters going to make its first entry. I don't think that we're going to do anything with machine code unless we get extremely lucky with our results halfway through the year. But eventually, that will be another tier. But I don't know, Just-In-Time compilation has a whole bunch of emotional baggage with it at this point that we're trying to avoid.Utsav: [19:25] Is it baggage from other projects trying it?Guido: [19:29] People assume that Just-In-Time compilation automatically makes all your code better. It turns out that it's not that simple. In our case, compilation is like, “What exactly is it that we compile?” At some point ahead of time, we compile your source code into bytecode. Then we translate the bytecode into specialized bytecode. I mean, everything happens at some point during runtime, so which thing would you call Just-In-Time? Guido: [20:04] So I'm not a big fan of using that term. And it usually makes people think of feats of magical optimization that have been touted by the Java community for a long time. And unfortunately, the magic is often such that you can't actually predict what the performance of your code is going to be. And we have enough of that, for example, with the modern CPUs and their fantastic branch prediction.Utsav: [20:35] Speaking of that, I saw that there's also a bunch of small wins y'all spoke about, that y’all can use to just improve performance, things like fixing the place of __dict__ in objects and changing the way integers are represented. What is just maybe one interesting story that came out of that?Guido: [20:53] Well, I would say calling Python functions is something that we actually are currently working on. And I have to say that this is not just the Microsoft team, but also other people in the core dev team, who are very excited about this and helping us in many ways. So, the idea is that in the Python interpreter, up to and including version 3.10, which is going to be released next week, actually, whenever you call a Python function, the first thing you do is create a frame object. And a frame object contains a bunch of state that is specific to that call that you're making. So, it points to the code object that represents the function that's being called, it points to the globals, it has a space for the local variables of the call, it has space for the arguments, it has space for the anonymous values on the evaluation stack. But the key thing is that it’s still a Python object. And there are some use cases where people actually inspect the Python frame objects, for example, if they want to do weird stuff with local variables. [22:18] Now, if you're a debugger, it makes total sense that you want to actually look at what are all the local variables in this frame? What are their names? What are their values and types? A debugger may even want to modify a local variable while the code is stopped in a breakpoint. That's all great. But for the execution of most code, most of the time, certainly, when you're not using a debugger, there's no reason that that frame needs to be a Python object. Because a Python object has a header, it has a reference count, it has a type, it is allocated as its own small segment of memory on the heap. It's all fairly inefficient. Also, if you call a function, then you create a few objects, then from that function, you call another function, all those frame objects end up scattered throughout the entire heap of the program. [23:17] What we have implemented in our version of 3.11, which is currently just the main branch of the CPython repo, is an allocation scheme where when we call a function, we still create something that holds the frame, but we allocate that in an array of frame structures. So, I can't call them frame objects because they don't have an object header, they don't have a reference count or type, it's just an array of structures. This means that unless that array runs out of space, calls can be slightly faster because you don't jump around on the heap. And allocation sort of is to allocate the next frame, you compare two pointers, and then you bump one counter, and now you have a new frame structure. And so, creation, and also deallocation of frames is faster. Frames are smaller because you don't have the object header. You also don't have the malloc overhead or the garbage collection overhead. And of course, it's backwards incompatible. So, what do we do now? Fortunately, there aren't that many ways that people access frames. And what we do is when people call an API that returns a frame object, we say, “Okay, well sure. Here's the frame in our array. Now we're going to allocate an object and we're going to copy some values to the frame object,” and we give that to the Python code. So, you can still introspect it and you can look at the locals as if nothing has changed. [25:04] But most of the time, people don't look at add frames. And this is actually an old optimization. I remember that the same idea existed in IronPython. And they did it differently. I think for them, it was like a compile-time choice when the bytecode equivalent in IronPython was generated for a function, it would dynamically make a choice whether to allocate a frame object or just a frame structure for that call. And their big bugaboo was, well, there is a function you can call sys dunder __getFrame__ and it just gives you the frame object. So, in the compiler, they were looking, were you using the exact thing named system dunder __getFrame__ and then they would say, “Oh, that's getFrame, now we're going to compile you slightly slower so you use a frame object.” We have the advantage that we can just always allocate the frame object on the fly. But we get similar benefits. And oh, yeah, I mentioned that the frame objects are allocated in array, what happens if that array runs out? Well, it's actually sort of a linked list of arrays. So, we can still create a new array of frames, like we have space for 100 or so which, in many programs, that's plenty. And if your call stack is more than 100 deep, we'll just have one discontinuity, but the semantics are still the same and we still have most of the benefits.Utsav: [26:39] Yeah, and maybe as a wrap-up question, there are a bunch of other improvements happening in the Python community for performance as well, right? There's Mypyc, which we're familiar with, which is using types, Mypy types to maybe compiled code to basically speed up. Are there any other improvements like that, that you're excited about, or you're interested in just following?Guido: [27:01] Well, Mypyc is very interesting. It gives much better performance boost, but only when you fully annotate your code and only when you actually follow the annotations precisely at runtime. In Mypy, if you say, “This function takes two integers,” and it returns an integer, then if you call it with something else, it's going to immediately blow up. It'll give you a traceback. But the standard Python semantics are that type annotations are optional, and sometimes they're white lies. And so, the types that you see at runtime may not actually be compatible with the types that were specified in the annotations. And it doesn't affect how your program executes. Unless you sort of start introspecting the annotations, your program runs exactly the same with or without annotations. [28:05] I mean, there are a couple of big holes that are in the type system, like any. And the type checker will say, “Oh, if you put any, everything is going to be fine.” And so, using that, it's very easy to have something that is passed, an object of an invalid type, and the type checker will never complain about it. And our promise is that the runtime will not complain about it either unless it really is a runtime error. Obviously, if you're somehow adding an integer to a string at runtime, it's still going to be a problem. But if you have a function that, say, computes the greatest common divisor of two numbers, which is this really cute little loop, if you define the percent operator in just the right way, you can pass in anything. I think there are examples where you can actually pass it to strings, and it will return a string without ever failing. [29:07] And so basically, Mypyc does things like the instance attributes are always represented in a compact way where there is no dunder __dict__. The best that we can do, which we are working on designing how we're actually going to do that, is make it so that if you don't look at the dunder __dict__ attribute, we don't necessarily have to store the instance attributes in a dictionary as long as we preserve the exact semantics. But if you use the dunder __dict__, at some later point, again, just like the frame objects, we have to materialize a dictionary. And Mypyc doesn't do that. It's super-fast if you don't use dunder __dict__. If you do use dunder __dict__, it just says, “dunder __dict__ not supported in this case.” [29:59] Mypyc really only compiles a small subset of the Python language. And that's great if that's the subset you're interested in. But I'm sure you can imagine how complex that is in practice for a large program.Utsav: [30:17] It reminds me of JavaScript performance when everything is working fast and then you use this one function, which you're not supposed to use to introspect an object or something, and then performance just breaks down. Guido: [30:29] Yeah, that will happen. Utsav: [30:31] But it's still super exciting. And I'm also super thankful that Python fails loudly when you try to add a number in the string, not like JavaScript,Guido: [30:41] Or PHP, or Perl.Utsav: [30:44] But yeah, thank you so much for being a guest. I think this was a lot of fun. And I think it walked through the performance improvement y’all are trying to make in an accessible way. So, I think it’s going to be useful for a lot of people. Yeah, thank you for being a guest.Guido: [30:58] My pleasure. It’s been a fun chat. Get on the email list at www.softwareatscale.dev

Guest Dan Lorenc Panelists Eric Berry | Justin Dorfman | Richard Littauer Show Notes Hello and welcome to Sustain! The podcast where we talk about sustaining open source for the long haul. Today, we have a very special guest, Dan Lorenc, who is a Staff Software Engineer and the lead for Google's Open Source Security Team. Dan founded projects like Minikube, Skaffold, TektonCD, and Sigstore. He blogs regularly about supply chain security and serves on the TAC for the Open SSF. Dan fill us in on how Docker fits into what he's doing at Google, he tells us about who's running the Open Standards that Docker is depending on, and what he's most excited for with Docker with standardization and in the future. We also learn a little more about a blog post he did recently and what he means by “package managers should become boring,” and he tells us how package managers can help pay maintainers to support their libraries. We learn more about his project Sigstore, and his perspective on the long-term growth of the software industry towards security and how that will change in the next five to ten years. Go ahead and download this episode now to find out much more! [00:01:09] Dan tells us his background and how he got to where he is today. [00:03:08] Eric wonders how Docker fits into what Dan is doing at Google and if he can compare Minicube and his work with what the Docker team is trying to drive. He also compares Kubernetes to Docker and how they relate. [00:06:13] Dan talks about if he sees a shift of adoption in the sphere of what he's seeing, and Eric asks if he feels that local development with Docker is devalued a little bit if you don't use the same Docker configuration for your production deploy. [00:08:49] Richard wonders in the long-term, if Dan thinks we're going to continually keep making Dockers, better Kubernetes, or at some point are we going to decide that tooling is enough. [00:10:35] We learn who's currently running the Open Standards that Docker is depending on and Dan talks about the different standards. [00:12:13] Dan shares how he thinks the shift towards open standards in particular with Docker, influences open source developers who are in more smaller companies, in SMEs, in medium-sized companies, or solo developers out there who may not have the time to get involved in open standards. [00:13:45] Find out what Dan is really excited about in terms of Docker, with standardization or in the future that will lead to a more sustainable ecosystem. [00:15:17] Justin brings up Dan's blog and a recent post he just did called, “In Defense of Package Managers,” and in it he mentions package managers should become boring, so he explains what he means by that. [00:18:01] Dan discusses how package managers can help pay maintainers to support their libraries. [00:22:03] Richard asks Dan if he has any thoughts on getting other ways of recognition to maintainers down the stack than just paying them. He mentions things that he loves that GitHub's been doing recently showing people their contribution history. [00:23:46] Find out about Dan's project Sigstore and what his adoption looks like so far. [00:26:35] Richard wonders if Dan thinks it's a good idea to have that ecosystem depend upon a few brilliant people like him doing this work or if there's a larger community of people working on security supply chain issues. Also, who are his colleagues that he bounces these ideas off of and how do we eliminate the bus factor here. Dan tells us they have a slack for Sigstore [00:30:03] We learn Dan's perspective on the long-term growth of the software industry towards security in general, how will that change over the next five to ten years, and how his role and the role of people like him will change. [00:31:35] Find out all the places you can follow Dan on the internet. Quotes [00:10:14] “You kind of move past that single point of failure and single tool shame that's actually used to manage everything.” [00:12:44] “So, they kind of helped contribute to the standardization process by proving stuff out by getting to try all the new exciting stuff.” [00:16:33] The “bullseye” release actually just went on a couple of days ago which was awesome.” [00:17:04] “It's a problem because there's nobody maintaining, which is a really good topic for sustainability.” [00:24:46] “But nobody's doing it for open source, nobody's signing their code on PyPy or Ruby Gems even though you can.” [00:29:50] “These are not the Kim Kardashians of the coding community.” [00:30:25] “Something that we've been constantly reminding, you know, the policy makers wherever we can, is that 80 to 90% of software in use today is open source.” [00:30:51] “And even if companies can do this work for the software that they produce if we don't think of, and don't take care of, and don't remember that these same requirements are going to hit opensource at the very bottom of the stack, and we're kind of placing unfunded mandates and burdens on these repositories and maintainers that they didn't sign up for it.” [00:31:11] “So we're really trying to remind everyone that as we increase these security standards, which we should do and we need to do, because software is serious, and people's lives depend on it.” Spotlight [00:32:32] Eric's spotlight is a game called Incremancer by James Gittins. [00:33:35] Justin's spotlight is Visual Studio Live Share. [00:34:04] Richard's spotlight is the BibTeX Community. [00:35:03] Dan's spotlight is the Debian maintainers. Links SustainOSS (https://sustainoss.org/) SustainOSS Twitter (https://twitter.com/SustainOSS?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) SustainOSS Discourse (https://discourse.sustainoss.org/) Dan Lorenc Twitter (https://twitter.com/lorenc_dan?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Dan Lorenc Linkedin (https://www.linkedin.com/in/danlorenc) Dan Lorenc Blog (https://dlorenc.medium.com/) Tekton (https://tekton.dev/) Minikube (https://minikube.sigs.k8s.io/docs/) Skaffold (https://skaffold.dev/) Open SSF (https://openssf.org/) Open Container Initiative (https://opencontainers.org/) Committing to Cloud Native podcast-Episode 20-Taking Open Source Supply Chain Security Seriously with Dan Lorenc (https://podcast.curiefense.io/20) “In Defense of Package Managers” by Dan Lorenc (https://dlorenc.medium.com/in-defense-of-package-managers-31792111d7b1?) Open Source Insights (https://deps.dev/) GitHub repositories Nebraska users (https://github.com/search?q=location%3Anebraska&type=users) CHAOSScast podcast (https://podcast.chaoss.community/) Sigstore (https://www.sigstore.dev/) RyotaK Twitter (https://twitter.com/ryotkak) Dustin Ingram Twitter (https://twitter.com/di_codes?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Incremancer (https://incremancer.gti.nz/) Visual Studio Live Share (https://visualstudio.microsoft.com/services/live-share/) Enhanced support for citations on GitHub-Arfon Smith (https://github.blog/2021-08-19-enhanced-support-citations-github/) Debian (https://www.debian.org/) Debian “bullseye” Release (https://www.debian.org/releases/bullseye/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr at Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Dan Lorenc.

Tener varias versiones de Python en el mismo ordenador, estado de Durus, su licencia y cómo funciona la persistencia de datos https://podcast.jcea.es/python/28 Participantes: Jesús Cea, email: jcea@jcea.es, twitter: @jcea, https://blog.jcea.es/, https://www.jcea.es/. Conectando desde Madrid. Jesús, conectando desde Ferrol. Felipem, conectando desde Cantabria. Eduardo Castro, email: info@ecdesign.es. Conectando desde A Guarda. Víctor Ramírez, twitter: @virako, programador python y amante de vim, conectando desde Huelva. Sergio, conectando desde Vigo. Juan José, Nekmo, https://nekmo.com/, https://github.com/Nekmo/. Madrileño conectando desde Málaga. Miguel Sánchez, email: msanchez@uninet.edu, conectando desde Las Palmas. Audio editado por Pablo Gómez, twitter: @julebek. La música de la entrada y la salida es "Lightning Bugs", de Jason Shaw. Publicada en https://audionautix.com/ con licencia - Creative Commons Attribution 4.0 International License. [00:52] Presentaciones. [03:47] Utilizar diferentes versiones de Python en el mismo ordenador. Cada paquete instalado está vinculado a una instancia concreta de Python instalada en el sistema. Nunca hacer pip install, sino indicar la versión: pip3.9 install. A la hora de instalar paquetes Python en la versión nativa del sistema operativo, se puede usar pip o bien el gestor de paquetes del sistema operativo. Mezclar ambas es una receta para el desastre. [16:37] Un problema de los paquetes precompilados ("wheels" https://www.python.org/dev/peps/pep-0427/) es que no se suelen precompilar de forma retroactiva para la última versión de Python que acaba de salir. No suelen estar disponibles hasta que sale una versión nueva del paquete, lo que puede tardar meses. [19:52] ¿Bibliotecas para manejar imágenes, compatibles con PyPy https://www.pypy.org/? Numpy https://numpy.org/ aún no funciona en PyPy https://www.pypy.org/. [21:17] ¿Qué es PyPy https://www.pypy.org/ exactamente? Jit: Compilación al vuelo https://es.wikipedia.org/wiki/Compilaci%C3%B3n_en_tiempo_de_ejecuci%C3%B3n. Barrera de entrada muy grande para entrar en el proyecto. Curva de aprendizaje. Problemas con los módulos en C. No valoraron la importancia del ecosistema. HPy https://hpyproject.org/. [27:27] Experiencia de un par de semanas con Flit https://pypi.org/project/flit/. Jesús Cea lo está utilizando para publicar su biblioteca toc2audio https://docs.jcea.es/toc2audio/. Herramienta propuesta en la charla "Python Packaging: Lo estás haciendo mal" https://www.youtube.com/watch?v=OeOtIEDFr4Y, de Juan Luis Cano. https://github.com/astrojuanlu/charla-python-packaging. https://nbviewer.jupyter.org/format/slides/github/astrojuanlu/charla-python-packaging/blob/main/Charla%20Python%20packaging.ipynb#/ PEP 621 -- Storing project metadata in pyproject.toml https://www.python.org/dev/peps/pep-0621/. Lo importante que es tener enlaces directos al "changelog" o a la documentación en PyPI https://pypi.org/. [31:32] Módulos de documentación. Carencias. Docstrings. doctest https://docs.python.org/3/library/doctest.html. Sphinx https://pypi.org/project/Sphinx/. make html. Tema eterno: Incluir una biblioteca en la biblioteca estándar o como biblioteca estándar. ReST: reStructuredText https://docutils.sourceforge.io/rst.html. PEP 287 -- reStructuredText Docstring Format https://www.python.org/dev/peps/pep-0287/. docutils: https://pypi.org/project/docutils/. [40:02] ¿Formato tertulia o preguntas y respuestas? [41:22] Estado actual de Durus https://www.mems-exchange.org/software/DurusWorks/ y comentarios variados sobre el sistema de persistencia. Jesús Cea ha estado intentando conectar con los autores, con poco éxito. Jesús Cea tiene problemas con la licencia. ¿Abandonar el proyecto y pasarse a ZODB https://zodb.org/en/latest/? La gente está haciendo "forks" https://en.wikipedia.org/wiki/Fork_(software_development) pasando olímpicamente de las licencias. Jesús Cea se está currando varios cambios de licencia en ciertos proyectos que le interesan, con muy poco éxito. ZOPE https://zopefoundation.github.io/Zope/. COPYRIGHT ASSIGNMENT https://www.copylaw.com/forms/copyassn.html. [50:32] ¿Cómo funciona un sistema de persistencia? Modelo completamente diferente a un ORM https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping. SQL: https://en.wikipedia.org/wiki/SQL. Working set: https://en.wikipedia.org/wiki/Working_set. [58:17] Volvemos al tema de licencias. [59:52] Explícame esto: https://lists.es.python.org/pipermail/general/2021-April/003476.html. Creamos un fichero "a.py" con el contenido: def x(): print('X') Creamos otro fichero "b.py" con el contenido: import a class clase: x = a.x def p(self): print(self.x) self.x() if __name__ == '__main__': a.x() b = clase() b.p() Ejecutas "b.py" y me explicas por qué sale lo que sale :-). [01:03:42] A la gente le encanta que le "piquen". [01:03:52] Las versiones actuales de Python ya han integrado el parche del "memory leak" que se habló en navidades. bpo-35930: Raising an exception raised in a "future" instance will create reference cycles #24995 https://github.com/python/cpython/pull/24995. [01:04:22] Llamada a ponencias de la PyConES https://2021.es.pycon.org/. [01:05:22] Volvemos al reto en https://lists.es.python.org/pipermail/general/2021-April/003476.html. Pista: los métodos son descriptores: https://docs.python.org/3/howto/descriptor.html. Bound method: https://www.geeksforgeeks.org/bound-methods-python/. Métodos estáticos: https://pythonbasics.org/static-method/. No se ha entendido nada porque ha habido numerosos cortes de sonido. El tema está bastante mejor explicado y se entiende en, por ejemplo, From Function to Method https://wiki.python.org/moin/FromFunctionToMethod. [01:10:02] Atributos de función. PEP 232 -- Function Attributes https://www.python.org/dev/peps/pep-0232/. Se pueden meter atributos a un método, pero se hace a nivel de clase, no de instancia, porque los métodos pertenecen a la clase, no a la instancia:class clase: def p(self): clase.p.hola = 78 >>> x=clase() >>> x.p() >>> x.p.hola 78 >>> y=clase() >>> a.p.hola 78 >>> clase.p.hola 78 [01:14:42] Notas de las grabaciones, temas futuros y enviar temas con algún tiempo previo a la tertulia si requieren pensar. [01:16:06] Final.

Diseccionamos la charla de Juan Luis Cano "Python Packaging: Lo estás haciendo mal" y mucho DevOps https://podcast.jcea.es/python/26 Este audio tiene mucho ruido producido por el roce del micrófono de Jesús Cea en la ropa. Participantes: Jesús Cea, email: jcea@jcea.es, twitter: @jcea, https://blog.jcea.es/, https://www.jcea.es/. Conectando desde Madrid. Felipem, conectando desde Cantabria. Víctor Ramírez, twitter: @virako, programador python y amante de vim, conectando desde Huelva. Javier, conectando desde Madrid. Audio editado por Pablo Gómez, twitter: @julebek. La música de la entrada y la salida es "Lightning Bugs", de Jason Shaw. Publicada en https://audionautix.com/ con licencia - Creative Commons Attribution 4.0 International License. [00:50] Preludio. Hay que automatizarlo todo, y lo que no se puede automatizar, se documenta. Detalles de calidad de grabación. Lo que falta para publicar los audios. toc2audio https://docs.jcea.es/toc2audio/. La publicación de audios es inminente. Diversas plataformas de podcast https://es.wikipedia.org/wiki/Podcasting. Spotify https://es.wikipedia.org/wiki/Spotify. ¿Y publicar en Youtube? Estadísticas de descarga. [08:20] Autonomía digital. ¡Muerte al MP3! https://es.wikipedia.org/wiki/MP3 [10:20] Jesús Cea se queja de que la encuesta de programadores de Python no es sobre Python. Python Developers Survey 2020 Results https://www.jetbrains.com/lp/python-developers-survey-2020/ [11:55] Python Packaging: Lo estás haciendo mal https://www.youtube.com/watch?v=OeOtIEDFr4Y. https://github.com/astrojuanlu/charla-python-packaging. https://nbviewer.jupyter.org/format/slides/github/astrojuanlu/charla-python-packaging/blob/main/Charla%20Python%20packaging.ipynb#/ La charla ha gustado bastante en general. Flit https://pypi.org/project/flit/. Mucha documentación online está anticuada. Viene bien una lista de "buenas prácticas" actualizadas. El peso del "legado" anticuado. El ecosistema se está moviendo muy rápido. Buenas prácticas: https://packaging.python.org/. Esperemos que alguien mantenga eso actualizado. PEP 621 -- Storing project metadata in pyproject.toml https://www.python.org/dev/peps/pep-0621/. Pecado que Jesús Cea comete constantemente: ¡instalar paquetes a nivel de sistema operativo!. No le da problemas porque hace tantas barbaridades que se cancelan unas a otras. ¡Tú mejor que sigas las recomendaciones de Juan Luis Cano https://twitter.com/juanluisback! pipenv es el mal https://pypi.org/project/pipenv/. pip-tools https://pypi.org/project/pip-tools/. pip-compile. pipdeptree https://pypi.org/project/pipdeptree/. [35:28] A la hora de fijar dependencias, no es lo mismo bibliotecas que aplicaciones. [40:58] ¿Estar a la última o actualizar cuando no hay más remedio? ¡Tests de integración! https://es.wikipedia.org/wiki/Prueba_de_integraci%C3%B3n [45:15] Un 100% de cobertura de código no garantiza que se ejecuten todos los estados del código. [49:10] Tests de mutaciones https://es.wikipedia.org/wiki/Prueba_de_mutaci%C3%B3n. hypothesis https://pypi.org/project/hypothesis/. mutant https://pypi.org/project/mutant/. [50:50] Flit https://pypi.org/project/flit/. PEP 420 -- Implicit Namespace Packages https://www.python.org/dev/peps/pep-0420/. PEP 621 -- Storing project metadata in pyproject.toml https://www.python.org/dev/peps/pep-0621/. [55:35] PEP 427 -- The Wheel Binary Package Format 1.0 https://www.python.org/dev/peps/pep-0427/. Conda: https://docs.conda.io/en/latest/. Problemas para que los Wheel soporten las nuevas versiones de Python. Cuando sale una nueva versión de Python, suele ser necesario esperar para tener soporte Wheels de los paquetes que nos interesan. ELF (Executable and Linkable Format): https://en.wikipedia.org/wiki/Executable_and_Linkable_Format. [01:03:10] ¿Alguien usando un sistema operativo viejo va a instalar una versión moderna de Python? Si puedes instalar Python desde código fuente, seguro que puedes compilar mi librería desde código fuente también. Ojo con los paquetes binarios avanzados en CPUs antiguas. SSE: https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions. cmov: https://en.wikipedia.org/wiki/Predication_(computer_architecture)#History. [01:10:48] Docker https://es.wikipedia.org/wiki/Docker_(software). [01:11:20] Réplicas locales de PyPI https://pypi.org/ y PyPI privados. [01:14:45] ccache https://ccache.dev/. Ansible: https://es.wikipedia.org/wiki/Ansible_(software). [01:18:58] HPy https://hpyproject.org/. [01:20:10] ¿Proponer temas esotéricos? ¿Mandar deberes? [01:21:05] Más sobre HPy https://hpyproject.org/. API alternativa para módulos Python en C. https://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones. Permite generar un Wheel https://www.python.org/dev/peps/pep-0427/ que funciona en varias versiones de Python. Buen rendimiento tanto en CPython como en PyPy https://www.pypy.org/. Posible API https://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones futuro para CPython. [01:29:02] Ayuda para adecentar la página web de los podcasts: https://podcast.jcea.es/python/. La publicación de los audios es inminente. Reusaremos el podcast "Python en español" https://podcast.jcea.es/python/. He pedido permiso a mis antiguos compañeros. CSS: https://es.wikipedia.org/wiki/Hoja_de_estilos_en_cascada. Hay tanto retraso en la publicación que cualquier "feedback" tardará en salir y en notarse sus efectos. [01:35:10] Canal de Telegram de coordinación: https://t.me/joinchat/y__YXXQM6bg1MTQ0. [01:36:10] Machete Mode https://nedbatchelder.com/blog/202103/machete_mode_tagging_frames.html. Usarlo para depurar un bug. Pena de muerte en producción. Ideas locas: James Powell https://twitter.com/dontusethiscode. Conocimiento íntimo del lenguaje y de su implementación. Javier disfruta dando charlas de temas profundos y esotéricos. [01:42:30] El parche de Memory Leak ya se ha integrado el Python. bpo-35930: Raising an exception raised in a "future" instance will create reference cycles #24995 https://github.com/python/cpython/pull/24995. [01:43:30] Despedida y deberes futuros. Security funding & NYU https://discuss.python.org/t/new-packaging-security-funding-nyu/7792. TUF (The Update Framework) https://theupdateframework.io/. PEP 458 -- Secure PyPI downloads with signed repository metadata https://www.python.org/dev/peps/pep-0458/. PEP 480 -- Surviving a Compromise of PyPI: End-to-end signing of packages https://www.python.org/dev/peps/pep-0480/. En honor a Eduardo, que no se ha conectado hoy, metemos ruido de teclado para que nuestro editor Pablo no lo eche de menos. [01:48:20] Final.

Internet Archive, no acabamos de hablar del nuevo "pattern matching", complejidad creciente de la sintaxis de Python https://podcast.jcea.es/python/20 Participantes: Eduardo Castro, email: info@ecdesign.es. Conectando desde A Guarda. Jesús Cea, email: jcea@jcea.es, twitter: @jcea, https://blog.jcea.es/, https://www.jcea.es/. Conectando desde Madrid. Víctor Ramírez, twitter: @virako, programador python y amante de vim, conectando desde Huelva. Javier, conectando desde Madrid. Audio editado por Pablo Gómez, twitter: @julebek. La música de la entrada y la salida es "Lightning Bugs", de Jason Shaw. Publicada en https://audionautix.com/ con licencia - Creative Commons Attribution 4.0 International License. [01:33] Cómo documentar en Python. Google docs: https://docs.google.com. Wikis en GitHub: https://docs.github.com/en/communities/documenting-your-project-with-wikis/about-wikis. Ventajas de tener la documentación en el control de versiones del proyecto. Ventajas de ir escribiendo la documentación mientras escribes el propio código: Realimentación. Sphinx: https://www.sphinx-doc.org/en/master/. sphinx.ext.autodoc: https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html. plantuml: https://github.com/sphinx-contrib/plantuml. Markdown: https://www.markdownguide.org/. [03:48] La vieja guardia es escéptica con las novedades de la semana. No hay balas de plata. La documentación guía el desarrollo. Paralelismo con los tests. [08:38] Open source y la vergüenza: tests y documentación. [09:28] CPython Internals Book https://realpython.com/products/cpython-internals-book/. [11:13] HPy https://hpyproject.org/. Nuevo API https://es.wikipedia.org/wiki/Api para programar extensiones C para Python, independizándote de la versión del intérprete y compatible con cosas como PyPy: https://www.pypy.org/. [13:18] Internet Archive como biblioteca de libros modernos: https://archive.org/details/inlibrary. Funciona como una biblioteca tradicional. Préstamo de libros. Están escaneando a toda velocidad: 2.5 millones de libros en el momento de escribir estas notas (mayo de 2021). Internet Archive: https://archive.org/. Wayback Machine: https://web.archive.org/. Preservación de videojuegos, páginas en flash, discos de música... [17:03] Web de Python en Internet Archive. 1997: https://web.archive.org/web/19970606181701/http://www.python.org/. 1998: https://web.archive.org/web/19981212032130/http://www.python.org/. Un ejemplo de "batteries included": https://commons.wikimedia.org/wiki/File:Python_batteries_included.jpg. [17:53] Jesús Cea echa de menos la internet distribuida. [18:23] Pattern Matching en Python 3.10. PEP 622 -- Structural Pattern Matching https://www.python.org/dev/peps/pep-0622/. ¿"match" y "case" serán palabras reservadas? PEP 617 -- New PEG parser for CPython https://www.python.org/dev/peps/pep-0617/. Se repasa la funcionalidad un poco por encima. [27:48] Logs fáciles de configurar y decorados con colorines: Daiquiri: https://daiquiri.readthedocs.io/en/latest/. Colorama: https://pypi.org/project/colorama/. Compatible con Windows. [29:28] Truco: Python -i: Ejecuta un script y pasa a modo interactivo. Comentado hace unas semanas. También se puede hacer desde el propio código con code.InteractiveConsole(locals=globals()).interact(). Jesús Cea se queja de que usando la invocación desde código no funciona la edición de líneas. Javier da la pista correcta: para que funcione, basta con hacer import readline antes de lanzar el modo interactivo. [30:48] Manhole: https://pypi.org/project/manhole/. [31:53] Breakpoints condicionales https://docs.python.org/3/library/pdb.html#pdbcommand-condition. breakpoint() como función nativa: PEP 553 -- Built-in breakpoint() https://www.python.org/dev/peps/pep-0553/. import pdb; pdb.set_trace(). [33:28] Scraping a mano: scrapy shell: https://docs.scrapy.org/en/latest/topics/shell.html. Jesús Cea no echa de menos Scrapy https://docs.scrapy.org/en/latest/. [36:03] Indexador y buscador de documentos: Whoosh https://whoosh.readthedocs.io/en/latest/intro.html. Jesús necesitaba ignorar tildes, lo que impacta en la extracción del lexema. El backend está documentado, para que te lo puedas currar tú si lo necesitas. [38:23] ¿Cómo hacer copia de seguridad de un fichero de 600 gigabytes con pocos cambios internos? [40:58] Eduardo Castro ha ganado un hackathon en Pontevedra. Software para Django: https://www.djangoproject.com/. [46:38] Experiencias agridulces con los hackathones https://en.wikipedia.org/wiki/Hackathon. Netflix Prize https://en.wikipedia.org/wiki/Netflix_Prize. [50:38] Una URL puede no estar no disponible ya cuando escuchas el podcast: Podcast: Programar es una mierda: https://www.programaresunamierda.com/. [52:28] Jamii https://jamii.es/. API https://es.wikipedia.org/wiki/Api [55:38] GraphQL https://es.wikipedia.org/wiki/GraphQL. REST: https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional. Permisos de usuario. No hay cacheo. Vulcain: https://github.com/dunglas/vulcain. [01:02:53] HTTP/2 https://en.wikipedia.org/wiki/HTTP/2. HTTP/2 Server Push: https://en.wikipedia.org/wiki/HTTP/2_Server_Push. No se tiene que responder por orden. Multiplexación. [01:08:53] La explosión de la complejidad innecesaria ocultada por bibliotecas: OAuth2 https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. OpenID: https://en.wikipedia.org/wiki/OpenID. [01:10:33] Complejidad creciente de la sintaxis de Python. Volvemos a Structural Pattern Matching https://www.python.org/dev/peps/pep-0622/. Complejidad de la sintaxis. Un lenguaje pequeño y capaz reemplaza a lenguajes dinosaurio. Python reemplazó a otros lenguajes dinosaurio. Ahora Python es un dinosaurio. ¿Cuándo saldrá un lenguaje que reemplace a Python? [01:12:13] Metaclases https://realpython.com/python-metaclasses/. Closures: https://es.wikipedia.org/wiki/Clausura_(inform%C3%A1tica). [01:15:08] Empiezan a aparecer sublenguajes, tribus, subculturas de Python. Ciertos cambios de sintaxis pueden unificar subculturas: "la forma oficial de hacerlo". El operador ternario de Python v = VALOR1 if CONDICIÓN else VALOR2: PEP 308 -- Conditional Expressions https://www.python.org/dev/peps/pep-0308/. List comprehension: [f(i) for i in ITER if CONDICIÓN(i)]: PEP 202 -- List Comprehensions https://www.python.org/dev/peps/pep-0202/. [01:20:18] En los viejos tiempos, podías hacer barbaridades como True = 0. Esto funciona en Pythonn 2.7. Es algo que se cambió en Python 3.0: https://docs.python.org/3.0/whatsnew/3.0.html#changed-syntax. [01:21:53] Jesús Cea echa de menos que se eliminen cosas. Está obsesionado con el tamaño del lenguaje. ¿Qué eliminaríamos? [01:25:23] El lenguaje C incluye solo lo mínimo imprescindible. [01:26:48] Curiosidades: What the f*ck Python! https://github.com/satwikkansal/wtfpython: >>> all([]) True >>> all([[]]) False >>> all([[[]]]) True [01:28:03] Algunos avances en la investigación del bug descrito por Virako en las últimas semanas: Ejemplo de código: https://pastebin.com/vGM1sh8r. Issue24676: Error in pickle using cProfile https://bugs.python.org/issue24676. Issue9914: trace/profile conflict with the use of sys.modules[__name__] https://bugs.python.org/issue9914. Issue9325: Add an option to pdb/trace/profile to run library module as a script https://bugs.python.org/issue9325. Requiere mejorar el módulo runpy https://docs.python.org/3/library/runpy.html. A nadie le ha dolido lo suficiente el bug como para solucionarlo. No es que sea realmente difícil. Tal vez sí. [01:35:53] Nuitka https://nuitka.net/. Ejecutables Python independientes de lo que tengas instalado en el sistema. Por ejemplo, para poder usar una versión de Python "moderna". También funciona en MS Windows. [01:39:43] Tertulia previa: Fuentes de caracteres con ligaduras. Combinación de caracteres unicode. Las banderas de los países, por ejemplo, son un código "bandera" seguido del código del país: https://en.wikipedia.org/wiki/Regional_indicator_symbol. La bandera de Taiwan se ve distinta en China que en el resto del mundo: https://emojipedia.org/flag-taiwan/. "Collation" https://en.wikipedia.org/wiki/Unicode_collation_algorithm, para ordenar y comparar correctamente caracteres unicode: PyICU: https://pypi.org/project/PyICU/. [01:50:23] Cuando el Steering Council https://www.python.org/dev/peps/pep-0013/ vota un tema polémico, la decisión es final. Ya no se busca el consenso a toda costa. [01:52:53] Despedida. [01:53:55] Final.

Polémica Frameworks, compilación al vuelo, compiladores y rendimiento Python, scraping web y la persistencia vuelve a la carga https://podcast.jcea.es/python/16 Participantes: Jesús Cea, email: jcea@jcea.es, twitter: @jcea, https://blog.jcea.es/, https://www.jcea.es/. Conectando desde Madrid. Eduardo Castro, email: info@ecdesign.es. Conectando desde A Guarda. Javier, conectando desde Madrid. Víctor Ramírez, twitter: @virako, programador python y amante de vim, conectando desde Huelva. Dani, conectando desde Málaga, invitado por Virako. Javier, conectando desde Sevilla, también invitado por Virako. Antonio, conectado desde Albacete. Jorge Rúa, conectando desde Vigo. Audio editado por Pablo Gómez, twitter: @julebek. La música de la entrada y la salida es "Lightning Bugs", de Jason Shaw. Publicada en https://audionautix.com/ con licencia - Creative Commons Attribution 4.0 International License. [01:17] Event sourcing y nieve. Borrasca Filomena: https://es.wikipedia.org/wiki/Borrasca_Filomena. [03:52] Los comentarios legales habituales para poder grabar la tertulia. [04:47] Presentaciones varias, dinámica y motivación de las tertulias. [11:22] Los problemas logísticos de Jesús Cea con sus charlas. [12:52] Debate: Frameworks y cómo condicionan el conocimiento del lenguaje y la forma de desarrollar código. Mucha tela que cortar. [30:22] Conexión con el mundo asyncio. [34:12] Digresión: ¿Cómo funciona la protección CSRF? https://es.wikipedia.org/wiki/Cross-site_request_forgery. Diferencia semántica entre verbos HTTP: GET y POST https://en.wikipedia.org/wiki/POST_(HTTP). Algunos recursos de seguridad web (no exhaustivo, la lista es infinita): CSRF: https://es.wikipedia.org/wiki/Cross-site_request_forgery. Cross-Origin Resource Sharing (CORS) https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. Content Security Policy Reference https://content-security-policy.com/. La documentación de FastAPI https://fastapi.tiangolo.com/ tiene mucho de seguridad: CORS (Cross-Origin Resource Sharing): https://fastapi.tiangolo.com/tutorial/cors/. OAuth2 with Password (and hashing), Bearer with JWT tokens https://fastapi.tiangolo.com/tutorial/security/oauth2-jwt/. About HTTPS https://fastapi.tiangolo.com/deployment/https/. [39:52] Proyecto ItsNat https://en.wikipedia.org/wiki/ItsNat. Estado en el servidor y el cliente solo gestiona eventos y actualizaciones del DOM que le envía el servidor. Se está moviendo otra vez la inteligencia del navegador al servidor. [44:42] ¿Realmente es imprescindible usar Javascript si tu interfaz es el navegador? Brython: https://brython.info/. Pyjs (antiguo Pyjamas): https://en.wikipedia.org/wiki/Pyjs. Emscripten: https://emscripten.org/. [48:57] ¡Compilación al vuelo! Versionado de diccionarios. PEP 509 Add a private version to dict: https://www.python.org/dev/peps/pep-0509/. Compilación al vuelo: Pyjion: https://pyjion.readthedocs.io/en/latest/index.html. Conflicto con la portabilidad del intérprete. numba: https://numba.pydata.org/. Hay pocos "core developers" y heredar código avanzado que luego hay que mantener es un problema. LLVM: https://en.wikipedia.org/wiki/LLVM. [01:04:27] Los lenguajes de programación deben ser conservadores porque no tienes ni idea de lo que están utilizando los programadores. [01:05:32] Si la documentación se ha actualizado, más vale que hayas actualizado tu código a "cómo se hacen ahora las cosas". [01:06:47] Tema recurrente: ¿Es mejor estar dentro o fuera de la biblioteca estándar? Boost: https://www.boost.org/. [01:09:12] Compiladores de Python: Cython: https://cython.org/. Rendimiento y ofuscación. nuitka: https://nuitka.net/. numba: https://numba.pydata.org/. PyPy: https://www.pypy.org/. [01:10:42] Mejoras recientes en la implementación de Python: Issue 26647: ceval: use Wordcode, 16-bit bytecode: https://bugs.python.org/issue26647. Issue 9203: Use computed gotos by default: https://bugs.python.org/issue9203. [01:14:52] Psyco https://en.wikipedia.org/wiki/Psyco. [01:16:22] Etiquetado de tipos para ayudar a los JIT. Cython: https://cython.org/. MYPY: http://mypy-lang.org/. MYPYC: https://mypyc.readthedocs.io/en/latest/index.html. Especialización. [01:22:37] GHC (The Glasgow Haskell Compiler): https://www.haskell.org/ghc/. [01:25:07] Memoria transaccional https://en.wikipedia.org/wiki/Transactional_memory. Implementaciones en Python: Sistemas de persistencia como Durus https://www.mems-exchange.org/software/DurusWorks/ o ZODB http://www.zodb.org/. Mecanismos de resolución de conflictos. [01:34:32] Más sobre optimizaciones y guardas. Mucha discusión sobre el GIL: https://en.wikipedia.org/wiki/Global_interpreter_lock. La atomicidad de operaciones no está documentada en ningún sitio. [01:42:02] Ejemplo de bytecode: >>> def rutina(n): ... n += 1 ... n = n + 1 ... >>> dis.dis(rutina) 2 0 LOAD_FAST 0 (n) 2 LOAD_CONST 1 (1) 4 INPLACE_ADD 6 STORE_FAST 0 (n) 3 8 LOAD_FAST 0 (n) 10 LOAD_CONST 1 (1) 12 BINARY_ADD 14 STORE_FAST 0 (n) 16 LOAD_CONST 0 (None) 18 RETURN_VALUE [01:45:02] Cuando haces cosas muy avanzadas que usan cosas no definidas formalmente, mejor verificar las suposiciones. [01:46:47] La ventaja de probar cosas en proyectos personales: ¿Por qué Jesús Cea se ha hecho su propio scraper web? "Maldades". scrapy: https://scrapy.org/. [01:49:22] Migración de versiones en sistemas de persistencia. [02:05:07] Event sourcing. Event sourcing: https://dev.to/barryosull/event-sourcing-what-it-is-and-why-its-awesome. Logs de modificaciones. [02:08:07] Ventajas de haber usado scrapy: https://scrapy.org/. Concurrencia. tarpit. Problemas habituales: Normalización de URLs. Webs mal formadas. [02:13:47] Módulos de scraping: newspaper3k: https://pypi.org/project/newspaper3k/. [02:15:02] Recapitulación. Pyjion: https://pyjion.readthedocs.io/en/latest/index.html. MYPYC: https://mypyc.readthedocs.io/en/latest/index.html. [02:16:02] Compilación de módulos de Python para MS Windows. Generar un wheel. Aprovechar sistemas de integración continua que levantan máquinas virtuales. [02:22:21] Final.

Ciclos de memoria, "core developers" y dataclasses https://podcast.jcea.es/python/12 En lo que sigue, cuando se habla de CPython, se refiere al intérprete de referencia de Python, que está escrito en lenguaje C: https://www.python.org/downloads/. Participantes: Eduardo Castro, email: info@ecdesign.es. Conectando desde A Guarda. Jesús Cea, email: jcea@jcea.es, twitter: @jcea, https://blog.jcea.es/, https://www.jcea.es/. Conectando desde Madrid. Javier, conectando desde Madrid. Víctor Ramírez, twitter: @virako, programador python y amante de vim, conectando desde Huelva. Juan Carlos. Audio editado por Pablo Gómez, twitter: @julebek. La música de la entrada y la salida es "Lightning Bugs", de Jason Shaw. Publicada en https://audionautix.com/ con licencia - Creative Commons Attribution 4.0 International License. [00:52] Seguimos hablando del bug comentado la semana pasada. bug bpo35930: "Raising an exception raised in a "future" instance will create reference cycles": https://bugs.python.org/issue35930. [02:17] El "bytecode" https://es.wikipedia.org/wiki/Bytecode que genera Python es muy mejorable. >>> import dis >>> def suma(valores): ... s=0 ... for i in valores: ... s+=i ... return s ... >>> dis.dis(suma) 2 0 LOAD_CONST 1 (0) 2 STORE_FAST 1 (s) 3 4 LOAD_FAST 0 (valores) 6 GET_ITER >> 8 FOR_ITER 12 (to 22) 10 STORE_FAST 2 (i) 4 12 LOAD_FAST 1 (s) 14 LOAD_FAST 2 (i) 16 INPLACE_ADD 18 STORE_FAST 1 (s) 20 JUMP_ABSOLUTE 8 5 >> 22 LOAD_FAST 1 (s) 24 RETURN_VALUE Inferencia de tipos: https://es.wikipedia.org/wiki/Inferencia_de_tipos. [08:32] Recogida de basuras. gc.set_threshold(): https://docs.python.org/3/library/gc.html#gc.set_threshold. gc.disable(): https://docs.python.org/3/library/gc.html#gc.disable. [11:27] Herramientas de monitorización: DTrace: http://dtrace.org/blogs/. Monitoriza el sistema operativo entero, incluyendo las aplicaciones, todo integrado, de forma segura y sin modificar el software. [13:32] Funcionalidades de auditoría de Python: PEP 551 -- Security transparency in the Python runtime https://www.python.org/dev/peps/pep-0551/. PEP 578 -- Python Runtime Audit Hooks https://www.python.org/dev/peps/pep-0578/. [16:47] Más herramientas de monitorización: SystemTap: https://es.wikipedia.org/wiki/SystemTap. eBPF: https://ebpf.io/. py-spy: https://github.com/benfred/py-spy. [17:52] Más sobre DTrace https://es.wikipedia.org/wiki/DTrace_(Sun_Microsystems) y Python: Añadir sondas DTrace al intérprete de Python: https://www.jcea.es/artic/python_dtrace.htm. [22:12] Tracemalloc. tracemalloc: https://docs.python.org/3/library/tracemalloc.html. [23:02] Seguimos hablando del bug comentado la semana pasada. bug bpo35930: "Raising an exception raised in a "future" instance will create reference cycles": https://bugs.python.org/issue35930. ¡Se ofrece una caja de cervezas! Brainstorming. Diagnóstico detallado. weakref — Weak references: https://docs.python.org/3/library/weakref.html. Se sube la apuesta a caja y media de cervezas :-). La excepción salta en un hilo y se "transporta" y almacena para que se pueda acceder desde otro hilo. Test reproducible. [36:42] Aviso legal. Machine learning para identificar los diferentes hablantes. [38:27] Las futuras notas de las grabaciones serán EXHAUSTIVAS (como estáis comprobando leyendo esto :). [39:17] Ideas para "cebar" las tertulias. Muchos temas recurrentes, se ve que hay temas "flotando" en el aire. [40:37] Cómo organizar las tertulias, diferentes intereses y profundidad. Dinámica de la tertulia. [42:32] ¿Cómo se organizan los "core developers"? El desarrollo se ha movido en github. Los bugs están a medio migrar, se va a integrar más en github. https://pyfound.blogspot.com/2020/05/pythons-migration-to-github-request-for.html PEP 581 -- Using GitHub Issues for CPython https://www.python.org/dev/peps/pep-0581/. Guía del desarrollador: https://devguide.python.org/. Backporting de bugs de cpython de la versión en desarrollo a las versiones estables. ¿Cómo se obtiene y se pierde el status de "core developer"? Steering council. PEP 8016: https://www.python.org/dev/peps/pep-8016/. Rol que cumple y cómo se elige. Desde que Guido no es BDFL, está muy activo en listas de correo y picando código. [52:22] ¡Víctor quiere más bugs para aprender! Bugs marcados como "easy", como forma de entrada a desarrolladores nuevos. [53:42] ¿Qué partes de CPython están escritas en C y cuáles en Python? Se escribe en C lo que no tiene más remedio, por rendimiento o porque interactúa con el sistema operativo. Más adelante de la conversación Jesús Cea explica cómo ver si un módulo concreto está en C o en Python sin tener que ir al código fuente. [57:32] PyPy https://www.pypy.org/. Intérprete de Python escrito en Python. RPython: https://rpython.readthedocs.io/en/latest/. [58:27] ¿Incluir otros lenguajes en la implementación de CPython? Rust: https://es.wikipedia.org/wiki/Rust_(lenguaje_de_programaci%C3%B3n). PyOxidizer: https://github.com/indygreg/PyOxidizer. Fragmentación. Jesús Cea estoy más centrado en la parte de C porque la mayor parte de los "core developers" no saben C. Añadir más lenguajes reduce el grupo de gente que puede mantener esas partes. Portabilidad de C. Bootstraping de un lenguaje con el propio lenguaje. Forth: https://en.wikipedia.org/wiki/Forth_(programming_language). [01:05:02] Python 3.9. Mejoras. Dificultades para utilizar la última versión de Python, en función de lo que tenga el cliente. [01:08:07] Dataclasses: https://docs.python.org/3/library/dataclasses.html. La dificultad para tener atributos opcionales. Algunas ideas. attrs: https://www.attrs.org/en/stable/. Usar valores "sentinel". DRY: https://es.wikipedia.org/wiki/No_te_repitas. [01:20:52] Pydantic: https://pydantic-docs.helpmanual.io/. [01:23:07] Horarios de las tertulias. Mucha discusión y algunas ideas. De momento no habrá cambios. Hace falta más feedback. Se agradecería que la gente que deje las tertulias, explicase por qué se ha ido. [01:30:27] Jesús Cea explica cómo ver si un módulo concreto está en C o en Python sin tener que ir al código fuente. [01:31:18] Más sobre la dinámica de las tertulias. Debate sobre presentarse o no en tertulias abiertas, o tener la cámara apagada. Va siendo necesario tener algun repositorio para que la gente de la tertulia pueda compartir cosas. ¿Lista de correo específica para las tertulias? [01:36:42] Actas de las tertulias y publicar las grabaciones de una puñetera vez. ¿Algún ingeniero de sonido en la sala? ¿Baratito? [01:39:08] El "nivel" de las listas de correo. ¿Dónde están las conversaciones interesantes? (aparte de la tertulia semanal :-). La maldición de lo básico e "introducción a". Igual para que haya conversación interesante, hay que hacer preguntas interesantes :-). Python-Madrid antes de que llegase Meetup. Jesús Cea sugiere listas como "python-ideas": https://mail.python.org/mailman3/lists/python-ideas.python.org/. También la lista de programación Python en español: python-es@python.org. Javier tiene intereses muy extraños :-). [01:54:52] Cierre. [01:56:42] Final.

Más de lo que nunca quisiste aprender sobre JIT, guardas y especialización https://podcast.jcea.es/python/11 En lo que sigue, cuando se habla de CPython, se refiere al intérprete de referencia de Python, que está escrito en lenguaje C: https://www.python.org/downloads/. Participantes: Eduardo Castro, email: info@ecdesign.es. Conectando desde A Guarda. Jesús Cea, email: jcea@jcea.es, twitter: @jcea, https://blog.jcea.es/, https://www.jcea.es/. Conectando desde Madrid. Javier, conectando desde Madrid. Víctor Ramírez, twitter: @virako, programador python y amante de vim, conectando desde Huelva. Miguel Sánchez, email: msanchez@uninet.edu, conectando desde Canarias. Audio editado por Pablo Gómez, twitter: @julebek. La música de la entrada y la salida es "Lightning Bugs", de Jason Shaw. Publicada en https://audionautix.com/ con licencia - Creative Commons Attribution 4.0 International License. [00:52] Aviso de que se está grabando. Temas legales. [01:52] Valor de publicar estos audios y las dificultades para hacerlo. [02:42] Métodos mágicos: __set_name__(). PEP 487: https://www.python.org/dev/peps/pep-0487/. [04:12] Problemas con PIP 20.3.2: https://github.com/pypa/pip/issues/9284. [05:52] ¿Actualizar a la última versión o esperar? Poder "echar atrás" fácil. Acumular cambios pendientes es deuda técnica. [10:42] Google caído https://www.theguardian.com/technology/2020/dec/14/google-suffers-worldwide-outage-with-gmail-youtube-and-other-services-down. [11:02] Generación de wheels en varios sistemas: https://pythonwheels.com/. auditwheel: https://pypi.org/project/auditwheel/. ¿Generación de Wheels en Microsoft Windows? [13:12] Caché local de PIP https://pip.pypa.io/en/stable/. [14:17] Event Sourcing https://dev.to/barryosull/event-sourcing-what-it-is-and-why-its-awesome. Módulo eventsourcing: https://pypi.org/project/eventsourcing/. [14:42] De momento se puede usar el viejo "resolver" de dependencias de PIP. Se puede usar la opción -use-deprecated=legacy-resolver. Esa opción se puede meter también en el fichero de configuración, para no tener que escribirlo en cada invocación. Jesús Cea comete el pecado de meter paquetes Python en el sistema operativo. [17:02] Batallitas de Jesús Cea. Jesús lleva dos años dándole vueltas a esto: bpo35930: "Raising an exception raised in a "future" instance will create reference cycles": https://bugs.python.org/issue35930. Explicación detallada del asunto. Brainstorming. [21:22] Visión a alto nivel del recolector de basuras de Python (cpython) Contador de referencias. Inmediato, pero no recoge ciclos. Si se crean instancias y no se destruyen, se llama a un recolector "pesado" que también recoge ciclos. Esto puede ser problemático al arrancar el programa, antes de que la creación/destrucción de objetos se "estabilice". gc.disable(): https://docs.python.org/3/library/gc.html#gc.disable. Jesús Cea "abusa" de los destructores y de que se ejecuten cuando él quiere. Lo práctico contra lo puro. Jesús ofrece cervezas. gc.collect(): https://docs.python.org/3/library/gc.html#gc.collect. Esto sirve tanto para recoger los ciclos como para comprobar si tu programa tiene ciclos de memoria o no. Futures: https://docs.python.org/3/library/concurrent.futures.html. [35:29] Módulo Manhole https://pypi.org/project/manhole/. Explorar un programa en producción. Tracemalloc: https://docs.python.org/3/library/tracemalloc.html. DTrace: http://dtrace.org/blogs/about/. py-spy: https://pypi.org/project/py-spy/. Pérdidas de memoria: Recordar lo hablado ya en tertulias anteriores. jemalloc: http://jemalloc.net/. MALLOC_PERTURB_: https://debarshiray.wordpress.com/2016/04/09/malloc_perturb_/. zswap: https://en.wikipedia.org/wiki/Zswap. [42:52] Micropython: https://micropython.org/. ESP8266: https://en.wikipedia.org/wiki/ESP8266. ESP32: https://en.wikipedia.org/wiki/ESP32. Bluetooth Low Energy: https://en.wikipedia.org/wiki/Bluetooth_Low_Energy. ¿Qué ventajas aporta usar Micropython? Velocidad de desarrollo y depuración. [52:42] ¿El futuro será mejor? O no. Desperdicio de recursos materiales porque realmente sobran. Python es mucho más lento que C y no digamos ensamblador. [57:17] Cambiar Python por un lenguaje más rápido. Go: https://en.wikipedia.org/wiki/Go_(programming_language). Rust: https://en.wikipedia.org/wiki/Rust_(programming_language). C++: https://en.wikipedia.org/wiki/C%2B%2B. [01:00:20] Python no pinta nada en móviles. Kivy: https://kivy.org/. [01:02:07] Acelerar Python. Subinterpreters: PEP 554: https://www.python.org/dev/peps/pep-0554/. Si los subintérpretes no compartiesen NADA, se podrían lanzar simultaneamente en varios núcleos de la CPU sin competir por un GIL https://en.wikipedia.org/wiki/Global_interpreter_lock único. JIT: https://es.wikipedia.org/wiki/Compilaci%C3%B3n_en_tiempo_de_ejecuci%C3%B3n. PYPY: https://www.pypy.org/. RPython: https://rpython.readthedocs.io/en/latest/. Numba: https://numba.pydata.org/. Cython: https://cython.org/. Python es "potencialmente" muy dinámico, pero en la práctica los programas no lo son. Jesús pone varios ejemplos. Conversación densa entre Jesús y Javier. Guardas para comprobar que la especialización sigue siendo correcta. Por ejemplo, para los diccionarios: PEP 509 Add a private version to dict: https://www.python.org/dev/peps/pep-0509/ "Tipado" más estricto. MYPY: http://mypy-lang.org/. Pydantic: https://pydantic-docs.helpmanual.io/. Comprobación de tipos en tiempo de ejecución. Descubrimiento de tipos en tiempo de ejecución, proporcionando "especialización". psyco: https://en.wikipedia.org/wiki/Psyco. Eduardo Castro entra y simplifica la discusión. Jesús explica qué hace "a+b" internamente. [01:29:22] PyParallel http://pyparallel.org/ Memoria transaccional: https://es.wikipedia.org/wiki/Memoria_transaccional. (nota de Jesús Cea): Los sistemas de persistencia Python descritos en tertulias anteriores pueden considerarse casos de memoria transaccional... si somos flexibles. "Colorear" objetos y que dos hilos no puedan acceder a objetos del mismo color simultaneamente o en transacciones concurrentes. [01:30:42] PYPY https://www.pypy.org/ es tan sofisticado que no lo entiende ni dios. Jesús Cea lo ha intentado y se ha rendido. psyco: https://en.wikipedia.org/wiki/Psyco. CFFI: https://cffi.readthedocs.io/en/latest/. [01:35:22] Compilar CPython a WebAssembly https://en.wikipedia.org/wiki/WebAssembly va más rápido que en C nativo. [01:36:02] Simplemente compilar código python con Cython https://cython.org/ sin declaración de tipos dobla la velocidad de ejecución. ¡CPython lo puede hacer mejor! [01:36:57] Subinterpreters: PEP 554: https://www.python.org/dev/peps/pep-0554/. Poder usar todos los núcleos de la CPU. [01:38:07] Seguimos hablando del asunto. [01:39:07] Un problema es que Python tiene la vocación de funcionar en todas partes, así que hay resistencia para implementar mejoras solo en ciertas plataformas. [01:40:17] Cierre. Dadle una pesada al bug bpo35930: "Raising an exception raised in a "future" instance will create reference cycles": https://bugs.python.org/issue35930. [01:41:13] Final.

Doblegando a la culebra https://podcast.jcea.es/python/8 Se me oye (Jesús Cea) muy mal y es muy cansado porque hablo mucho y tengo mala calidad de sonido. Lo siento. Se han eliminado las pausas en la edición, así que es bastante cansado oír a Jesús Cea hablar a toda velocidad y sin respirar. Lo haremos mejor la próxima vez. Se oye mucho tecleo. Participantes: Eduardo Castro, email: info@ecdesign.es. Jesús Cea, email: jcea@jcea.es, twitter: @jcea, https://blog.jcea.es/, https://www.jcea.es/. Sara Sáez, twitter: @saruskysaez. Luis. Audio editado por Pablo Gómez, twitter: @julebek. La música de la entrada y la salida es "Lightning Bugs", de Jason Shaw. Publicada en https://audionautix.com/ con licencia Creative Commons Attribution 4.0 International License. [01:42] API limitado API limitado de Python para asegurar compatibilidad binaria de extensiones en C entre versiones diferentes del intérprete de Python. PEP 384: https://www.python.org/dev/peps/pep-0384/. [03:42] Por qué empecé a usar Python. [06:52] Eduardo: Cartas de restaurante con códigos QR: https://www.qrico.eu/. [10:42] ¿Es mejor que una biblioteca esté en la biblioteca estándar de Python o ser una librería externa? Tema recurrent. Pros y contras. [18:34] Soporte de Python en MS Windows. Distribución de librerías precompiladas. ¿Cómo compilar una extensión C en MS Windows? [20:52] Problema de las distribuciones binarias cuando sale una nueva versión de Python. Es una de las motivaciones para usar el API limitado definido en PEP 384: https://www.python.org/dev/peps/pep-0384/. [23:22] Sistema de notificación de actualizaciones de librerías. Por ejemplo: https://libraries.io/. Feed RSS de PYPI: https://pypi.org/rss/updates.xml. ¿Actualizas a la última versión? Pros y contras. [28:22] Mejor entrar con vídeo a la tertulia. [29:12] Debugging de uso de memoria y memory leaks. Flamegraphs: http://www.brendangregg.com/flamegraphs.html. Tracemalloc: https://docs.python.org/3/library/tracemalloc.html. [33:52] Virtualenv, ¿qué usa cada uno? ¿Y en MS Windows? [35:52] Soporte de Python en MS Windows. La mayor parte del uso de Python es en MS Windows, pero los "core developers" no usar MS Windows. Eso causa problemas de soporte. [40:52] Guido van Rosum y Microsoft. Guido van Rosum ha empezado a trabajar para Microsoft: https://www.msn.com/en-us/news/technology/python-creator-guido-van-rossum-joins-microsoft/ar-BB1aXmPu. [44:22] ¿Ya estáis usando Python 3.9? El API limitado se va ampliando versión a versión de Python. PEP 384: https://www.python.org/dev/peps/pep-0384/. [45:22] Opciones para acelerar la ejecución de código Python. Numba https://numba.pydata.org/. Cython https://cython.org/. Pero una vez que empiezas etiquetar tipos, el código resultante ya no es Python. El futuro es type hinting: PEP 484 https://www.python.org/dev/peps/pep-0484/. Programar una extensión en C nativo. PyPy https://www.pypy.org/. Ojo con la compatibilidad. [54:32] Métodos para enlentecer Python :-) [55:12] Protección de código en Python. Cython https://cython.org/. [58:47] Mezclar código C en Python. Programar un módulo C. CFFI: https://cffi.readthedocs.io/en/latest/. [01:01:52] Guido van Rosum y Microsoft (segunda parte) Volvemos al tema de Guido van Rosum trabajando para Microsoft: https://www.msn.com/en-us/news/technology/python-creator-guido-van-rossum-joins-microsoft/ar-BB1aXmPu. La polémica del "walrus operator" u "operador morsa". [01:05:22] "Operador morsa" o "Walrus operator". PEP 572 https://www.python.org/dev/peps/pep-0572/. Tema recurrrente: Python se está complicando cada vez más. Problema para los novatos. [01:14:32] Opciones para acelerar la ejecución de código Python (2). Otra forma de acelerar Python: MYPY http://mypy-lang.org/ y MYPYC https://github.com/mypyc/mypyc. Type hinting. PEP 484 https://www.python.org/dev/peps/pep-0484/. [01:17:42] ¿Python con tipos? Motivación. [01:20:52] ¿Quien paga los tests? [01:22:37] Los tests como documentación. [01:23:32] ¿Qué usais para tests? [01:26:22] ¿Qué hace cada uno con Python? Hobby, Zope https://zope.readthedocs.io/en/latest/, imágenes, numpy https://numpy.org/, Jupyter https://jupyter.org/. Persistencia de datos y ORMs. Integrar Python dentro de otros proyectos, como en Kodi https://www.kodi.tv/. Django https://www.djangoproject.com/, micropython http://www.micropython.org/. [01:33:12] Colofón y mi motivación para las tertulias.

Sponsored by Techmeme Ride Home podcast: pythonbytes.fm/ride Special guest: Steve Dower - @zooba Brian #1: Making Enums (as always, arguably) more Pythonic “I hate enums” Harry Percival Hilarious look at why enums are frustrating in Python and a semi-reasonable workaround to make them usable. Problems with enums of strings: Can’t directly compare enum elements with the values Having to use .value is dumb. Can’t do random choice of enum values Can’t convert directly to a list of values If you use IntEnum instead of Enum and use integer values instead of strings, it kinda works better. Making your own StringEnum also is better, but still doesn’t allow comparison. Solution: class BRAIN(str, Enum): SMALL = 'small' MEDIUM = 'medium' GALAXY = 'galaxy' def __str__(self) -> str: return str.__str__(self) Derive from both str and Enum, and add a *__str(self)__* method. Fixes everything except random.choice(). Michael #2: Python 3.10 will be up to 10% faster 4.5 years in the making, from Yury Selivanov work picked up by Pablo Galindo, Python core developer, Python 3.10/3.11 release manager LOAD_METHOD, CALL_METHOD, and LOAD_GLOBAL improved “Lot of conversations with Victor about his PEP 509, and he sent me a link to his amazing compilation of notes about CPython performance. One optimization that he pointed out to me was LOAD/CALL_METHOD opcodes, an idea first originated in PyPy.” There is a patch that implements this optimization Based on: LOAD_ATTR stores in its cache a pointer to the type of the object it works with, its tp_version_tag, and a hint for PyDict_GetItemHint. When we have a cache hit, LOAD_ATTR becomes super fast, since it only needs to lookup key/value in type's dict by a known offset (the real code is a bit more complex, to handle all edge cases of descriptor protocol etc). Steve #3: Python 3.9 and no more Windows 7 PEP 11 -- Removing support for little used platforms | Python.org Windows 7 - Microsoft Lifecycle | Microsoft Docs Default x64 download Brian #4: Writing Robust Bash Shell Scripts David Pashley Some great tips that I learned, and I’ve been writing bash scripts for decades. set -u : exits your script if you use an uninitialized variable set -e : exit the script if any statement returns a non-true return value. Prevents errors from snowballing. Expect the unexpected, like missing files, missing directories, etc. Be prepared for spaces in filenames. if [ "$filename" = "foo" ]; Using trap to handle interrupts, exits, terminal kills, to leave the system in a good state. Be careful of race conditions Be atomic Michael #5: Ideas for 5x faster CPython Twitter post by Anthony Shaw calling attention to roadmap by Mark Shannon Implementation plan for speeding up CPython: The overall aim is to speed up CPython by a factor of (approximately) five. We aim to do this in four distinct stages, each stage increasing the speed of CPython by (approximately) 50%: 1.5**4 ≈ 5 Each stage will be targeted at a separate release of CPython. Stage 1 -- Python 3.10: The key improvement for 3.10 will be an adaptive, specializing interpreter. The interpreter will adapt to types and values during execution, exploiting type stability in the program, without needing runtime code generation. Stage 2 -- Python 3.11: Improved performance for integers of less than one machine word. Faster calls and returns, through better handling of frames. Better object memory layout and reduced memory management overhead. Stage 3 -- Python 3.12 (requires runtime code generation): Simple "JIT" compiler for small regions. Stage 4 -- Python 3.13 (requires runtime code generation): Extend regions for compilation. Enhance compiler to generate superior machine code. Wild conversation over here. One excerpt, from Larry Hastings: Speaking as the Gilectomy guy: borrowed references are evil. The definition of the valid lifetime of a borrowed reference doesn't exist, because they are a hack (baked into the API!) that we mostly "get away with" just because of the GIL. If I still had wishes left on my monkey's paw I'd wish them away (1). (1) Unfortunately, I used my last wish back in February, wishing I could spend more time at home.* Steve #6: CPython core developer sprints Hosted by pythondiscord.com https://youtu.be/gXMdfBTcOfQ - Core dev Q&A Extras Brian: Tools I found recently that are kinda awesome in their own way - Brian mcbroken.com - Is the ice cream machine near you working? just a funny single purpose website vim-adventures.com - with a dash. Practice vim key bindings while playing an adventure game. Super cool. Joke: Hackobertfest 2020 t-shirt https://twitter.com/McCroden/status/1319646107790704640 5 Most Difficult Programming Languages in the World (Not really long enough for a full topic, but funny. I think I’ll cut short the last code example after we record) suggested by Troy Caudill Author: Lokajit Tikayatray malboge, intercal, brainf*, cow, and whitespace whitespace is my favorite: “Entire language depends on space, tab, and linefeed for writing any program. The Whitespace interpreter ignores Non-Whitespace characters and considers them as code comments.” Intercal is kinda great in that One thing I love about this article is that the author actually writes a “Hello World!” for each language. Examples of “Hello World!” malboge (=

Google could be extending its Firefox search royalty deal, PyPy leaves the Software Freedom Conservancy, Ubuntu puts out a call for testing, Linspire removes snapd support, Microsoft showcases its open source contributions, and Facebook joins The Linux Foundation.

Special guest: Ines Montani Michael #1: VS Code Device Simulator Want to experiment with MicroPython? Teaching a course with little IoT devices? Circuit Playground Express BBC micro:bit Adafruit CLUE with a screen Get a free VS code extension that adds a high fidelity simulator Easily create the starter code (main.py) Interact with all the sensors (buttons, motion sensors, acceleration detection, device shake detection, etc.) Deploy and debug on a real device when ready Had the team over on Talk Python. Brian #2: pytest 6.0.0rc1 New features You can put configuration in pyproject.toml Inline type annotations. Most user facing API and internal code. New flags - --no-header - --no-summary - --strict-config : error on unknown config key - --code-highlight : turn on/off code highlighting in terminal Recursive comparison for dataclass and attrs Tons of fixes Improved documentation There’s a list of breaking changes and deprications. But really, nothing in the list seems like a big deal to me. Plugin authors, including myself, should go test this. Already found one problem. pytest-check: stop on fail works fine, but failing tests marked with xfail show up as xpass. Gonna have to look into that. And might have to recruit Anthony to help out again. To try it: pip install pytest==6.0.0rc1 I’m currently running through the pytest book to make sure it all still works with pytest 6. So far, so good. The one hiccup I’ve found so far, TinyDB had a breaking change with 4.0, so you need to pip install tinydb==3.15.2 to get the tasks project to run right. I should have pinned that in the original setup.py. However, all of the pytest stuff is still valid. Guido just tweeted: “Yay type annotations in pytest!” Ines #3: TextAttack Python framework for adversarial attacks and data augmentation for natural language processing What are adversarial attacks? You might have seen examples like these: image classifier predicting a cat even if the image is complete noise people at protests wearing shirts and masks with certain patterns to trick facial recognition Google Translate hallucinating bible texts if you feed it nonsense or repetitive syllables What does it mean to "understand" a model? How does it behave in different situations, with unexpected data? We can't just inspect the weights – that's not how neural networks work To understand a model, we need to run it and find behaviours we don't like TextAttack lets you run various different “attacks” from the current academic literature It also lets you create more robust training data using data augmentation, for example, replacing words with synonyms, swapping characters, etc. Michael #4: What is the core of the Python programming language? By Brett Cannon, core developer Brett and I discussed Python implementation for WebAssembly before Get Python into the browser, but with the fact that both iOS and Android support running JavaScript as part of an app it would also get Python on to mobile. We have lived with CPython for so long that I suspect most of us simply think that "Python == CPython". PyPy tries to be so compatible that they will implement implementation details of CPython. Basically most implementations of Python strive to pass CPython's test suite and to be as compatible with CPython as possible. Python’s dynamic nature makes it hard to do outside of an interpreter That has led Brett to contemplate the question of what exactly is Python? How much would one have to implement to compile Python directly to WebAssembly and still be considered a Python implementation? Does Python need a REPL? Could you live without locals()? How much compatibility is necessary to be useful? The answer dictates how hard it is to implement Python and how compatible it would be with preexisting software. [Brett] has no answers It might make sense to develop a compiler that translates Python code directly to WebAssembly and sacrifice some compatibility for performance. It might make sense to develop an interpreter that targets WebAssembly's design but maintains a lot of compatibility with preexisting code. It might make sense to simply support RustPython in their WebAssembly endeavours. Maybe Pyodide will get us there. Michael’s thoughts: How about a Python standard language spec? A standard-library “standard???!?” spec. It’s possible - .NET did it. What would be build if we could build it with web assembly? Interesting options open up, say with NodeJS like capabilities, front-end frameworks This could be MUCH bigger if we got browser makes to support alternative runtimes through WebAssembly Brian #5: Getting started with Pathlib Chris May Blog post: Stop working so hard on paths. Get started with pathlib! PDF “field guide”: Getting started with Pathlib Really great introduction to Pathlib Some of the info This file as a path object: Path(__file__) Parent directory: Path(__file__).parent Absolute path: Path(__file__).parent.resolve() Two levels up: Path(__file__).resolve(strict=True).parents[1] See pdf for explanation. Current working dir: Path.cwd() Path building with / Working with files and folders Using glob Finding parts of paths and file names. Any time spent learning Pathlib is worth it. If I can do it in Pathlib, I do. It makes my code more readable. Ines #6: Data Version Control (DVC) We're currently working on v3.0 of spaCy and one of the big features is going to be a completely new way to train your custom models, manage end-to-end training workflows and make your experiments reproducible It will also integrate with a tool called DVC (short for Data Version Control), which we've started using internally DVC is an open-source tool for version control, specifically for machine learning and data Machine learning = code + data. You can check your code into a Git repo, but you can't really check in your datasets and model weights. So it's very difficult to keep track of changes. You can think of DVC as “Git for data” and the command line usage is actually pretty similar – for example, you run dvc init to initialize a repo and dvc add to start tracking assets DVC lets you track any assets by adding meta files to your repository. So everything, including your data, is versioned, and you can always go back to the commit with the best accuracy It also builds a dependency graph based on the inputs and outputs of each step, so you only have to re-run a step if things changed for example, you might have a preprocessing step that converts your data and then a step that trains your model. If the data hasn't changed, you don't have to re-run the preprocessing step. They recently released a new tool called CML (short for Continuous Machine Learning), which we haven't tried yet. CI for Machine Learning Previews look pretty cool: you can submit a PR with some changes and a GitHub action will run your experiment and auto-comment on the PR with the results, changes in accuracy and some graphs (similar to tools like Code Coverage etc.) Extra Michael: Podcast Python Search API package, by Anton Zhiyanov Mid-string f-string upgrades coming to PyCharm. And Flynt! via Colin Martin Ines: Built-in generic types in 3.9 (PEP 585): you can now write list[str] ! Brian: https://testandcode.com/120: FastAPI & Typer - Sebastián Ramírez Jokes Fast API Job Experience Sebastián Ramírez - @tiangolo I saw a job post the other day. It required 4+ years of experience in FastAPI. I couldn't apply as I only have 1.5+ years of experience since I created that thing. Maybe it's time to re-evaluate that "years of experience = skill level". Defragged Zebra

newline Podcast Sudo StephNate: [00:00:00] Steph, just tell us a little bit about your work and kind of your background with, like AWS and like what you're doing now.Steph: [00:00:06] Yes, so I work as a engineer for a manage services provider called Second Watch. We basically partner with other big companies that use AWS or some other clouds sometimes Azure for managing their cloud infrastructure, which basically just means that.We help big companies who may not, their focus may not be technology, it may not be cloud stuff in general, and we're able to just basically optimize the cost of everything, make sure that things are running reliably and smoothly, and we're able to work with AWS directly to kind of keep people ahead of the curve when.New stuff is coming out and just it changes so much, you know, it's important to be able to adapt. So like personally, my role is I develop automation for our internal operations teams. So we have a bunch of, you know, just really smart people who are always working on customer specific AWS issues. And we see some of the same issues.Pop up over and over. Of course, you know, security , auditing, cost optimization. And so my team makes optimizations that we can distribute to all of these clients who have to maintain their own. You know, they have their own AWS account. It's theirs. And we make it so that we're actually able to distribute these automations same way in all of our customers' accounts.So the idea is that, and it's really wouldn't be doable without serverless because the idea is that everyone has to own their own infrastructure, right? Your AWS account is yours does or your resources, you don't, for security reasons, want to put all of your stuff on somebody else's account. But actually managing them all the same way can be a really difficult, even with scripts, because permissions different places have to be granted through the AWS permissions up with  access, I identity and access management, right? So serverless gave us the real tool that we needed to be able to at scale, say, Hey, we came up with a little script that will run on an hourly basis to check to see how much usage these servers are getting, and if they're not production servers, you know, spin them down if they're not in use to save money.Little things like that when it comes to operations and AWS Lambda is just so good for it because it's all about, you know, like I said, doing things reliably. Doing things in a ways that can be audited and logged and doing things for like a decent price. So like background wise, I used to work at AWS in AWS support actually, and I kind of supported some of their dev ops products like OpsWorks, which is based on chef for configuration management, elastic Beanstalk and AWS CloudFormation, specifically. After working there for a bit, I really got to see, you know, how it's made and what the underlying system is like. And it was just crazy just to see how much work goes into all this, just so you can have a supposedly, easier to use for an end. But serverless just kinda changed all that for the better.Luckily.Amelia: [00:02:57] So it sounds like AWS has a ton of different services. What are the main ones and how many are there?Steph: [00:03:04] So I don't think I can even count anymore because they just, they do release new ones all the time. So hundreds at this point, but really main ones, and maybe not hundreds, maybe a little over a hundred would be a better estimate.I mean,  EC2 which is elastic compute is. The bread and butter. Historically, AWS is just, they're virtualized servers basically. So EC2, the thing that made AWS really special from the beginning and that made cloud start to take over the world was the concept of auto scaling groups, which are basically definitions you attached to EC2 and it basically allows you to say, Hey, if I start getting a lot of traffic on.This one type of server, right? You know, create a second server that looks exactly the same and load balance the traffic through it. So when they say scaling, that's basically what, how you scale, easy to use auto scaling groups and elastic load balancers and kind of distribute the traffic out. The other big thing besides the scalability of  with auto scaling groups is.Redundancy. So there's this idea of regions within AWS, and within each region there's availability zones. So regions are the general, like you can think of it as the place where data center is kind of like located within like a small degree. So it's usually like. Virginia is one, right? That's us East one.It's the oldest one. Another one is in California, but they're all over the world now. So the idea is you pick a region to minimize latency, so you pick the region that's closest to you. And then within the region, there's the idea of availability zones, which are basically just discreet, like physical locations of the servers that you administer them the same way, but they're protected.So like if a tornado runs through and hits one of your data centers. If you happen to have them distributed between two different availability zones, then you'll still be able to, you know, serve traffic. The other one will go down, but then the elastic load balancer will just notice that it's not responding and send the traffic to the other availability zone.So those are the main concepts that make it like EC2 those are what you need to use it effectively.Nate: [00:05:12] So with an easy to instance, that would be like a virtual server. I mean, it's not quite a Docker container, I guess we're getting to nuance there, but it's basically like a server that you would have like command line access to.You could log in and you can do more or less whenever you want on an EC2 instance.Steph: [00:05:29] Right, exactly. And so it used to be AWS used what was called Zen virtualization to do it. And that's just like you can run Zen on your own computer, you can get a computer and set up a virtual machine, almost just like they used to do it .So they are constantly putting out like new ways of virtualizing more efficiently. So they do have new technology now, but it's not something that was really, I mean, it was well known, but they really took it to a new kind of scale, which made it really impressive.Nate: [00:05:56] Okay, so EC2 lets you have full access to the box that's running and you might like load bounce requests against that.How does that contrast with what you do with AWS Lambda and serverless?Steph: [00:06:09] So with , you still have to, you know, either secure shell or, you know, furious and windows. Use RDP or something to actually get in there. You care about what ports are open. You have security groups for that. You care about all the stuff you would care about normally with a server you care about.Is it patched and up today you care about, you know, what's the current memory and CPU usage? All those things don't go away on EC2 just because it's cloud, right? When we start bringing serverless into the mix, suddenly. They do go and away. I mean, and there's still a few limitations. Like for instance, a Lambda has a limit on how much memory it can process with, just because they have to have a way to kind of keep costs down and define the units of them and define where to put them.Right? But at its core, what a Lambda is, it actually runs on a Docker container. You can think of it like a pre-configured Docker container with some pre-installed dependencies. So for Python, it would have. The latest version of Python that it says it has, it would have boto. It would have the stuff that it needs to execute that, and it would also have some basic, it's structured like it was, you know, basic Linux.So there's like a attempt. So slash temp you can write files there, right. But really it's like a Docker container. That runs underneath it on a fleet of . As far as availability zone distribution goes, that's already built into land, but you don't have to think about it with . You do have to think about it.Because if you only run one easy to server and it's in one availability zone, it's not really different from just having a physical server somewhere with a traditional provider.Nate: [00:07:38] So. There are these two terms, there's like serverless and Lambda. Can you talk a little bit about like the difference between those two terms and when to use each appropriately?Steph: [00:07:48] Yeah, so they are in a way sorta interchangeable, right? Because serverless technology just means the general idea of. I have an application, I have it defined it an artifact of we'll say zip from our get repo, right? So that application is my main artifact, and then I pass it to a service somewhere. I don't know.It could be at work. The Google app engine, that's a type of serverless technology and AWS Lambda is just the specific AWS serverless technology. But the reason AWS Lambda is, in my opinion so powerful, is because it integrates really well with the other features of AWS. So permissions management works with AWS Lambda API gateway.there's a lot of really tight integrations you can make with Lambda so that it doesn't, it's not like you have to keep half of your stuff one place and half of your stuff somewhere else. I remember when like Heroku was really big . A lot of people, you know, maybe they were maintaining an AWS account and they were also maintaining a bunch of  stuff and Heroku, and they're just trying to make it work together.And even though Heroku does use, you know, AWS on the backend, or at least it did back then, it can just make things more complicated. But the whole server, this idea of the artifact is you make your code general, it's like a little microservice in a way. So I can take my serverless application and ideally, you know, it's just Python.I use NF, I write it the right way. Getting it to work on a different server. This back end, like for, exit. I think Azure has one, and Google app engine isn't really too much of a change. There's some changes to permissions and the way that you invoke it, but at the core of it, the real resource is just the application itself.It's not, you know, how many, you know, units of compute. Does it have, how many, you know, how much memory, what are the IP address rules and all that. YouNate: [00:09:35] know. So what are some good apps to build on serverless?Steph: [00:09:39] Yes. So you can build almost anything today on serverless, there's actually so much support, especially with AWS Lambda for integrations with all these other kinds of services that the stuff you can't do is getting more limited.But there is a trade off with cost, right? Because. To me the situation where it shines, where I would for no reason ever choose anything but serverless, is if you have something that's kind of bursty. So let's say you're making like a report generation tool that needs to run, but really you only run it three times a week or something like things that.They need to live somewhere. They need to be consistent. They need to be stable, they need to be available, but you don't know how often they're going to call. And even if they can go from that, there is small numbers of times it's being called, because the cool thing about serverless is , you're charged per every 100 milliseconds of time that it's being processed.When it comes to , you're charged and units that are, it used to be by the hour, I think they finally fixed it, and it's down to smaller increments. . But if you can write it. Efficiently. You can save a ton of money just by doing it this way, depending on what the use cases. So some stuff, like if you're using API gateway with Lambda, that actually can.Be a lot more expensive than Lambda will be. But you don't have to worry about, especially if you need redundancy. Cause otherwise you have to run a minimum of two  two servers just to keep them both up for a AZ kind of outages situation. You don't have to worry about that with Lambda. So anything that with lower usage 100%.If it's bursty 100% use Lambda, if it's one of those things where you just don't have many dependencies on it, then Lambda is a really good choice as well. So there's especially infrastructure management, which is, if you look, I think Warner Vogels, he wrote something recently about how serverless driven infrastructure automation is kind of going to be the really key point to making places that are using cloud use cloud more effectively.And so that's one group of people. That's a big group of people. If you're a big company and you already use the AWS and you're not getting everything out of it that you thought you would get. Sometimes there's serverless use cases that already exist out there and like there's a serverless application repo that AWS provides and AWS config integrations, so that if you can trigger a serverless action based off of some other resource actions. So like, let's say that your auto scaling group  scaled up and you wanted to like notify somebody, there's so many things you could do with it. It's super useful for that. But even if you're just, I'm co you're coming at it from like a blank slate and you want to create something .There are a lot of really good use cases for serverless. If you are, like I said, you're not really sure about how it's going to scale. You don't want to deal with redundancy and it fits into like a fairly well-defined, you know, this is pretty much all Python and it works with minimal dependencies. Then it's a really good starting place for that.Nate: [00:12:29] You know, you mentioned earlier that serverless is very good for when you have bursty services in that if you were to do it based on  and then also get that redundancy one. You're going to have to run while you're saying you'll have to run at least two EC2 instances, just 24 hours a day. I'm paying for those.Plus you're also going to pay for API gateway. Do you pay hourly for API gatewaySteph: [00:12:53] API gateway? It, it would work the same either way, but you would pay for, in that case, like a load balancer.Nate: [00:12:59] What is API gateway? Do you use that for serverless?Steph: [00:13:02] All the time. So API gateway?Nate: [00:13:04] Yeah. Tell us the elements of a typical serverless stack.So I understand there's like Lambda, for example, maybe you say like you use CloudFront. In front of your Lambda functions, which may be store images and S3 that like a typical stack? And then can you explain like what each of those services are,Steph: [00:13:22] how you would do that? Yeah, so you're, you're not, you're on the right track here.So, okay. So a good way to think about it is, if you look at AWS has published something which a lot of documentations on it called the serverless application management standard. So S a N. And so basically if you look at that, it actually defines the core units of serverless applications. So which is the function, an API, if you, if you want one.And basically any other permission type resources. So in your case, let's say it was something where I just wanted like a really. Basic tutorial that AWS provides is someone wants to upload an image for their profile and you want to, you know, scale it down to like a smaller image before you store it on your S3.You know, just so they're all the same size and it saves you a ton, all that. So if you're creating something like that, the AWS resources that you would need are basically an API gateway, which is. Acts as basically the definition of your API schema. So like if you've ever used swagger or like a open API, these standards where you basically just define, and JSON, you know it's a rest API, you do get here, post here, this resource name.That's a standard that you might see outside of AWS a lot. And so API Gateway is just basically a way to implement that same standard. They work with AWS. So that's how you can think of API gateway. It also manages stuff like authentication integration. So if you want to enable OAuth or something on something, you could set that up the API gateway level.SoNate: [00:14:55] if you had API gateway set up. Then is that basically a web server hosted by Amazon?Steph: [00:15:03] Yeah, that's basically it.Nate: [00:15:05] And so then your API gateway is just  assigned essentially randomly a DNS name by Amazon. If you wanted to have a custom DNS name to your API gateway. How do you do that?Steph: [00:15:21] Oh, it's just a setting.It's pretty. so what you could do, yeah, so if you already have a domain name, right? Route 53 which is AWS is domain name management service, you can use that to basically point that domain to the API gateway.Nate: [00:15:35] So you'd use route 53 you configure your DNS to have route 53 point a specific DNS name to your API gateway, and your API gateway would be like a web server that also handles like authentication and AWS integration. Okay,Steph: [00:15:51] got it. Yeah, that's a good breakdown of what that works. So that's your first kind of half of how people commonly trigger Lambdas. And that's not the only way to trigger it, but it's a very common way to do it. So what happens is when the API gateway is configured, part of it is you set what happens when the method is invoked.So there's like a REST API as a type of API gateway that. People use a lot. There's a few others, like a web socket, one which is pretty cool for streaming uses, and then they're always adding new options to it. So it's a really neat service. So you would have that kind of input go into your API gate.We would decide where to route it. Right. So in a lot of cases here, you might say that the Lambda function is where it gets routed to. That's considered the integration to it. And so basically API gateway passes it all of this stuff from the requests that you want to pass it. So, you know, I want to give it the content that was uploaded.I want to give it the IP address. It originally came from whatever you want to give it.Nate: [00:16:47] What backend would people use for API gateway other than Lambda? Like would you use an API gateway in front of an EC2 instance?Steph: [00:16:56] You could, but I would use probably a load balancer or application load balancer and that kind of thing.There's a lot of things you can integrate it for. Another cool one is, AWS API calls. It can proxy, so it can just directly take input from an API and send it to a specific API call if you want to do that. That's kind of some advanced usage, but Lambdas are kind of what I see is the go-to right now.Nate: [00:17:20] So the basic stack that we're looking at is you use API gateway to be in front of your Lambda function, and then your Lambda function just basically does the work, which is either like a writing to some sort of storage or calculating some sort of response. You mentioned earlier, you said, you know the Lambda function it can be fronted by an API if you want one. And then you mentioned, you know, there's other ways that you can trigger these Lambda functions. Can you talk a little bit about like what some of those other ways are?Steph: [00:17:48] Yeah, so actually those are really cool. So the cool thing is that you could trigger it based off of basically any type of CloudWatch event is a big one.And so CloudWatch is basically a monitoring slash auditing kind of service that AWS provides. So you can set triggers that go off when alarms are set. So. It could be usage, it could be, Hey, somebody logged in from an IP address that we don't recognize. You could do some really cool stuff with CloudWatch events specifically. And so those are one that I think for like management purposes are really powerful to leverage. But also you can do it off of S3 events, which are really cool. So like you could just have it, so anytime somebody uploads a. Let's say it was a or CI build, right?  You're doing IA builds and you're putting your artifacts into a S three bucket, so you know this is released version 1.1 or whatever, right?You put it into an S3 bucket, right? You can hook it up so that when ever something gets put into that S3 bucket. That another action is that takes place so you can make it so that, you know, whenever we upload a release, then you know, notify these people. So now an email or you can make it so that it, you know, as complicated as you want, you can make it trigger a different kind of part in your build stage.If you have things that are outside of AWS, you can have it trigger from there. There's a lot of really cool, just direct kind of things that you don't need. An API for. An S3 is a good one. The notification service, SNS it's used within AWS a lot that can be used. The queuing service AWS provides called SQS.It works with, and also just scheduled events, which I really like because it replaces the need for a crown server. So if you have things that run, you know, every Tuesday or whatever, right, you can just trigger your Lambda to do that from just one configuration point, you don't have to deal with anything more complicated than that.Nate: [00:19:38] I feel like that gives me a pretty good grounding in the ecosystem, in the setting. Maybe we could talk a little bit more about tools and tooling. Yeah, so I know that in the JavaScript world, on like the node world, they have the serverless framework, which is basically this abstraction over, I think it's over like Lambda and you know, Azure functions and Google up.Google cloud probably too. Do they have like a serverless framework for Python or is there like a framework that you end up using? Or do you just generally just write straight on top of Lambda?Steph: [00:20:06] So that's a great question and I definitely do recommend that even though there is like a front end you could do to just start, you know, typing code in and making the Lambda work right.It's definitely better to have some sort of framework that. Integrates with your actual, like, you know, wherever you use to store your code and test it and that kind of thing. So serverless is a really big one, and that's, it's kind of annoying because serverless, you know, it also refers to the greater ecosystem of code that runs without managing underlying servers.But in this particular case, Serverless is also like a third party company in tooling, and it does work for Python. It works for, a whole budget. That's kind of like the serverless equivalent in my head of like Terraform, something that is kind of meant to be kind of generic, but it offers a lot of kind of value to people just getting started. If you just want to put something in your, read me that says, here's how to, you know, deploy this from Github. You know, serverless is a cool tool for that. I don't personally like building with it myself just because I find that this SAM, which is Serverless Application Model, I think I said management earlier, but it's actually model.I just looked that up. I feel like that has everything I really want for AWS and I get more fine grain control. I don't like having too much obstruction and I also don't like. When you have to install something and something changes between versions and that changes the way your infrastructure gets deployed.That's a pet peeve of mine, and that's why I don't really use Terraform too much for the same reason. When you're operating really in one world, which in my case is AWS, I just don't get the value out of that. Right. But with the serverless application model, and they have a whole Sam CLI, they have a bunch of tools coming out.So many examples on their Github repos as well. I find that it's got really everything. I want to use plus some CloudFormation plugs right into that. So if I need to do anything outside of the normal serverless kind of world, I can do that. So it's better to use serverless than to not use anything at all.  I think it's a good tool and really good way to kind of get used to it and started, but at least my case where it really matters to have super consistent deployments where I'm sharing between people and accounts and all of that. And I find that SAM really gives me the best kind of best of both worlds.Amelia: [00:22:17] So, as far as I understand it, serverless is a fairly new concept.Steph: [00:22:22] You know, it's one of those things it's catching on. Recently, I felt like Google app engine candidate a long time ago, and it was kind of a niche thing for awhile, but it recently it, we're starting to see. Bigger enterprises, people who might not necessarily want bleeding edge stuff start to accept that serverless is going to be the future.And that's why we're seeing all this stuff come up and it's, it's actually really exciting. But the good thing is it's been around long enough that a lot of the actual tooling and the architecture patterns that you will use are mature. They've been used for years. Their sites you've been using for a long time that.You don't know that it's serverless on the back end, but it is because it's one of those things that doesn't really affect you unless you're kind of working on it. Right. But it's new to a lot of people, but I think it's in a good spot where it's more approachable than it used to be.Nate: [00:23:10] When you say that there's like a lot of standard patterns, maybe we could talk about some of those.So when you write a Lambda function and code, either with like Python or Java script or whatever, there are bloods, they say Python because you use Python primarily right? Well, maybe we could talk a little bit about that. Like why do you prefer Python?Steph: [00:23:26] Yeah, so just coming from my background, which is, like I said, I did some support, did some straight dev ops, kind of a more assisted mini before the world kind of became a more interesting place kind of background.Python is just one of those tools that is installed on like every Linux server in the world and works kind of predictably. Enough people know it that it's, it's not too hard to like. Share between people who may not be, you know, super advanced developers, right? Cause a lot of people I work with, maybe they have varying levels of skills and Python's one of those ones you can start to pick up pretty quickly.And it's not too foreign really to people coming from other languages as well. So it's just a practicality thing for a lot of it. But there's also a lot of the tooling that is around. Dev ops type stuff is in Python, like them, Ansible for configuration management, super useful tool. You know, it's all Python.So really there's, there's a lot of good reasons to use Python from, like in my world it's, it's one of the things where you don't have to use one specific language, but Python is just, it has what I need and it gets, I can work with it pretty quickly. The ecosystems develop. There's still a lot of people who use it and it's a good tool for what I have to do.Nate: [00:24:35] Yeah, there's tons, and I was looking at the metrics. I think Python is like, last year was like one of the fastest growing programming languages too. There's a lot of new people coming into Python,Steph: [00:24:44] and a lot of it is data science people too, right? People who may not necessarily have a strong programming background, but there's the tooling they need in a Python already there.There's community, and it sucks that it's not as scary looking as some other languages, frankly. You know.Nate: [00:24:58] And what are some of the other like cloud libraries that Python has? Like I've seen one that's called like BotoSteph: [00:25:03] Boto is the one that Amazon provides as their SDK, basically. And so every Lambda comes bundled with Boto three you know, by default.So yeah, there was an older version of ODA for Python too. But Boto three is the main one everyone uses now. So yeah, Bodo is great. I use it extensively. It's pretty easy to use, a lot of documentation, a lot of examples, a lot of people answering questions about it on StackOverflow, but I'm really, every language does have an SDK for AWS these days, and they all pretty much work the same way because they're all just based off of.The AWS API APIs and all the API APIs are well-defined and pretty stable, so it's not too much of a stretch to use any other language, but Bono's the big one, the requests library in Python is super useful just because it makes it easier to deal with, you know, interacting with API APIs or interacting with requests to APIs.It's just all about, you know, HTP requests and all that. Some of the new Python three. Libraries are really good as well, just because they kind of improve. It used to be like with Python 2, you know, there's URL lib for processing requests and it was just not as easy to use. So people would always bundle a third party tool, like requests, but it's getting better.Also, you know, Python, there's some. Different options for testing Py unit and unit test, and really there's just a bunch of libraries that are well maintained by the community. There's a kazillion on PyPy, but I try to keep outside dependencies from Python to a total minimum because again, I just don't like when things change from underneath me, how things function.So it's one of the things where I can do a lot without. Installing third party libraries, so wherever I can avoid it, I do.Nate: [00:26:47] So let's talk a little bit about these patterns that you have. So Lambda functions generally have a pretty well defined structure, and it's basically through that convention. It makes it somewhat straightforward to write each function. Can you talk a little bit about like, I don't know, the anatomy of a Lambda function?Steph: [00:27:05] Yeah,  so at its basic core, the most important thing that every Lambda function in the world is going to have is something called a handler. And so the handler is basically a function that is accessed to begin the way that it starts.So, any Lambda function when it's invoked. So anytime you are calling it, it's called invoking a Lambda function. It sends it parameters that are event. An event is basically just the data that defines, Hey, this is stuff you need to act on. And it sends it something called context, which a lot of time you never touched the context object.But it's useful too, because AWS provides it with every Lambda and it's basically like, Hey, this is the ID of the currently running Lambda function. You know, this is where you're running. This is the Lambdas name. So like for logging stuff, context can be really useful. Or for stuff where it's like your function code may need to know something about where it is.You can save yourself time from, you don't have to use like an environment. They're able, sometimes if you can look in the context object. So at the core it's cause you have at least a file, you can name it whatever you want. A lot of people call it index and then within that file you define a function called handler.Again, it doesn't have to be called handler, but. That makes it easy to know which one it is, and it takes that event and context. And so really, if that's all you have, you can literally just have your Lambda file be one Python file that says, you can say def handler takes, you know, object and then return something.And then that can be it. As long as you define that index dot handler as your handler resource, which is, that's a lot of words, but basically we need to find your Lambda within AWS.  The required parameters are basically the handler URI, which is the name of the file, and then a.in the name of the handler function.So that's at its most basic. Every Lambda has that, but then you start, you know, scoping it out so you can actually know, organize your code decently. And then it's just a matter of, is there a read me there. Just like any other Python application really, you know, do you have a read me? Do you want to use like a requirements.txt file to like define, you know, these are the exact third party libraries that I'm going to be using.That's really useful. And if you're defining it with SAM, which I really recommend. Then there's a file called template.yaml And that's just contains the actual, like AWS resource definition, as well as any like CloudFormation defined resources that you're using. So you can make a template.yaml as the infrastructure kind of as code, and then everything else, just the code as code.Nate: [00:29:36] Okay. So unpacking that a little bit, you'll invoke this function and they'll basically be two arguments. One is the event that's coming in the event in particular, and then it'll also have the context, which is sort of metadata about the context in which this request is running. So you mentioned some of the things that come in the context, which is like what region you're in or what the name of the function is that you're on.What are some of the parameters in the event object.Steph: [00:30:02] So the interesting thing about the event object. Is, it can be anything. It just has to be basically a Python dictionary or basically, you know, you could think of it like a JSON, right? So it's not predefined and Lambda itself doesn't care what the event is.That's all up to your code to decide what is it, what is a valid event, and how to act on it. So API gateway if you're using that. There's a lot of example events, API gateway will send and so if you like ever try it, look at like the test events for Lambda, you'll see a lot of like templates, which are just JSON files with like expected outputs.But really it can be anything.Nate: [00:30:41] So the way that Lambda's structured is that API gateway will typically pass in an event that's maybe like the request was a POST request, and then it has these like query parameters or headers attached to it. And all of that would be within like the request object. But the event could also be like you mentioned like CloudWatch, like there's like a CloudWatch event that could come in and say, you basically just have to configure your handler to handle any of the events you expect that handler to receive.Steph: [00:31:07] Yeah, exactly.Nate: [00:31:09] So let's talk a little bit more about the development tooling. How in the world do you test these sorts of things? Like with, do you have to deploy every single time or tell us about like the development tooling that you use to test along the way.Steph: [00:31:22] Yeah. So I'm, one of the great things about SAM and there's some other tools for this as well, is that it lets you test your Lambdas locally before you deploy it, if you want.And the way that it does that is, I mentioned earlier that Lambda is really at its core, a container, like a Docker container running on a server somewhere. Is, it just creates a Docker container that behaves exactly like a Lambda would, and it sends your events. So you would just define basically a JSON with the expected data from either API gateway or whatever, right?You make a test one and then it will send it to that. It'll build it on demand for you and you test it all locally with Docker. When you like it, you use the same tool and it'll package it up and deploy it for you. So yeah, it's actually not too bad to test locally at all.Nate: [00:32:05] So you create JSON files of the events that you want it to handle, and then you just like invoke it with those particular events.Steph: [00:32:12] Yeah, so basically like if I created it like a test event, I would save it to my repo is tests slash API gateway event.json Had put in the data I expect, and then I would do like a SAM. So the command is like SAM, a local invoke, and then I would give it to the file path to the JSON, and it would process it.I'd see the exact same output that I would expect to see from Lambda. So it'll say, Hey, this took this many milliseconds to invoke the response code was this, this is what was printed. So it's really useful just for. It's almost a one to one with what you would get from Amazon Lambda output.Amelia: [00:32:50] And then to update your Lambda functions.Do you have to go inside the AWS GUI or can you do that from the command line.Steph: [00:32:57] yeah, no, you can do that from the command line with Sam as well. So there's a Sam package and Sam deploy command. It's useful if you need to use basically any type of CII testing service to like manage your deployments or anything like that.Then you can get a package it and then send it the package to your, Whatever you're using, like Gitlab or something, right. For further validation and then have Gitlab deploy it. Like if you don't want people to have deployed credentials on their local machine, that's the reason it's kind of broken up into two steps there.But basically you just do a command, Sam deploy, and what it does is it goes out to Amazon. It says, Hey, update the Lambda to point to this as the new resource artifact to be invoked. And if you're using and which I think it's enabled by default, not actually the versioning feature, it actually just adds another version of the Lambda so that if you need to roll back, you can just go to the previous one, which is really useful sometimes.Nate: [00:33:54] So let's talk a little bit about deployment. One of the things that I think is stressing when you are deploying Lambda functions is like, I have no idea how much it's going to cost. How is it going to cost to launch something, and how much am I going to pay? And I guess maybe you can kind of calculate if you estimate the number of requests you think you're going to get, but how do you approach that when you're writing a new function?Steph: [00:34:18] Yeah, so the first thing I look at is what's the minimum, basically timeout, what's the minimum memory usage? So number of invocations is a big factor, right? So like if you have free tier, I think it's like a million invocations you get, but that's like assuming like a hundred under a hundred milliseconds each.So when you just deploy it, there's no cost for just deploying it. You don't get charged until it's invoked. If you're storing like an artifact and as three, there's a little cost for you keeping it in as three. But it's usually really, really minimal. So the big thing is really, how many times are you give it?Is it over a million times and or are you not on free tier? The costs, like I said, it gets batchedtogether and it's actually really pretty cheap just in terms of number of invocations cause at the bigger places where you can normally save costs. Is it over-provisioned for how much memory you give it?Right. I think the smallest unit you can give it as 128 that can go up to like two gigabytes maybe more now. So if you have it set where, Oh, I want it to use this much memory and it really never is going to use that much memory and that's kind of like wasteful or if you know, if it uses that much, that's like something's wrongNate: [00:35:25] cause you pay, you configure beforehand, like we're going to use max 128 megabytes of memory and then it's allocated on invocation or something like that.And then if you set it too high, you were going to pay more than you need to. Is that right?Steph: [00:35:40] Yeah. Well and it's more like, I think I'll have to double check cause it actually just show you how much memory you use each time in Lambda is invoked. So you can sort of measure if it's getting near that or if you think you need more than it might give an error.If it doesn't, it isn't able to complete . But in general, like. I haven't had many cases where the memory has been the limiting factor. I will say that, the timeout can sometimes get you, because if a Lambda's processing forever, like let's say API gateway, a lot of times API gateway has its own sort of timeout, which is, I think it's like 30 seconds to respond.And if your Lambda is set to, you know, you give it five minutes to process  it always five minutes processing. If you, let's say that you program something wrong and there's like a loop somewhere and it's going on forever, it'll waste five minutes. Computing API gateway will give up after 30 seconds, but you'll still be charged for the five minutes that Lambda was kind of doing its thing.SoNate: [00:36:29] it's like, I know that AWS is services and Lambda are created by like world-class engineers. It's the highest performing infrastructure probably in the world, but as a user, sometimes it feels like there's giant Rube Goldberg machine, and I have like no idea. All of the different aspects that are involved in, like how do you manage that complexity?Like when you're trying to learn AWS, like let's say someone who's listening to this, they want to try to understand this. How do you. Go about making sense of all of that. Like difficulty.Steph: [00:37:02] You really have to go through a lot of the docs, like videos, people showing you how they did something isn't always the best just because they kind of skirt around all the things that went wrong in the process, right? So it's really important just to understand, just to look at the documentation for what all these features are before you use them. The marketing people make it sound like it's super easy and go, and to a degree, it really is like, it's easier than the alternative, right?It's where you put your complexities the problem Nate: [00:37:29] yeah, and I think that part of the problem that I have with their docs is like they are trying to give you every possible path because they're an infrastructure provider, and so they support like these very complex use cases. And so it's, it's like the world's most detailed choose your own adventure.It's like, Oh, have you decide that you need to take this path? Go to   or this one path B. Path C there's like so many different like paths you can kind of go down. It's just a lot when you're first learning.Steph: [00:37:58] It is, and sometimes like the blog posts have better kind of actual tutorial kind of things for like real use cases.So if you have a use case that is general enough, a lot of times you can just Google for it and there'll be something that one of their solution architects wrote up about had actually do it from like a, you know, user-friendly perspective that anything with the options is that you need to be aware of them too, just because the way that they interact can be really important.If you do ever do something that's not done before and the reason why it's so powerful and what, you know why it takes all these super smart people to set up and all this stuff is actually because are just so many variables that go into it that you can do so much with that. It's so easy to shoot yourself in the foot.It always has been in a way, right? But it's just learning how to not shoot yourself in the foot and use it like with the right agility. And once you get that down, it's really great.Amelia: [00:38:46] So there's over a hundred AWS services. How do you personally find new services that you want to try out or how does anyone discover any of these different services.Steph: [00:38:57] What I do is, you know, I get the emails from AWS whenever they release new ones, and I try to, you know, keep up to date with that. Sometimes I'll read blog posts that I see people writing about how they're using some of them, but honestly, a lot of it's just based off of when I'm doing something, I just keep an eye out.If there's something like, I wished that it did sometimes, like, I used some AWS systems manager a lot, which is basically. You can think of it. It's sort of like a config management an orchestration tool. It lets you, basically, it's a little agent. You can sell on  servers and you can, you know, just automate patching and all this other like little stuff that you would do with like Chef or Puppet or other config management tools.And. It seems like they keep announcing services. What are really just like tie ins to existing ones, right? Which is like, Oh, this one adds, you know, for instance, like the secret management and the parameter store would secrets. A lot of them are really just integrations to other AWS services, so it's not as much.The really core ones that everyone needs to know is, you know, EC2 of course Lambda, so big API gateway and CloudFormation because it's basically. The infrastructure as code format that is super useful just for structuring everything. And I guess S3 is the other one. Yeah. Let's talk aboutNate: [00:40:15] cloud formation for a second.So earlier you said your Lambda function is typically going to have a template.yaml. Is that template.yaml CloudFormation code.Steph: [00:40:26] So at its core, yes. But the way you write it is different. So how it works is that the Sam templating language is defined to simplify. What you would with CloudFormation.So a CloudFormation you have to put a gazillion variables in.And it's like, there's some ways to like make that easier. Like I really like using a Python library called Tropo sphere, where you can actually use Python to generate your own cloud formation templates for you. And it's really nice just cause, you know, I like to know I'll need a loop for something or I'll need to like fetch a value from somewhere else.And it's great to have that kind of flexibility with it . The, the Sam template is specifically a transform, is what they call it, of cloud formation, which means that it executes against the CloudFormation service. So the CloudFormation service receives that kind of turns it into the core that it understands and executes on it.So at the core of it, it is executing on top of CloudFormation. You could create a mostly equivalent kind of CloudFormation template usually, but there's more to it. But there's a lot of just reasons why you would want to use Sam for serverless specifically, just because they add so many niceties and stuff around, you know, permissions management that you don't have to like think of as much and shortcuts and it's just a lot easier to deal with, which is a nice change.But the power of CloudFormation is that if you wanted to do something. That like maybe SAM didn't support the is outside the normal scope. You could just stick a CloudFormation resource definition in it and it would work the same way cause it's running against it. It's one of those services where people, sometimes it gets a bad rap because it's so complicated, but it's also super stable.It behaves in a super predictable way and it's just, I think learning how to use that when I worked at AWS was really valuable.Nate: [00:42:08] What tools do you use to manage the security when you're configuring these things? So earlier you mentioned IAM, which is a, I don't know what it stands for.Steph: [00:42:19] Identity and access management,Nate: [00:42:20] right?Which is like configuration language or configuration that we can configure, which accounts have access to certain resources. let me give you an example. One question I have is how do you make sure each system has the minimum level of permissions and what tools you use? So for example, I wrote this Lambda function a couple of weeks ago.Yeah. I was just following some tutorial and they said like, yeah, make sure that you create this IAM role as like one of the resources for launching this Lambda function, which I think they're like, that's great. But then like. How do I pin down the permissions when I'm granting that function itself permissions to grant new IAM roles. So it was like I basically just had to give it route permission according to my low, my skill level, because otherwise I wasn't able to. Create, I am roles without the authority to create new roles, which just seems like root permissions.Steph: [00:43:13] Yes. So there are some ways that's super risky, honestly, like super risky.Nate: [00:43:17] Yeah. I'm going to need your help,Steph: [00:43:19] but it is a thing that there are case you can, you can limit it down with the right kind of definition. SoIAM. It's really powerful. Right? So the original case behind a MRI was that, so you're a servers so that if you had a, an application server and a database server separately.You could give them separate IAM roles so that they could have different things they could do. Like you never really want your database server to maybe. Interface directly with, you know, an S three resource, but maybe you want your application server to do that or something. So it was nice because it really let you limit down the scope from a servers and you don't, cause you have to leave keys around if you do it .So you don't have to keep keys anywhere on the server if you're using IAM roles to access that stuff. So anytime you're storing like an AWS secret key on a server, or like in a Lambda, you kinda did something wrong. The thing they are just because that's, AWS doesn't really care about those keys. It just looks, is it a key?Do it here. But when you actually use IAM policies, you could say it has to be from this role. It has to be executed from, you know, this service. So it can make sure that it's Lambda or the one doing this, or is it somebody trying to assume Lambda credentials? Right? There's so much you can do to kind of limit it.With I am. So it was really good to like learn about that. And like all of the AWS certifications do focus on IAM specifically. So if anyone thinking about taking like an AWS certification course, a lot of them will introduce you to that and help a lot with understanding like how to use those correctly.But for what you talked about with you, like how do you deal with a function that passes, that creates a role for another function, right? What you would do in that kind of case is there's an idea of IAM paths. So basically you can give them like as namespacing for IAM permissions, right? So you can make a, I am role that can grant functions that can create roles .Only underneath its own namespace. Within its own path.Nate: [00:45:20] When you say namespaces, I mean did inherit permissions. But the parent permission has?Steph: [00:45:28] Depends. So it doesn't inherit itself. But like, let's say that I was making a build server . And my build server, we had to use a couple of different roles for different pieces of it. For different steps. Cause they used different services or something. So we would give it like the top level one of build. And then in my S3 bucket, I might say aloud upload for anyone whose path had built in it. So that's, that's the idea that you can limit on the other side, what is allowed.And so of course, it's one of the things where you want to by default blacklist as much as possible, and then white list what you can. But in reality it can be very hard to go through some of that stuff. So you just have to try to, wherever you can, just minimize the risk potential and understand what's the worst case that could happen if someone came in and was able to use these credentials for something.Amelia: [00:46:16] What are some of the other common things that people do wrong when they're new to AWS or DevOps?Steph: [00:46:22] One thing I see a lot is people treating the environment variables for Lambdas as if they were. Private, like secrets. So they think that if you put like an API key in through the environment variable that that's kind of like secure, but really like I worked in AWS support, anyone would be able to see that if they were helping you out in your account.So it's not really a secure way to do that. You would need to use a surface like secrets manager, or you'd have some kind of way to, you would encrypt it before you put it in and then the Lambda would decrypt it, right? So there's ways to get around that, but like using environment variables as if there were secure or storing.Secure things within your git repositories that get pushed to AWS is like a really big thing that should be avoided. And we said, what else did you ever own?Nate: [00:47:08] I'm pretty sure that I put an API key in mineSteph: [00:47:11] before. So yeah, no, it's one of the things people do, and it's one of those things that. A lot of people, you know, maybe nothing will go wrong and it's fine, but if you can just reduce the scope, then you don't have to worry about it.And it just makes things easier in the future.Amelia: [00:47:27] What are like the new hot things that are up and coming?Steph: [00:47:30] So I'd say that there's more and more kind of uses for Lambda at edge for like IOT integration, which is pretty cool. So basically Lambda editor. Is basically where you can process your lamb dos computers, basically, like, you know, like, just think of it as like raspberry pi.It's like that kind of type thing, right? So you could take asmall computer and you could put it like, you know, maybe where it doesn't have a completely like, consistent internet connection . So maybe if you're doing like a smart vending machine or something. Think of it like that. Then you could actually execute the Lambda logic directly there and deploy it to there and manage it from AWS whenever it does have like a network connection and then you can basically, it just reduces latency.A lot and let your coat and lets you test your code both like locally and then deploy it out. So it was really cool for like IOT stuff. There's been a lot of like tons of stuff happening in machine learning space on AWS too much for me to even keep on top of. But a lot of the stuff around Alexa voices is super cool, like a poly where you can just, if you play with your Alexa type thing before, it's cool, but you could just write a little Lambda program to actually generate, you know, whatever you want it to say in different accents, different voices on demand, and integrate it with your own thing, which is pretty cool. Like, I mean, I haven't had a super great use case for that yet, but it's fun to play with.Amelia: [00:48:48] I feel like a lot of the internet of things are like that.Steph: [00:48:52] Oh, they totally are. That they really are. But yeah, it's just one of the things you had to keep an eye out for. Sometimes the things that, for me, because I'm dealing so much with like enterprisey kind of stuff that excite me are not really exciting to other people cause it's like, yay, patching has a way to like lock it down to a specific version of this at this time.You know, it's like, it's like, it's not really exciting, but like, yeah.Nate: [00:49:14] And I think that's one of the things that's interesting talking to you is like I write web apps, I think of serverless from like a web app perspective, but it's like, Oh, I'm going to write an API that will let her know, fix my images on the way up or something.But a lot of the uses that you alluded to are like using serverless for managing, other parts of your infrastructure, they're like, you're using, you've got a monitor on some EC2 instance that sends out a cloud watch alert that like then responds in some other way, like within your infrastructure.So that's really interesting.Steph: [00:49:47] Yeah, no, that's, it's just been really valuable for us. And like I said, I mentioned the IAM stuff. That's what makes it all possible really.Amelia: [00:49:52] So this is totally unrelated, but I'm always curious how people got into DevOps, because I do a lot of front end development and I feel like.It's pretty easy to get into front end web development because a lot of people need websites. It's fairly easy to create a small website, so that's a really good gateway, but I've never like on the weekend when it to spin up a server or any of this,Steph: [00:50:19] honestly for me, a lot of it was like my first job in college.Like I was basically part-time tech support / sys admin. And I always loved L nuxi because, and the reason I got into Lennox in the first place is I realized that when I was in high school that I could get around a lot of the schools, like, you know, spy software that won't let you do fun stuff on the internet or with the software if you just use a live boot Linux USB.So part of it was just, I was using it. So, you know. Get around stuff, just curiosity about that kind of stuff . But when I got my first job, that's kind of like assist admin type thing. It kind of became a necessity. Because you know when you have limited resources, it was like me and like another part time person and one full time person and hundreds of people who we had to keep their email and everything.Working for them. It kind of becomes a necessity thing cause you realize that all the stuff that you have to do by hand back then, you can't keep track of it all. You can't keep it all secured for a few people. It's extremely hard. And so one way people dealt with that was, you know, offshoring or hiring people, other people to maintain it.But it was kind of cool at the time to realize that the same stuff I was learning in my CS program about programming. There's no reason I couldn't use that for my job, which was support and admin stuff. So, I think I got introduced to like chef, that was the first tool that I really, I was like, wow, this changes everything.You know, because you would write little Ruby files to do configuration management and then your servers would, you know, you run the chef agent to end, you know. You know, they'd all be configured exactly the same way. And it was testable. And there's all this really cool stuff you could do with chef that I, you know, I had been trying to play to do with like, you know, bash script or just normal Python scripts.But then chef kind of gave me that framework for it. And I got a job at AWS where one of the main components was supporting their AWS ops work stool, which was basically managed chef deployments. And so that was cool because then I learned about how does that work at super high scale. What are other things that people use?And right before I actually, you know, got my first job as a full time dev ops person was when they, they were releasing the beta for Lambda. So I was in the little private beta for AWS employees and we were all kind of just like, wow, this changes a lot. They'll make our jobs a lot easier, you know, in a way it will reduce the need for some of it.But we were so overloaded all the time. And I feel like a lot of people from a  perspective know what it feels like to be like. There's so much going on and you can't keep track of it all and you're overloaded all the time and you just want it to be clean and not have to touch it and to do less work at dev ops was kind of like the way forward.So that's really how I got into it.Amelia: [00:52:54] That's awesome. Another thing I keep hearing is that a lot of dev ops tests are slowly being automated. So how does the future of DevOps look if a lot of the things that we're doing by hand now will be automated in the future?Steph: [00:53:09] Well, see, the thing about dev ops is really, it's more of like a goal.It's an ideal. A lot of people, if they're dev ops purists and they'll tell you that it means it's having a culture where. There are not silos between developers and operations, and everyone knows how to deploy and everyone knows how to do everything. But really in reality, not everyone's a generalist.And being a generalist in some ways is kind of its own specialty, which is kind of how I feel about the DevOps role that you see. So I think we'll see that the dev ops role, people might go by different names for the same idea, which is. Basically reliability engineering, like Google has a whole book about site reliability engineering is the same kind of philosophy, right? It's you want to keep things running. You want to know where things are. You want to make things efficient from an infrastructure level. But the way that you do it is you use a lot of the same tools that developers use. So I think that we'll see tiles shift to like serverless architect is a big one that's coming up because that reliability engineering is big.And we may not see people say dev ops is their role as much, but I don't think the need for people who kind of specialize in like infrastructure and deployment and that kind of thing is going to go away. You might have to do more with less, right? Or there might be certain companies that just hire. A bunch of them, like Google and Amazon, right?They're pro still going to be a lot of people, but maybe they're not going to be working at your local place because if they're going to be working for the big people who actually develop the tools that are used for that resource. So I still think it's a great field and it might be getting a little harder to figure out where to enter in this because there's so much competition and attention around the tools and resources that people use, but it's still a really great field overall. And if you just learn, you know, serverless or Kubernetes or something that's big right now, you can start to branch out and it's still a really good place to kind of make a career.Nate: [00:54:59] Yeah. Kubernetes. Oh man, that's a whole nother podcast. We'll have to come back for that.Steph: [00:55:02] Oh, it is. It is.Nate: [00:55:04] So, Steph, tell us more about where we can learn more about you.Steph: [00:55:07] Yeah. So I have a book coming out.Nate: [00:55:10] Yes. Let's talk about the book.Steph: [00:55:12] Yeah. So I'm releasing a book called, Fullstack Serverless. See, I'm terrible.I should know exactly what the title, I don'tNate: [00:55:18] know exactly the title. . Yeah. Full stack. Python with serverless or full-stack serverless with Python,Steph: [00:55:27] full stack Python on Lambda.Nate: [00:55:29] Oh yeah. Lambda. Not serverless.Steph: [00:55:31] Yeah, that's correct. Python on Lambda. Right. And that book really has, it could take you from start to finish, to really understand.I think if you read this kind of book, if I, if I had read this before, like learning it, it wouldn't feel so maybe. Some people confusing or kind of like it's a black box that you don't know what's happening. Cause really at its core lambda that you can understand exactly everything that happens. It has a reason, you know it's running on infrastructure that's not too different from people who run infrastructure on Docker or something.Right. And the code that you write. Can be the same code that you might run on a server or on some other cloud provider. So the real things that I think that the book has that maybe kind of hard to find elsewhere is there's a lot of information about how do you do proper testing and deployment?How do you. Manage your secrets, so you aren't storing those in them in those environment variables. Correct. It has stuff about logging and monitoring, all the different ways that you can trigger Lambda. So API gateway, you know, that's a big one. But then I mentioned S3 and all those other ones. there's going to be examples of pretty much every way you can do that in that book.Stuff about optimizing cost and performance and stuff about using that. SAM, serverless application, a repository, so you can actually publish Lambdas and share them and even sell them if you want to. So it's really a start to finish everything you need to. If you want to have something that you create from scratch.In production. I don't think there's anything left out that you would need to know. I feel pretty confident about that.Nate: [00:57:04] It's great. I think one of the things I love about it is it's almost like the anti version of the docs, like when we talked about earlier that the docs cover every possible use case.This talks about like very specific, but like production use cases in a very approachable, like linear way. You know, even though you can find some tutorials online, maybe. Like you mentioned, they're not always accurate in terms of how you actually do or should do it, and so, yeah, I think your book so far has been really great in covering these production concerns in a linear way.All right. Well, Steph is great to have you.Steph: [00:57:37] Thank you for having me. It was, it was great talking to you both.

An airhacks.fm conversation with Thomas Wuerthinger (@thomaswue) about: Working on HotSpot, Sun started collaboration with Johannes Kepler University (JKU) in Linz, Java HotSpot is written in C++, "Array Bounds Check Elimination" for Java HotSpot Compiler, increased the performance by approx. 10%, the possibly most impactful student work ever, IdealGraphVisualizer (IGV): the graphical visualisation tool for HotSpot uses NetBeans visual library, IGV is also used for GraalVM, the Maxine Research VM at Sun Microsystems, Project Maxwell was renamed to Maxine, working at Sun's Menlo Park at Maxine, the circular optimization of Java leads to higher performance, the relation between Maxine and GraalVM, replacing the Maxine Compiler with Client HotSpot Compiler "transpiled" from C++ to Java, the C1X compiler, maxine was too ambitious, GraalVM just focusses on the compiler and makes it available for HotSpot, the Java compiler (javac) is written in Java, the quality of the JIT output is the first factor for good performance, HotSpot asks JIT to optimize "hot" methods, Maxine project is stil active, JVMCI, working on crankshaft compiler at Google with a team of 8 people, using Graal as polyglot environment, converting JavaScript to GraalIR was too complex, JavaScript is dynamic and GraalIR is typed, partial evaluation was inspired by PyPy, JavaScript interpreter was written in Java and is optimized by GraalVM, the frozen interpreters, the meta-circularity comes with the native image, a small JavaScript interpreter team implements recent JavaScript features, improving serverside ReactJS rendering performance with GraalVM, R, Ruby and Python are exectly the same integrated as JavaScript, Java is going to be interpreted in the same way as well, method inlining across language boundaries, Truffle is the intepreter API and comes with language-independent tooling, GraalVM is able to output bitcode instead of native code with LLVM, native image was used to compile the Graal compiler itself, the native image contains garbage collector, native image is considered "early adopters" technology, HotSpot mode is still 20% to 50% faster, G1 is going to be available on the native image as well, in future the performance of the AOT could vary +/-10% compared to JIT, polymorphic invocations could become faster on the native image / AOT, profile guided optimizations can be performed also ahead of time, new native images could learn from the past, the stability of AOT and JIT are similar, twitter already uses AOT for years, with Java you have the choice between AOT and JIT, unikernels could be supported by GraalVM in future, the GraalVM is hiring, Thomas Wuerthinger on twitter: @thomaswue

Sponsored by DigitalOcean: pythonbytes.fm/digitalocean Special guest: Kojo Idrissa! Michael #1: donkeycar Have you ever seen a proper RC car race? Donkeycar is minimalist and modular self driving library for Python. It is developed for hobbyists and students with a focus on allowing fast experimentation and easy community contributions. Use Donkey if you want to: Make an RC car drive its self. Compete in self driving races like DIY Robocars Experiment with autopilots, mapping computer vision and neural networks. Log sensor data (images, user inputs, sensor readings). Drive your car via a web or game controller. Leverage community contributed driving data. Use existing CAD models for design upgrades. Brian #2: RIP Pipenv: Tried Too Hard. Do what you need with pip-tools. Nick Timkovich No releases of pipenv in 2019. It “has been held back by several subdependencies and a complicated release process” main benefits of pipenv: pin everything and use hashes for verifying packages The two file concept (Pipfile Pipfile.lock) is pretty cool and useful But we can do that with pip-tools command line tool pip-compile, which is also used by pipenv: pip-compile --generate-hashes --ouptut-file requirements.txt requirements.in What about virtual environment support? python -m venv venv --prompt $(basename $PWD) or equivalent for your shell works fine, and it’s built in. Kojo #3: str.casefold() used for caseless matching “Casefolding is similar to lowercasing but more aggressive because it is intended to remove all case distinctions in a string.” especially helpful for Unicode characters firstString = "der Fluß" secondString = "der Fluss" # ß is equivalent to ss if firstString.casefold() == secondString.casefold(): print('The strings are equal.') else: print('The strings are not equal.') # prints "The strings are equal." Michael #4: Virtualenv via Brian Skinn Virtualenv 20.0.0 beta1 is available Announcement by Bernat Gabor Why the major release I identified three main pain points: Creating a virtual environment is slow (takes around 3 seconds, even in offline mode; while 3 seconds does not seem that long if you need to create tens of virtual environments, it quickly adds up). The API used within PEP-405 is excellent if you want to create virtual environments; however, only that. It does not allow us to describe the target environment flexibly or to do that without actually creating the environment. The duality of virtualenv versus venv. Right, python3.4 has the venv module as defined by PEP-405. In theory, we could switch to that and forget virtualenv. However, it is not that simple. virtualenv offers a few benefits that venv does not Benefits over venv Ability to discover alternate versions (-p 2 creates a python 2 virtual environment, -p 3.8 a python 3.8, -p pypy3 a PyPy 3, and so on). virtualenv packages out of the box the wheel package as part of the seed packages, this significantly improves package installation speed as pip can now use its wheel cache when installing packages. You are guaranteed to work even when distributions decide not to ship venv (Debian derivates notably make venv an extra package, and not part of the core binary). Can be upgraded out of band from the host python (often via just pip/curl - so can pull in bug fixes and improvements without needing to wait until the platform upgrades venv). Easier to extend, e.g., we added Xonsh activation script generation without much pushback, support for PowerShell activation on POSIX platforms. Brian #5: Property-based tests for the Python standard library (and builtins) Zac Hatfield-Dodds and Paul Ganssle, so far. Goal: Find and fix bugs in Python, before they ship to users. “CPython's existing test suite is good, but bugs still slip through occasionally. We think that using property-based testing tools - i.e. Hypothesis - can help with this. They're no magic bullet, but computer-assisted testing techniques routinely try inputs that humans wouldn't think of (or bother trying), and turn up bugs that humans missed.” “Writing tests that describe every valid input often leads to tighter validation and cleaner designs too, even when no counterexamples are found!” “We aim to have a compelling proof-of-concept by PyCon US, and be running as part of the CPython CI suite by the end of the sprints.” Hypothesis and property based testing is superb to throw at algorithmic pure functions, and the test criteria is relatively straightforward for function pairs that have round trip logic, like tokenize/untokenize, encode/decode, compress/decompress, etc. And there’s probably tons of those types of methods in Python. At the very least, I’m interested in this to watch how other people are using hypothesis. Kojo #6: PyCon US Tutorial Schedule & Registration Find the schedule at https://us.pycon.org/2020/schedule/tutorials/ They tend to sell out FAST Videos are up fast afterwards What’s interesting to me? Migration from Python 2 to 3 Welcome to Circuit Python (Kattni Rembor) Intro to Property-Based Testing Minimum Viable Documentation (Heidi Waterhouse) Extras Michael: Foreword for Mastering Python Networking Pyramid (Waitress) and Django both issued security CVEs. You should upgrade! StackOverflow Survey 2020 is open. Go fill it out! Joke See the cartoon: https://trello-attachments.s3.amazonaws.com/58e3f7c543422d7f3ad84f33/5df14f77efb5642d017a593f/31cba5cdf0e9805d47837916555dd7ab/b5cb6570af72883f06c3dcbf47679e9d.jpg

A double dose of Python, AWS credits for open source projects, a new kernel development course from the Linux Foundation, and an exciting release for KDE Plasma.

Mark and Brian Dorsey spend today talking Python with Dustin Ingram. Python is an interpreted, dynamically typed language, which encourages very readable code. Python is popular for web applications, data science, and much more! Python works great on Google Cloud, especially with App Engine, Compute Engine, and Cloud Functions. To learn more about best (and worst) use cases, listen in! Dustin Ingram Dustin Ingram is a Developer Advocate at Google, focused on supporting the Python community on Google Cloud. He’s also a member of the Python Packaging Authority, maintainer of PyPI, and organizer for the PyTexas conference. Cool things of the week Machine learning can boost the value of wind energy blog Compute Engine Guest Attributes site Colopl open sourced a Cloud Spanner driver for Laravel framework site Running Redis on GCP: four deployment scenarios blog Interview GCP Podcast Episode 3: Kubernetes and Google Container Engine podcast Python site Extending Python with C or C++ docs PyPy site PyPI site App Engine site Compute Engine site Cloud Functions site Ubuntu site Flask site Flask documentation docs Docker site Python documentation docs PyCon site PyCaribbean site Question of the week How can I manipulate images with Cloud Functions? Where can you find us next? Mark will be at GDC, Cloud NEXT, and ECGC in April. Dustin will be at Cloud Next and PyCon. Brian will be lecturing at Cloud Next: ‘Where should I run my code?’

Hold on to your tits! Chingona is back for a second season. Nadia, Karen and Lea give you a sneak peek of Season 2. Our insta: www.instagram.com/chingonapodcast/ Our twitter: twitter.com/ChingonaPodcast Music: Pagan Day by Pypy http://freemusicarchive.org/music/PyPy/Live_at_WFMU_for-Spin_Age_Blasters_with_Creamo_Coyl_1232017_1032/Pypy_3_Pagan_Day Chingona Theme song by Raul Garza

See the full show notes for this episode on the website at pythonbytes.fm/47.

RPython is a subset of Python that is used for writing high performance interpreters for dynamic languages. The most well-known product of this tooling is the PyPy interpreter. In this episode we had the pleasure of speaking with Maciej Fijalkowski about what RPython is, what it isn't, what kinds of projects it has been used for, and what makes it so interesting.

See the full show notes for this episode on the website at talkpython.fm/32.

See the full show notes for this episode on the website at talkpython.fm/21.

Новости Engine Yard Local JRuby 1.7.1 DRY в RSpec Refinements могу быть отложены до 2.1, полная функциональность точно отложена, статья Чарльза Наттера об этом Статья на русском об ActiveSupport::Notifications Легкий пул процессов xpool StatBoard — статистика создания объектов Ruby 2.0.0 preview2 Вышел Draper 1.0.0.beta1 Библиотека krypt Тур по исходному коду MRI Обсуждение Новый сайт Наш новый сайт Мащенко Артем и твиттер Хилков Иван Юдин Максим Инструмент для статических сайтов middleman Railsclub'Ульяновск — 15 и 16 декабря в Ульяновске Алексей Палажченко Твиттер Алексея Qik Проект PyPy и еще о нем же Язык Go и еще о нем же История создания и философия языка Go Дизайн и философия языка Celluloid Модель акторов и статья в википедии о последовательных процессах (Алексей назвал их “синхронными”, хотя они последовательные) dl.google.com now served by Go Пакетный менеджер для Go Проблема с GC на 32-битных системах Changelog Go 1.1 Пять этажей в сутки Борец за качество подкаста Алексей назвал процедурные языки декларативными, хотя они императивные. facepalm. (Добавлено по просьбе Алексея)

Bradley and Karen discuss their jobs, particularly fundraising, and plans for future shows. Show Notes: Segment 0 (00:36) The Google Summer of Code Program is large philanthropic program by Google for students to write Free Software in the summer. Bradley gave a talk about non-profit organizations at the Google SoC Mentor Summit 2011 Karen mentioned the GNOME Women's Outreach Program, which coordinates with the SoC, and the Season of KDE. (09:36) Conservancy's Amarok, Mercurial and PyPy projects are all currently doing fundraising programs (14:38) Bradley will give two talks at LinuxCon Europe this week. (15:15) Karen will attend the Ubuntu Developer Summit. (20:20) Karen will speak in Latvia later this year. (24:20) Richard Fontana discussed RMS' quote about Jobs on identi.ca (26:27) Segment 1 (29:28) We'll try to record some talks/interviews at upcoming events. Send feedback and comments on the cast to . You can keep in touch with Free as in Freedom on our IRC channel, #faif on irc.freenode.net, and by following Conservancy on identi.ca and and Twitter. Free as in Freedom is produced by Dan Lynch of danlynch.org. Theme music written and performed by Mike Tarantino with Charlie Paxson on drums. The content of this audcast, and the accompanying show notes and music are licensed under the Creative Commons Attribution-Share-Alike 4.0 license (CC BY-SA 4.0).

Bradley and Karen discuss their jobs, particularly fundraising, and plans for future shows. Show Notes: Segment 0 (00:36) The Google Summer of Code Program is large philanthropic program by Google for students to write Free Software in the summer. Bradley gave a talk about non-profit organizations at the Google SoC Mentor Summit 2011 Karen mentioned the GNOME Women's Outreach Program, which coordinates with the SoC, and the Season of KDE. (09:36) Conservancy's Amarok, Mercurial and PyPy projects are all currently doing fundraising programs (14:38) Bradley will give two talks at LinuxCon Europe this week. (15:15) Karen will attend the Ubuntu Developer Summit. (20:20) Karen will speak in Latvia later this year. (24:20) Richard Fontana discussed RMS' quote about Jobs on identi.ca (26:27) Segment 1 (29:28) We'll try to record some talks/interviews at upcoming events. Send feedback and comments on the cast to . You can keep in touch with Free as in Freedom on our IRC channel, #faif on irc.freenode.net, and by following Conservancy on on Twitter and and FaiF on Twitter. Free as in Freedom is produced by Dan Lynch of danlynch.org. Theme music written and performed by Mike Tarantino with Charlie Paxson on drums. The content of this audcast, and the accompanying show notes and music are licensed under the Creative Commons Attribution-Share-Alike 4.0 license (CC BY-SA 4.0).

Karen and Bradley discuss the GNOME 3.2 release, Karen interviews Jos Poortvliet, Bradley complains about identi.ca web interface and they discuss together UEFI “secure” boot, and the PyPy Python 3 campaign. Show Notes: Segment 0 (00:40) Bradley wrote a blog post about how GNOME 3 is not for him. Segment 1 (07:14) Karen interviewed Jos Poortvliet Segment 2 (21:04) Bradley mentioned Shaun McCance's post to desktop-devel about response bias, which he posted on user survey thread. (25:04) Karen mentioned that GNOME 3.2 has been released with new features, such as better window resizing. (28:57) Bradley pointed out that gnats was one of the earliest Free Software bug tracking systems. (30:37) Segment 3 (31:53) Bradley mentioned that he feels like the unfrozen caveman lawyer when trying to use identi.ca now. (32:54) Bradley mentioned Matthew Garrett's blog post about UEFI so-called “secure” booting. (37:36) PyPy is trying to raise funds to support Python 3 on PyPy. (41:20) Send feedback and comments on the cast to . You can keep in touch with Free as in Freedom on our IRC channel, #faif on irc.freenode.net, and by following Conservancy on identi.ca and and Twitter. Free as in Freedom is produced by Dan Lynch of danlynch.org. Theme music written and performed by Mike Tarantino with Charlie Paxson on drums. The content of this audcast, and the accompanying show notes and music are licensed under the Creative Commons Attribution-Share-Alike 4.0 license (CC BY-SA 4.0).

Karen and Bradley discuss the GNOME 3.2 release, Karen interviews Jos Poortvliet, Bradley complains about identi.ca web interface and they discuss together UEFI “secure” boot, and the PyPy Python 3 campaign. Show Notes: Segment 0 (00:40) Bradley wrote a blog post about how GNOME 3 is not for him. Segment 1 (07:14) Karen interviewed Jos Poortvliet Segment 2 (21:04) Bradley mentioned Shaun McCance's post to desktop-devel about response bias, which he posted on user survey thread. (25:04) Karen mentioned that GNOME 3.2 has been released with new features, such as better window resizing. (28:57) Bradley pointed out that gnats was one of the earliest Free Software bug tracking systems. (30:37) Segment 3 (31:53) Bradley mentioned that he feels like the unfrozen caveman lawyer when trying to use identi.ca now. (32:54) Bradley mentioned Matthew Garrett's blog post about UEFI so-called “secure” booting. (37:36) PyPy is trying to raise funds to support Python 3 on PyPy. (41:20) Send feedback and comments on the cast to . You can keep in touch with Free as in Freedom on our IRC channel, #faif on irc.freenode.net, and by following Conservancy on on Twitter and and FaiF on Twitter. Free as in Freedom is produced by Dan Lynch of danlynch.org. Theme music written and performed by Mike Tarantino with Charlie Paxson on drums. The content of this audcast, and the accompanying show notes and music are licensed under the Creative Commons Attribution-Share-Alike 4.0 license (CC BY-SA 4.0).

Armin Rigo discusses the research he has done to implement Python in Python. The new project, titled PyPy, can increase the speed at which programs run, as well as reduce the total memory that they use. (March 2, 2011)

In dieser Ausgabe von Chaosradio Express geht es in die technischen Details eines speziellen Projektes in der Welt der Programmiersprachen und Compiler: PyPy. Im Gespräch mit Tim Pritlove erörtert Holger Krekel Hintergründe zur Programmierung in Python und die Motivation zum Start des PyPy-Projektes. Zunächst widmet sich die Sendung der Programmiersprache Python selbst und erläutert verschiedene Konzepte und Konventionen der Programmierung. Hier kommen unter anderem zur Sprache: direkte Evaluation, die spezielle Syntax von Python unter Verwendung von Einrückung anstatt von Trennzeichen, der Einsatz von Regressionstest in der Programmierung, Kooperatives Programmierung in einem Projekt mit Sprints und Modulen, Namespaces, die verfügbaren Python-Interpreter und -Laufzeitumgebungen, Einsatzmöglichkeiten und Stärken von Python, populäre Bibliotheken, Projekte und Organisationen, die Python verwenden. Im zweiten Teil konzentriert sich das Gespräch auf PyPy. Hier werden erläutert: wie es zu dem Projekt kam und welche Ziele es verfolgt, wie man einem Programm dadurch analysiert, in dem man ihm zur Laufzeit dabei zuschaut, wie es ausgeführt wird, wie man daraus einen Übersetzter in beliebige Zielplattformen generiert, die automatische Erzeugung von Just-In-Compilern, die Low Level Virtual Machine (LLVM), EU-Förderung für das PyPy-Projekt und mögliche Anwendungen für PyPy in der Zukunft.