Pyrefly: Fast, IDE-friendly typing for Python

00:00 Python typing got fast enough to feel invisible.

00:02 Pyrefly is a new open source type checker and IDE language server from Meta, written in Rust with a focus on instant feedback and real world developer experience.

00:13 Today, we dig into what it is, why it exists, and how it plays with the rest of the Python typing ecosystem.

00:19 We have Abby Mitchell, Danny Yang, and Kyle Into from Pyrefly here to dive into the project.

00:25 This is Talk Python To Me, episode 523, recorded September 9th.

00:29 2025. Welcome to Talk Python To Me, the number one podcast for Python developers and data

00:51 scientists. This is your host, Michael Kennedy. I'm a PSF fellow who's been coding for over 25 years.

00:57 Let's connect on social media.

00:59 You'll find me and Talk Python on Mastodon, Bluesky, and X.

01:02 The social links are all in the show notes.

01:05 You can find over 10 years of past episodes at talkpython.fm.

01:09 And if you want to be part of the show, you can join our recording live streams.

01:13 That's right.

01:14 We live stream the raw, uncut version of each episode on YouTube.

01:18 Just visit talkpython.fm/youtube to see the schedule of upcoming events.

01:23 and be sure to subscribe and press the bell so you'll get notified anytime we're recording.

01:28 This episode is brought to you by Sentry. Don't let those errors go unnoticed. Use Sentry like we do here at Talk Python. Sign up at talkpython.fm/sentry. And it's brought to you by Agency.

01:40 Discover agentic AI with Agency. Their layer lets agents find, connect, and work together, any stack, anywhere. Start building the internet of agents at talkpython.fm/agency, Spelled A-G-N-T-C-Y.

01:54 I'm super excited to tell you that I just released my first solo book.

01:58 It's called Talk Python in Production.

02:01 It's the inside look at how we host all the Talk Python sites, APIs, and more.

02:06 The core idea is that I believe most hosting stories sold to developers and data scientists are way overcomplicated and overpriced.

02:14 You've heard me say that you're not Google and you're not Facebook, so you shouldn't run your infrastructure the way they do.

02:20 But if not that, then what?

02:22 This book is both a blueprint for what I chose at Talk Python and a story arc of 10 years of running our own infrastructure from complete newbie to pretty neat infrastructure as code DevOps style.

02:34 You'll find the book right on talkpython.fm.

02:37 Just click book in the nav bar.

02:39 I've made the first third of the book available for free for everyone to read online.

02:43 After that, you can grab the DRM free EPUB and Kindle editions from that same page.

02:48 I hope this book resonates with you.

02:50 People have asked me to share the details of how I run our sites at Talk Python, and now here it is in detail.

02:57 If you're interested, grab the ebook at talkpython.fm.

03:00 Today, I'm working on the paperback version as well.

03:03 Should be out soon.

03:04 Getting the book is a great way to support the podcast.

03:07 Kyle, Danny, and Abby, welcome to Talk Python To Me.

03:10 Thank you.

03:11 Thank you for having us.

03:12 Hello, hello.

03:14 I don't know what type of podcast this is going to be.

03:16 I imagine, you know, I'm talking about Python types.

03:18 It's going to be amazing.

03:20 So thank you all for being here. And I feel there's a new generation of Python type tools and appreciation, and you all have built a really cool one that we're going to dive into.

03:32 So super excited about that. Before we get into everything, though, let's just get a quick introduction about who you are and things like that. So Kyle, we'll go around the squares here.

03:42 How are you doing? Sure. I'm doing great. I've been working on Meta for three years on static analysis tooling. Originally the Pyre type checker, which I actually have engraved on my cup right here. We did that at the office. And then more recently working on Pyrefly. So I'm really excited

03:57 to be here to talk to you guys about that. Yeah. And is your background in Python or what's the

04:01 background? I guess technically I haven't worked in too much Python. Pyre was written in OCaml.

04:06 I've worked in TypeScript and then Rust for Pyrefly. So I do personal projects in Python.

04:11 Do you feel that TypeScript prepared you well for Python typing or is it like really different? I More than, say, C#, C++, other languages, like TypeScript and Python typing kind of share a philosophy.

04:24 Yeah, I think they're similar.

04:26 It definitely gave me some background.

04:28 I think Python typing is its own beast, and there's so much about it that isn't so similar to TypeScript, so it really is pretty different.

04:36 Okay. Hey, Danny.

04:37 Hey, I've been at Meta for just over five years.

04:40 Currently work on Python type checking, so I support Powerfly mostly from the type checking side of things.

04:46 Before this, I was on WhatsApp working on developer tooling for them.

04:51 And before that, I was working on like server and client infrastructure for Messenger.

04:56 Yeah, very fun.

04:57 All right, Abby, welcome.

04:58 Hi, I'm the newest joiner, I guess, of this trio to Meta.

05:04 I joined earlier this year and I'm a developer advocate.

05:07 I started off doing more JavaScript sort of web development work and then became more of a Python person and moved into developer relations.

05:17 And yeah, now I'm here.

05:18 How do you find developer relations?

05:20 I love it.

05:21 I think I learned very early on that I enjoyed talking about code and being nerdy with people about code as much as I did actually sitting and writing code.

05:32 So this job is kind of like the best of both worlds.

05:36 Yeah, it's awesome.

05:36 I always kind of thought that'd be a super fun role and something I might want to do at some point,

05:41 but I guess in a sense, I kind of- Yeah, exactly.

05:44 I just, I have no allegiances or no particular thing that I'm really, you know.

05:50 Jackable trades.

05:52 Yeah, exactly.

05:53 Just whatever is curious, we'll talk about it.

05:54 Like types.

05:55 So super cool.

05:56 Let's start with, excuse me, let's start with what is Pyrefly?

06:01 Pyrefly is a Python type checker and language server that has very powerful IDE features.

06:07 It's written in Rust.

06:08 You know, you can use it as a command line tool.

06:10 You can use it as a VS Code extension.

06:13 You can use it as a language server connected to your favorite editor.

06:17 And it provides both IDE things like hover, go to definition, things like that, as well as like just very fast type checking that infers a lot of types, even when your code base is not annotated.

06:29 We should also mention that it's in alpha right now.

06:32 So a lot of like changes getting shipped every week, you know, lots of sort of exciting new things happening.

06:42 So, but just, you know, try it out with a pinch of salt.

06:45 Sure.

06:45 No, that's a really good point.

06:47 I was just logging into GitHub for a completely different reason this morning and writing my activity feed.

06:54 The very top item was Pyrefly's latest release with, I think, 18 contributors and 70 changes or something like that.

07:02 Quite a big deal.

07:04 Yeah, it's a huge sort of community effort.

07:07 I know because I do the release notes every week.

07:09 So I'm, you know, looking through everyone that's been pushing stuff.

07:13 And that's we do releases currently every week.

07:16 So every week it's, you know, some of the same faces showing up like quite a lot of the meta team, but also quite a few non meta folks as well, contributing or just opening bug reports or feature requests as well.

07:31 Yeah, so pretty it's a hive of activity at the moment.

07:34 Yeah. So you said you're doing the release notes.

07:37 This project you're working on as a proper open source project rather than what you might call source open, like you can see the source, but we're working on it type of thing.

07:47 Yeah, so I think one of the things that, and I think Kyle and Danny can also speak to this, they've been with the project since its inception, you know, really started from the get go as an open source initiative. This wasn't something that we built internally, and then just through over the fence, you know, we're working in public, and we're trying to bring in the community and work alongside them to make something that is a great tool for everyone, not just for meta obviously you know we it the original motivation for the project was probably because of some you know specific needs we had internally but there's a lot of effort that gets put into making sure that um you know we're prioritizing features that are useful for the

08:32 entire community as well yeah and just that from the audience there tushar says pyrofly is incredible really looking forward to using it as a base tool for many many dev tools so you even though it's alpha you already have some fans which is cool that's awesome yeah and that's part of the open source thing right like kyle or danny you want to talk a bit as well about just why you all decided to open source it or you know build it primarily as an open source thing sure yeah i think

08:59 the more open source contributors we have actually the more help we get in like contributions bug reports um meta has a lot of python code if python as an ecosystem gets better meta's code gets better So we love to see when we work on something and the community can improve because of it.

09:17 Yeah. And I guess another sort of motivation that we had was that Pyre was very like tailored to how Meta's code bases are structured, like Meta's build systems and things like that. And what that meant was that we actually had trouble sort of when we pulled in dependencies from the, you know, wider ecosystem, Pyre had some trouble understanding them.

09:38 So like sort of being able to understand all the code that and not just like the flavor of Python that meta writes is was very important for us.

09:48 And just and we also sort of identified a gap in the current tooling that's available.

09:56 And we thought that we could help sort of bring forward and sort of elevate the state of typing in Python by providing tools that make it easier to, you know, add types to your code and things like that and add type checking.

10:08 So I think, you know, maybe an interesting analogy here.

10:11 I don't know how much you all are even really aware or looked at it, but I think Cinder is another thing that came from you all that got open source.

10:20 But it was it was like so specifically for meta and sort of internally that it had all these cool features, but they had to kind of be backported or crossported.

10:31 I don't know whatever you call it when it goes over to the real Python to sort of add some of these features.

10:36 and some of them are making big impacts, right?

10:38 Like we've got with 3.14, the proper adoption of, I don't know, was it PEP 703 or something where the gill-less, the free-threaded Python stuff.

10:47 And like a lot of the faster C-Python things were either taken from or inspired from Cinder.

10:52 So it was really impactful.

10:53 But I think maybe that's kind of a contrast to Powerfly where that was done, as far as I could tell, like really internally and then like started to be shown off outside.

11:03 Yeah, so with, I guess with CPython, I think like, I don't think Cinder's goal was necessarily to just create an alternative like runtime implementation of Python that everyone uses, but like to upstream the improvements to the, you know, the reference or like the official implementation of Python.

11:23 Whereas I think in the typing space, things are a bit more fragmented.

11:27 Like there isn't really a like official, you know, type checker for Python.

11:32 mypy is the reference implementation, yes, but it also was built not as a language server.

11:40 And I think architecturally, and there's a lot of different choices out there, right?

11:44 PyRite is very popular, PyLance, and things like that.

11:48 So it's less sort of, I think contributing to the typing ecosystem doesn't necessarily have to come in the form of upstreaming changes to mypy.

11:59 Whereas it's a bit different for runtime.

12:00 That's a really good point.

12:01 Kyle, did you want to add something as well?

12:03 You were going to say something, I think.

12:04 Yeah.

12:05 I don't exactly remember.

12:06 I think Danny covered it all.

12:08 All right.

12:08 It's all good.

12:10 It's all good.

12:11 I do think it's different as well, right?

12:13 Like in practice, there's really can only be one CPython.

12:17 I know we have PyPy.

12:18 I know we had IronPython, Iron, we had Jython.

12:22 There's a lot of variations, but in practice of what people use, it's really CPython or Bust.

12:27 You know what I mean?

12:28 And so you kind of got to upstream those things if they're going to really make it back in.

12:33 Whereas I agree with mypy.

12:34 I know I always felt like mypy was the official hype checker, but that its adoption wasn't all that high.

12:39 I mean, it has a lot of users.

12:44 So I think maybe adoption, I would say, is pretty high, but I'd say maybe it's not as widespread.

12:52 There's definitely a lot of people that have strong feelings about mypy and how it doesn't work for them.

13:00 And I think a lot of the design choices that were made in Pyrefly and some of the other type checkers that you're seeing sort of coming on the scene this year were deliberately to solve some of those issues for people out there that wanted to use typed Python and wanted to have a type checker that didn't suffer from some of the same frustrations they had with mypy.

13:24 Sure. Okay. Yeah. Your stuff is still pretty popular already for being in alpha, almost 4,000 GitHub stars.

13:31 And yeah, that's a sign that there's a lot of interest.

13:33 That's just me putting in the mess office.

13:37 Every day, get my coffee, star my project.

13:40 So one of the goals, as you can tell from the H2, a fast Python type checker,

13:47 maybe hints at some of the reasons that you all built it.

13:50 So, and some of its like really important attributes.

13:54 I know people in the Python space often harp on fast, Usually the word Rust is involved, check.

14:02 But it's not always that fast is necessarily that important, right?

14:06 Like sometimes it can take half a second or it can take a tenth of a second and it's effectively fine.

14:11 But with these, especially, it's not even just the type checker.

14:16 And Danny, I think this is how we originally got connected is I said, oh, this is the type checker.

14:21 And I was talking about something else and said, well, that's a LSP, like a language server protocol.

14:27 later language server um and you're like no ours does too i'm like oh okay interesting and there it starts to matter quite a bit right like the speed actually facilitates a different sort of

14:39 interaction right yeah so i would say like if you ask like is pyrefly a type checker or is it a language server i think the answer would be yes it is both of those things and those things do rely on each other. Actually, maybe Kyle, you have some good insights to share here. You've done a lot of the language server specific work. Yeah, we've been thinking about this problem for a while.

15:04 I think when you run something on the command line, if it's running in CI, you might not actually be sitting there waiting for it. It would still be fast. It would be nice to be fast running on continuous integration. But definitely as you're typing, if you can see these type errors appear, but also have IDE language services working for you.

15:21 That's a huge thing for it to be fast.

15:25 I think one example that we've seen is like the Instagram code base is a large Python code base.

15:30 Pyre, our old type checker, was originally written because nothing could scale the Instagram level.

15:36 From moving from Pyrite for our language services to Pyrefly, we've actually seen a 90% increase in speed for go-to definition across our Instagram users, Instagram developers.

15:47 So I think a difference like that from seconds to milliseconds can be really, really huge when it comes to developer productivity.

15:54 Yeah, I don't know about you, but I'll open up a thing and a quick command click on something.

15:59 I'm just jumping around like, oh, here, no, actually over there.

16:02 And I can see that, why is it not?

16:05 Oh, now it's working, right?

16:06 Like that would be really frustrating.

16:08 It's the difference between wondering, is your IDE just frozen versus just not even noticing it at all and it just blending into the background of your development environment.

16:19 And it's actually not easy to make that happen, especially when you have these massive code bases.

16:26 And so building with speed in mind does have a very tangible difference, even though it may not be the first thing that you as an end user are thinking about.

16:36 This portion of Talk Python To Me is brought to you by Sentry.

16:40 Over at Talk Python, Sentry has been incredibly valuable for tracking down errors in our web apps, our mobile apps, and other code that we run.

16:49 I've told you the story how more than once I've learned that a user was encountering a bug through Sentry and then fixed the bug and let them know it was fixed before they contacted me.

16:58 That's pretty incredible.

16:59 Let me walk you through the few simple steps that you need to add error monitoring and distributed tracing to your Python web app.

17:06 Let's imagine we have a Flask app with a React front end, and we want to make sure there are no errors during the checkout process for some e-commerce page.

17:15 I don't know about you, but anytime money and payments are involved, I always get a little nervous writing code.

17:20 We start by simply instrumenting the checkout flow.

17:23 To do that, you enable distributed tracing and error monitoring in both your Flask backend and your React frontend.

17:30 Next, we want to make sure that you have enough context that the front-end and back-end actions can be correlated into a single request.

17:38 So we enrich a Sentry span with data context.

17:41 In your React checkout.jsx, you'd wrap the submit handler in a Sentry start span call.

17:47 Then it's time to see the request live in a dashboard.

17:49 We build a real-time Sentry dashboard.

17:51 You spin up one using span metrics to track key attributes like cart size, checkout duration, and so on, giving you one pain for both performance and error data.

18:02 That's it.

18:02 When an error happens, you open the error on Sentry and you get end-to-end request data and error tracebacks to easily spot what's going on.

18:10 If your app and customers matter to you, you definitely want to set up Sentry like we have here at Talk Python.

18:16 Visit talkpython.fm/sentry and use the code TALKPYTHON, all caps, just one word.

18:22 That's talkpython.fm/sentry, code TALKPYTHON.

18:26 Thank you to Sentry for supporting the show.

18:29 Can you all give any sense, and if you're not allowed to or whatever, it's fine, but give me a sense of how much, how big, when you say a big code base, what do you mean?

18:39 Like I was just fiddling around trying to get a sense of like, well, how big is this versus that versus that?

18:45 And like Django, I think Flask is 30,000 lines of Python.

18:49 Django is 300.

18:51 VS Code is 2 million.

18:52 Linux is 30 million.

18:53 Like, where are we talking on that spectrum?

18:57 What's a large code base?

18:59 Instagram is the biggest, I think, Django deployment in the world.

19:03 And I think the code base size is an order of magnitude bigger than VS Code.

19:08 Wow, okay.

19:09 Yeah.

19:09 Isn't the official number 20 million lines?

19:13 20-something million, yeah.

19:14 There's somewhere between, what did you say, Linux and...

19:18 Yeah, between VS Code and Linux.

19:20 I think you're...

19:21 It sounds like on the par of, like, Firefox.

19:23 or something, which is a mega, mega project.

19:26 Yeah, that's awesome.

19:27 Yeah.

19:27 And to give like a point of reference, the like Pyre took 15 whole minutes to check the Instagram code base.

19:35 Like mypy and Pyreite just couldn't do it and fell over.

19:39 And Pyrefly now takes 15 seconds.

19:41 So it's a huge difference.

19:43 Yeah, wow.

19:44 Yeah, that is a huge difference.

19:45 And I think for language services too, like we talk about the size of the code base, but if it's a very shallow dependency graph with many, many files, that code base might still be fast with existing tools. I think where we start to see slowdowns is when you have this big bundle of dependencies that's very, very, very deep. And that's, I think, where the existing tools didn't work for us. I see. So if you were to create a

20:10 dependency graph, the problem is more like how many edges are there and how much interconnectivity, the more it is computationally, that just gets way worse, right? Okay. Yeah, that makes a lot of So what lessons did you all take from Pyre, the OCaml version coming over?

20:27 Like you wrote, you created this somewhat internal tool and then you redid it, right?

20:31 So what was the story?

20:33 So yeah, Pyre, we started a while ago as at first static analysis for type checking and security.

20:40 And then actually a few years ago, we did try porting it to an LSP.

20:44 Like we said, Instagram is very, very slow with existing tools.

20:47 Pyre did work for Instagram.

20:49 It would take a while to type check, but if you can type check incrementally, Pyre actually did a pretty good job of that.

20:56 So with that, we tried taking our type checker, turning it into a language server for the squiggles in the editor, but also like the command clicks and all of that.

21:06 I think it didn't work for a lot of reasons.

21:09 And I guess maybe the biggest lesson was we kind of have to be thinking about this language server from the beginning when we make this design of a system like this.

21:18 Did Pyre start out as originally just a type checker?

21:20 I wasn't there when it was started, but it was a type checker.

21:23 And there's a query interface that lets you like ask questions basically about the types.

21:29 It's used for a few things, but like static analysis in general is its goal.

21:34 Yeah, I can give a little bit more context on that.

21:38 So I think the core of sort of how Pyre started was a security tool that sort of analyzed data flow through programs and prevents like, for example, unsanitized user input from being directly executed. And I think that type of static analysis tooling, like sort of, you know, is only designed to run in continuous integration. And it sort of the internal representations that used for the code were like simplified, and you know, you lose some things that are not relevant for static analysis. And then turning that into a type checker with Pyre, you know, there were already some issues with sort of Pyre's internal representation losing some of the syntactic components that were required for type checking. So we've spent a lot of time compensating for that.

22:24 And then like turning that into a language server was like another big jump. And it's just, it just felt like we were taking a tool that wasn't designed to be a language server and trying to turn it into a language server and getting sort of mediocre results. So the lesson is like, you know, designing it as a language server from the ground up was very important. You know, a language server can be used as a type checker more easily than a type checker can be used as a language server. And I guess the idea of incremental checking is, you know, I think that's a good idea and it works. And, you know, we were also prioritized incrementality when we designed

22:59 Pyrefly. Okay. And why Rust? I mean, I know it's the way that Python gets sped up these days, but you could have picked anything.

23:08 And it was OCaml before.

23:10 And I feel like going from, you know, functional type language, right, to another one is a really big change as well.

23:16 So how'd that come about?

23:18 Well, I think also like partly like what you said isn't like about it, it's the way now that people do Python and Rust.

23:26 Like that's not actually too far from the truth.

23:29 Like if you're creating an open source project, if you genuinely want contributions from the community, there is some sense in writing it in a language that the community is has the skills for and is excited about like Rust as opposed to something like OCaml um no offense to any OCaml fans out there but our you know our potential community of contributors definitely was larger with with Rust so I can speak to that point a bit but I think there's also some more sort of like specific technical reasons as well that Danny could probably elaborate on.

24:05 Yeah, I think that's absolutely worth considering, though.

24:07 If you want contributors, you want to work in a language that people at least know ideally want to play with, right?

24:14 So that's a really, it's non-trivial.

24:17 I mean, it matters.

24:18 Yeah, getting contributors for OCaml was difficult.

24:21 Although I will say one of the reasons why I joined the Pyre team was so I could get paid to write OCaml.

24:26 So, you know.

24:30 But here you are.

24:31 I enjoy writing Rust as well.

24:33 So I really, yeah, it's been a great journey.

24:37 And I mean, I think when writing a tool for Python, maybe the first most obvious choice would just be to write it in Python directly.

24:46 So tools like, you know, FlakeA, mypy are written in Python and that really helps get new contributors.

24:52 But I think we felt like with our like very aggressive performance goals that writing it directly in Python wouldn't be fast enough.

24:59 So we wanted to pick, you know, a fairly fast language that, you know, compiled to native code, worked on Windows, which was very important because Pyre did not work on Windows.

25:09 And so that left us with only a few options, really.

25:13 And I think in the end, it was when we were doing the prototyping, it was between Rust and Go.

25:19 And I think the team had sort of more experience in Rust and sort of one of the one of the leads for the project sort of had experience with a successful rewrite of our buck build system into Rust and had good results from that.

25:34 So we were more confident in moving forward with writing it in Rust.

25:37 But then the TypeScript team is rewriting their compiler in Go, right?

25:41 So yeah, they are.

25:42 That's actually a really big deal.

25:44 Yeah.

25:44 So yeah, we were also picking between those two languages.

25:48 I do think that Rust is a little more compatible with Python people and tooling and expectation than Go.

25:57 Nothing's wrong with Go necessarily, but it's more focused on concurrency than others.

26:02 And I guess that there's probably some parallelism that's really interesting here, but you can do that in Rust as well.

26:07 But I just see Rust being used as if you've got to go to something native, it's almost always Rust if it's a new project these days.

26:15 Yeah. And I mean, Rust also lets us have very like good control over our memory. So and one of the concerns when checking extremely large code bases is sort of the memory overhead, both like, you know, total and also the peak and sort of having control over sort of how how memory is allocated when to evict certain things was like very was important for us.

26:38 So, yeah. So you talked about having to work on Windows. What's the what's the OS breakdown at meta? Like, do people get to pick whatever they want? Is it all Macs? Can you do Linux on the desktop? What's the story there?

26:51 Well, I'm the most recent joiner out of this team. And I definitely got a choice of device when I joined. But yeah, I'd say, yeah, I don't know. I think it probably really depends on what team you're in. And I think we do when we're creating open source projects, you know, not all of the not not every user in the world is someone who sits in Silicon Valley and is using like the latest version of their Mac device.

27:21 So it's super important to make sure we're, you know, thinking about all the different, you know, at least well within reason.

27:29 Yeah, yeah.

27:30 I mean, you don't need it to run on a Raspberry Pi necessarily.

27:34 But if you look at the latest survey results, like these are always the PSF survey results.

27:39 These are always a year behind because they get collected at the end of that year.

27:43 And then this is the latest one, even though it's 2024.

27:46 If you look at Windows, I mean, what operating system people write Python code on?

27:50 it is i think it's actually windows is the most it's 58 compared to Linux which is 59 but i think that means a lot of people write on windows and deploy to Linux and check both boxes you know what i mean yeah and people write on mac and Linux and they check that box and so i think Linux while it's 59 versus 58 i think it it gets double counted a lot kind of like css is one of the most popular languages well sort of anything no matter what language you're using it gets that box checked

28:21 you know what i mean it will probably also be interesting to look at this data when you kind of cross-section it by regions of the world as well yes probably if you're looking at north america the mac proportion would be significantly higher but than it is there but you know python is such a globally adopted language and there are huge emerging you know tech economies in certain areas of like india southeast asia um south america where you know windows systems that are much more

28:55 dominant as well yeah that's a good point abby yeah i definitely think it's table stakes to support all the operating systems people use especially if we expect people to use our project

29:04 yeah the sort of main area why like pyre not working on windows i think hurt mostly the ar vr developers at meta who had to develop in a windows environment i think because they were writing like

29:18 C# so right right or maybe using direct x or something like that yeah okay no very interesting um the other thing i think is interesting if you look over here is see how many years of professional coding experience do you have? 50% say two years or less. 30% say less than one year. So what do you think about typing for new people coming in versus those who've been around for a long time and like, yeah, I worked on a project without typing and eventually it got out of control.

29:47 How do you see Pyrofly fitting in with new folks versus people who've been around for a long time?

29:51 It's really interesting because Python, I mean, I would argue is so much of the success of Python as a language is because it is very well designed for newcomers to programming in general. So I think there is a reason why you see like a lot of Python developers skew towards maybe more of the sort of early learners. And then I think you certainly get, and again, this is more like anecdotal, you know, my anecdotal take, but you sort of, you get to a point, you know, after you've, you know, sort of you've got the basics of the language, you've got those sort of fundamental skills locked down, and you're starting to actually develop production level code when you realize that like, oh, maybe I can't, maybe I shouldn't be playing as fast and loose with the types. And, you know, maybe it would actually be helpful if I was, you know, thinking a little bit more, you know, proactively about the types that I'm passing around as my project scales more and more. I think the goals of Pyrefly specifically are to support people that really value type safety and bug-free code. So maybe if you are a super new user, maybe adding a type checker isn't really on the cards for you right now. But there is a significant proportion of the Python community that are like in this stage where, you know, that they're not early professionals anymore. And they're trying to build production level code. And now they need tools to support them and, and help them get through, you know, make type safe code. And that's where a tool like type checker, a tool like Pyrefly, I think really provides value.

31:44 I will say that even if you don't want type checking in your code, and you don't want to write any types at all you can still use pyrefly in vs code and it will try to understand as many types as it can and power your go to death in like you know and it will work better than if you were doing it without you know without understanding any of the types so i see so maybe it can tell you

32:06 this thing like i can find references on this thing and show you the three places used or go to its definition i just can't tell you that it returns a list of integers well it does some

32:15 inference is it depends on you as a user, right? Like if you want to use Pyrefly as a language server, you can do that and you definitely should. So if you're maybe an early user who's not interested in types, maybe you just want to use Pyrefly as your IDE extension because it's really fast and helps you navigate your code base. If you then want to make that jump to being a bit more type conscious, you can still use Pyrefly. You just have to decide that now I also want Pyrefly to help me check the type as well.

32:47 And that is a toggle that you can switch as a user.

32:52 This portion of Talk Python To Me is brought to you by Agency.

32:55 Build the future of multi-agent software with Agency, spelled A-G-N-T-C-Y.

33:01 Now an open source Linux foundation project, Agency is building the internet of agents.

33:06 Think of it as a collaboration layer where AI agents can discover, connect, and work across any framework.

33:13 Here's what that means for developers.

33:15 The core pieces engineers need to deploy multi-agent systems now belong to everyone who builds on agency.

33:21 You get robust identity and access management, so every agent is authenticated and trusted before it interacts.

33:27 You get open, standardized tools for agent discovery, clean protocols for agent-to-agent communication, and modular components that let you compose scalable workflows instead of wiring up brittle glue code.

33:40 Agency is not a walled garden.

33:42 You'll be contributing alongside developers from Cisco, Dell Technologies, Google Cloud, Oracle, Red Hat, and more than 75 supporting companies.

33:51 The goal is simple.

33:53 Build the next generation of AI infrastructure together in the open so agents can cooperate across tools, vendors, and runtimes.

34:01 Agencies dropping code, specs, and services with no strings attached.

34:05 Sound awesome?

34:06 Well, visit talkpython.fm/agency to contribute.

34:10 that's talkpython.fm/agntcy the link is in your podcast player show notes and on the episode page thank you as always to agency for supporting talk python to me and i guess two sort of key

34:25 things that i think is or three key things that i think are very important for sort of um sort of early and intermediate stage developers is like one is like things should work pretty well out of the box. Like, I don't think they necessarily, people necessarily want to go fiddle with a bunch of settings to get things working if they're just working on like a small script or something.

34:45 And the second is like good error messages. I think like not just saying like these types don't match, but like explaining why and maybe explaining how to fix it. And that's something that we're, we're working on. And the third is something that we provide in the IDE called like inlay hints, where we put the inferred types in this like grayed out text next to like the variable.

35:07 So even if you like didn't know what the type was or didn't understand the type, how the types work, like you can still see, you can still see the type of the variable next to it without you actually having to write any types.

35:19 And if you want to eventually start adding types to your code base, it's as simple as like you can double click that type and it will just add it to your code.

35:27 And you can also run it.

35:28 I was going to, yeah, I was going to ask if there's any kind of tools take that inference and turn it into concrete code.

35:36 Yeah.

35:36 So in addition to clicking in the UI, we also have a sub command in Pyrofly called Pyrofly infer that just takes all of the inferred types and applies it to your whole code base.

35:47 And does that surface itself in VS Code where you've got that little, like, you can, was it Alt Enter or something?

35:53 And it'll show you like, here's the fixes you can apply or the things you can apply.

35:57 And you can choose like, add the types to my code or something like that.

36:00 I think not.

36:01 I think right now it's just a command line tool, but that's a good idea.

36:04 You know, I'll write this down.

36:06 There you go.

36:07 So, but the thing is, if you're using Firefly only, you don't necessarily need to write all the types.

36:13 I think we like when interface boundaries have these types.

36:17 Like, so for functions, if you can do a return type on those, that's actually what the typing spec mandates.

36:22 So mypy doesn't type check your function unless it has a return type or like types in the arguments.

36:28 But I think for like the quick fix and the IDE, it might be noisy if every time we infer something, we show it to you.

36:36 So I guess these things are still somewhat being figured out.

36:38 Yeah, you don't want it to just swamp your code and kill readability.

36:41 This is maybe an interesting challenge that might be worth clicking into a little bit and that we as the team developing Pyrefly, it's hard to create a language server and a type checker that does everything for everyone.

36:59 And I think individual developers have a lot of, you know, different opinions on like how much they want Pyrefly to like get in the way of what they're doing.

37:11 Like some people care a lot about if anything might even have a chance of being a type error, they want to know about it.

37:17 Other people, you know, that's too much for them.

37:20 And they, you know, they would rather like us not, you know, aggressively tell them that they have these errors.

37:27 Right. Part of the magic of Python typing is you don't have to be exactly 100% complete and perfect.

37:34 Yeah.

37:34 Yeah.

37:35 But some people do want that if they're, you know, shipping very sophisticated production level code, for example.

37:41 So we've a lot of our, I think, development discussions revolve around, you know, what should the default behavior be here?

37:50 Like we can make like what should be like a choice that is for the user?

37:54 What things do we assume that the user wants?

37:58 And so it's definitely challenging.

38:01 So yeah, to try and like figure out like, because there doesn't really seem to be a consensus in the Python community right now.

38:08 No, no, there definitely is not.

38:10 And I'm on team Kyle.

38:12 I think that putting the types in on like the architectural boundary areas is super valuable because you can think about, well, what comes into this area?

38:22 I want it to be completely known and accurate and write, but every single variable in a function doesn't need a type.

38:28 You know, like there's a lot of just let me work in this nice free form readable way, but also let me put up the signs or signposts or whatever.

38:37 People that say if I'm going to create a public package, well, every single public bit of that's going to have types, but maybe not the internals, right?

38:45 And it really, I think just a little bit like that really helps the language servers make your editors better because there's enough information for them to refer almost everything, especially the stuff that you're going to touch because that's on the boundaries.

38:56 Yeah, I definitely think at Meta, we've had experience making sure that your code can become typed. So like Maggie at a bunch of the PyCons on our team will talk about how much success we've had in increasing type coverage. So I definitely think these inference tools and the other tools will provide people will be a really good way for people to add types and make their code base

39:17 very strongly typed. Yeah. To give you overdo it, you start to kill the Xenopython and it starts to look like C# or Java or something like that, where it's like, why are all these symbols

39:28 here? You know, there's a lot of symbols here all of a sudden. Let's not start an existential crisis around like, what is Python on? I know. I don't think I can handle it.

39:40 Absolutely. So right here on the screen, it says get VS Code extension. So if I were to go over there and get the VS Code extension, I know you said it's an alpha, but 15,143 people don't care.

39:53 14 people gave it five stars across the board so what happens if i install this into a vs code based editor you know yes many many many branches of that tree these days but if i install it into a vs code based editor from the marketplace does it replace pylance or pyrite or things like that

40:13 yes so actually now if you install it it's just one click install it will disable pylance and pyrite it will start using Pyrefly for everything.

40:23 And in our case, that works really well because we have very, very large code bases and PyLance and Pyright are a little bit slow on them.

40:31 If that doesn't work for you and if you want Pyrefly to only be used in certain cases, we have settings in the, you can see in the readme, there's two, there's disabled language services and then disabled type errors.

40:44 And you can configure that however you want to.

40:48 But it's ready to try out today.

40:50 If I wanted to install it, it would work.

40:53 Yes, you can even try it in front of us live if you want.

40:56 There we go.

40:57 Let me show you all my errors.

41:00 Do you have intentions of supporting anything other than VS Code, like the JetBrains IDEs or Emacs or whatever?

41:07 I don't know.

41:08 So we do already have a JetBrains extension made by a community member.

41:13 I don't know when the last time it was updated was.

41:15 it is not a meta official one, but someone did make it. We support all editors that support LSP.

41:23 So like Vim, Emacs, we have in our website ways to download Firefly for those. We've even made some decisions in the process of ming Firefly that make it easier for non-VS Code editors to work.

41:34 So one example of this is basically we try keeping as much out of the language client as possible to make it so any editor will work really well.

41:43 Okay.

41:44 I'm just fooling around with the PyCharm version here.

41:46 Yeah, it looks, it's got 1,300 installs as well, which is, you know, pretty comparable.

41:52 That's pretty cool.

41:53 If you're using IntelliJ or PyCharm and the plugin's going to be installed.

41:56 Okay, very nice.

41:57 Haven't tried that yet, but I don't, I think that the language server type checker aspect is more presented to you in VS Code and PyCharm, it's like, hey, PyCharm has really good type checking, but we don't know how that happens.

42:10 You know what I mean? Like, it's kind of like just behind the scenes in their tooling, whereas you're going through and picking the details in the VS Code with all the extensions and piecing it together.

42:19 Yeah, I think a lot of people also are just something that you you're not necessarily thinking about a lot, like you're thinking about writing your code, and you're thinking about, you know, whatever goal you're trying to achieve with the project that you're building. And so I think a lot of people don't even know necessarily what default language server they're using in that IDE and how that affects the development experience, especially in IDEs like PyCharm, where it's very built in and you know, for better or worse, is abstracted away from the user.

42:52 Yeah. So one of the things I think will be interesting, maybe we can explore a little bit is sometimes, you know, you talked about like picking the right defaults. And when you're new, you don't necessarily want to fiddle with the defaults. I think also, as you go through these different type checker options, they make different choices for the default behaviors and what how strict or relaxed they're going to be. And it can be super annoying if you ever want to adopt them.

43:17 I remember somebody sent me a message about a, I can't remember which one.

43:22 One, I have a bunch of different packages that let you do different things for web frameworks.

43:28 Like I have one called FastAPI Chameleon.

43:31 So if you want to use the Chameleon template language, but in FastAPI, instead of using Jinja, you just put a decorator and it does its thing.

43:37 And one is about like partial rendering.

43:40 I think it was the first one that I said.

43:42 Somebody sent me a message and said, Pyrite is giving me a load of errors out of this when I use your library.

43:48 It's a decorator for web calling.

43:51 Nobody's calling that function.

43:52 How is it giving you an error?

43:54 Just the fact of here's a web view in Flask or FastAPI or whatever it was, and you put a decorator on it.

44:01 Pyrite decided, well, here's a function that's never called, but we better validate it.

44:05 And there was some slight variation, and it basically filled the screen to put out the signature differences between the two.

44:12 It was gnarly.

44:13 And I'm like, does it really, do I really need to figure this out to make that error go away for this person?

44:17 And I did end up doing it and it was a hassle.

44:21 But my point is these different tools out there all make these different trade-offs and having it as a language server is really nice because if it's your language server and then maybe your CI testing tool, you see it as you build the code.

44:35 You know, you don't build all the code and then run a different tool and go, whoa, it's full of errors.

44:40 You see the little squigglies as you make your way through, right?

44:43 And as you switch around, you'll see like a whole bunch of errors appear that you thought were not a problem, but one thing says yes, one thing says no.

44:50 So that's a very long-winded way of saying, let's maybe talk just a little bit about like the different type checkers and how you, what is your philosophy in like kind of that zone compared to say mypy, Pyrite, PyLance.

45:03 We could talk about ty just a little bit as well.

45:06 other another new one that i feel um a peer of powerfly yeah so i guess maybe our our philosophy right now is like we we're fairly aggressive i think with trying to infer types but we're not necessarily like super aggressive about you know raising type errors or like you know we're we do want to try and reduce noise and we've tried we've implemented a few features um to help with that. Like if you are coming from mypy or pyright, we have a pyrefly init script that will actually take your pyright config or mypy config and generate an equivalent pyrefly config that has, you know, the equivalent error settings. And if you run it in a vacuum, then it will automatically add suppressions to certain files or like ask you to like opt in or out of type checking certain error codes if they're like very prevalent in your project. But yeah, I guess like, Compared to mypy, I guess we are a language server and not just a type checker.

46:09 And I would say compared to Pyright, we are significantly more aggressive in terms of type inference.

46:15 So a good example for this is an empty container.

46:19 So if you have, for example, if you write X equals empty list, and then say later on, you add an int to it.

46:28 And then after that, you try to add a string to it.

46:31 mypy and Pyrofly, what we'll do is we'll determine that based on the first time you add something to the list, that it's a list of ints. And then when you try to add a string to it, it will error. And what Pyright does is it will assume it's a list of any because it's empty. And then you can add anything to it. And then when you read from it, you lose your type safety because where you're getting out of it isn't any.

46:55 Right. Yeah. And that's like a trade off between, you know, the flexibility of having a list of any versus like the type safety you get by assuming it's a list of ints, you know, so it depends in this case where we're more trying to make sure that you're being as as type safe as you can be, I guess, in that.

47:17 Yeah, it makes a lot of sense. I do feel like there's a lot of stuff geared towards, well, it could be anything, right? It's a dictionary, it could have anything, it's a list, it could have anything or a set or whatever. I might just put three customers, shopping cart object and a couple of integers into a list, like it's totally possible.

47:35 You can do that if you type your list, you know, at the start.

47:41 But I think, you know, there's a lot of talk about like how this is an advantage and it's a thing that you want to keep the flexibility.

47:48 But I don't know if I've ever seen real code written that does real things that is that flexible.

47:54 You know what I mean?

47:55 Like you usually want a list of roughly the same types of things.

47:59 Maybe the integers and floats, but they're not like completely unrelated almost ever.

48:04 So I feel like that's a pretty fair assumption you all are making.

48:07 Yeah, and there's, I guess, a third path to doing this inference that's not like pinning it based on the first time it's used, or just giving up and doing any. There's another way where based on what you add to it, you continually modify the type of the list. So if you add an int to it, and then you add a string, then it becomes a list of int or string. And then you get your error when you try to read from the list and use it as an int. But, you know, then you end up with like kind of spooky, like action at a distance where you're getting your error where you're reading from the

48:37 list, but you don't know where you put the wrong thing into the list. So yeah, where you fix your

48:41 error is not where your squiggle is. So we thought that like, you know, giving the error when you put things into the list makes the error more easy to fix. And I guess if you're like, if you're if

48:52 you have a code base where you're trying to sort of gradually add types to, but you want to make sure that it is type safe, then, you know, doing it the way that Pyrefly does, I think is you you can have a list where you haven't declared the type from the start and you can go back and add it later. But PyFly helps make sure that in the meantime, before you do that, you're not, you know, you're not going to break things because we're catching a potential error before it happens.

49:21 Yeah, I like it. So let's do a little, I don't know, compare and contrast, if you will. I think you've talked a lot about mypy already in terms of like the difference in the language server, But just in terms of the type checking aspect, what are some of the philosophical differences, say, with mypy versus PowerFly? mypy seems quite strict in the way that it works.

49:42 Yeah, I think mypy, I think, does a lot of inference and basically like this empty container stuff. But I think we're actually a little bit more aggressive in terms of inferring some of the types.

49:58 I think, for example, when you construct a class and you aren't able to determine the type of the type parameters based on the arguments you provide to the constructor, we can actually, based on how you use that class later, infer that last type parameter.

50:14 So that's something that I don't think any other type checker does.

50:18 Okay. What about pyrite?

50:20 i think i think the biggest like contrast like i could give is the empty container um okay

50:27 example i don't know if kyle or abby have any no honestly all the type checkers blur together

50:32 a little bit yes i know i think until you change them in the editors and you get new errors you're

50:38 like oh wait this one does that okay and then there's also and like you can also configure each of them with your own you know whatever their defaults are you can normally toggle to whatever

50:47 the other option is. So yeah. Yeah. But like, overall, PyRite is like very good. You know, they they do a lot of things right. So architecturally, we're pretty similar to them,

50:59 actually. Yeah, PyRite, the creator of PyRite actually made a conformance test suite that all type checkers run on. So we run PyRify on that PyRite runs on it, my PyRons on it. And the goal is to make all the type checkers behave in a very, very similar way for the unspecified things.

51:15 In practice, there will still be differences in the inference and other things.

51:20 But ideally, if all type bearers could give the same output with the same input, it would be much easier to migrate between them.

51:27 Yeah, it definitely would.

51:28 Maybe you can send me the links for any...

51:30 Yeah, yeah.

51:31 I'll put it in the show notes.

51:32 Yeah, absolutely.

51:33 Yeah.

51:33 It's like a reset CSS equivalent to try to get a weird assumption browsers make, but for typing.

51:40 Yeah.

51:40 And then...

51:41 Go ahead.

51:42 I was going to add one more thing.

51:43 And what Pyrefly also gives you is an automatic suppression script.

51:47 So let's say you do switch from a different type checker.

51:49 If you don't want to use our adoption script that will try mimicking the old type checkers config, you can just run this script that will automatically put a type ignore in all of the spots for you to then later fix.

52:02 Oh, interesting. Okay.

52:03 Yeah, because we know that like there's probably people out there that have never used a type checker before, but also a lot of people that maybe already use mypy or PyRite.

52:12 And everyone hates, you know, doing migrations if it's too much of a hassle.

52:17 So we really tried to make that experience as pain-free as we could.

52:23 Yeah, I totally, I totally get that.

52:25 All right.

52:26 So another one that is similar, not the same for sure, comes from Astral, right?

52:32 Britain and Ruffed.

52:33 T.Y. had Charlie Marsh on the show a month ago or something like that to talk about, maybe a little bit longer, maybe six weeks.

52:39 him and Carl Meyer on the show to talk about ty and all the stuff it's doing, why it's different.

52:46 Want to maybe compare and contrast that one. I know one of the big differences is that ty is based on Salsa, a static analysis tool from the Rust world, and you guys are not. But what else?

52:59 Yeah. So I think architecturally, that is a major difference. And we sort of chose not to use Salsa because we wanted more control over the memory allocation aspect of things.

53:12 I think Salsa, if you're using a framework to handle the core of your type checking, then you kind of give up some of that control.

53:22 Like what we are able to do things like, for example, we don't keep the whole AST in memory during the whole duration of type checking.

53:29 Like we are able to free the memory for the AST as soon as we're done with it.

53:34 And then that keeps our memory from spiking so much during type checking.

53:38 And that's something that we wouldn't have as much control over with Salsa.

53:43 It's like more of a generator-iterator type of pattern instead of just load it all up and process it.

53:49 Yeah, it's sort of like an eager versus lazy thing.

53:52 But I guess in terms of concrete comparisons, so everything I say has to be taken with a grain of salt because both type checkers are in alpha.

54:01 design decisions can change. I would say like right now, I think we're a bit further along in terms of implementing the typing spec. Like I think in terms of like typing, the number of fully passing typing conformance cases, we're actually like higher than mypy now. But ty has, I think, done a lot of very interesting things related to gradual typing and sort of pioneering the representation of like intersection and negation types, which are not part of the typing specification.

54:31 So I think there's just sort of like each type checker is like sort of ahead in different

54:36 areas right now.

54:37 Yeah, both very interesting indeed.

54:40 So one thing I think might be fun to close this out.

54:43 Well, a couple of things for sure.

54:45 But one thing I think that people don't often, at least a year or two ago, they didn't really think about a benefit of typing.

54:54 This originally manifests itself in like printed words or out of context information about the code, right?

55:00 So if I'm doing a blog post and I've got a function, I write, look, here's a little thing we're doing.

55:07 And it doesn't have any types.

55:08 We don't have necessarily how it's used and you don't have a lot of information.

55:12 The 2025 equivalent of that is maybe AI coding agents, right?

55:18 I want to say, here's what I'm working on.

55:20 Help me.

55:21 Somehow, didn't we?

55:22 We had to.

55:23 We had to.

55:24 And so it's like, here's some Python code.

55:26 Help me do this thing.

55:27 If there is typing on that code, I think the AI agents have a much better chance at getting it right.

55:34 Like, oh, that's an integer.

55:36 That means this.

55:37 And if that information is missing, well, it just has more work to figure out if it ever can possibly figure it out.

55:44 So what do you all think about the benefits of typing?

55:47 not for consistency of people, not for reading printed non-IDE code, but for actually this weird, bizarre and kind of amazing time we live in now with AI.

55:59 Yeah. I mean, I think, I mean, I can just give you like one example of how like it helps me in my sort of daily development life. And I, you know, I will put my hands up and say, I use AI assisted coding tools all the time. It saves me so much time. It's a huge time saver and I'm really enjoying using them. One thing that I will do a lot is some of these AI tools you can have directly in your IDE. You can write the function signature and the doc string and then you can just ask the AI to fill in the rest of the code for me. It is so much, I will get a much better result If I add type annotations to my function signature, and then the whatever AI tool I'm using can use that function signature and know, oh, it needs to take in an int, but it needs to return a string.

56:57 And it's a really small change that I can make and how I'm just writing the first part of that code that gives me like a much better result from what the AI spits out at me.

57:08 So that's like one very tangible example of how typed Python, I think, is valuable in this new world of vibe coding that we're living in.

57:20 Yeah, I don't know, Danny or Kyle, if you have more to add.

57:23 Yeah, I definitely think a lot of models are not good at keeping a ton of context. They can't keep a whole code based in the context. So if a type checker or even an LSP that can find the definition of stuff, find references, if it can just provide a little summary with some more information closer the model like that I think is huge for the model being able to produce a correct result and then on the other side you have like the like is it correct question which I think these tools will become even more important in if we have agents that do things without users necessarily right

58:00 right then you kind of want to say does this code hang together from this piece to this piece to this piece or this job to that job yeah yeah and I guess to piggyback off of that like yeah

58:11 like type checkers are pretty valuable as both tools for coding agents to use and for graders to evaluate the finished work. So like, I guess, having a, you know, a type checker that runs quickly, of course, is very valuable, because these like agentic coding loops already take like a really long time. Like sometimes, you know, you set the AI going, you go get coffee or eat lunch, and then you come back and see, check for it. So anything that can make it work faster is valuable.

58:39 But also, I think grading the LLM generated work is very important.

58:46 One concrete example I can give is that at Meta, we do these things called code mods, which are sort of automated refactors.

58:53 Imagine you have your 20 million line code base, and you need to upgrade an old API to a new API.

59:00 And there's like 20,000 call sites.

59:03 Doing that by hand is not really a good use of engineering time.

59:08 So you normally would write like maybe a complicated AST based transformation, but not everything can be expressed in a simple like AST mapping. And like maybe you want something that's a bit smarter. So then LLMs have unlocked a lot of like fancier types of refactoring. Like maybe a simple example that I can give is I did recently did one where we were just eliminating redundant casts.

59:33 So we're looking at where we're getting redundant cast warnings from the type checker.

59:37 We're getting rid of the cast and then cleaning up the imports.

59:40 And, you know, and sort of and if you're casting like the variable you're casting and the variable you're casting to were both named X, then it would just clean it up entirely.

59:50 Things like that.

59:51 That's like that would be a very it's doable, but fairly complicated to write as AST transformation.

59:56 So sort of having the LLM do that and then having and running a type checker on the results to make sure that the LLM didn't like, you know, remove an import it wasn't supposed to remove.

01:00:07 It didn't like break anything else in the code.

01:00:09 It didn't like introduce a new type checker like suppression when it wasn't supposed to.

01:00:13 Things like that are has been very valuable.

01:00:17 Yeah, that's an awesome example.

01:00:19 I definitely have in rules files for agentic agents.

01:00:23 For me, I have things like make sure that you run the linter on anything that you edit.

01:00:27 And then if there's a problem, you need to go fix that.

01:00:30 Like, don't just leave it there, you know, and type checking and things like that.

01:00:33 And you should add a line, run Pyrefly and make sure that it's, you know, got the right types.

01:00:39 Yeah, I think that might be one of my new lines as well.

01:00:41 That's going to be pretty cool.

01:00:42 Okay, so let's wrap this up.

01:00:45 Let's just maybe give people a sense of where you're going.

01:00:48 I know if I go, like I said, there was a brand new release today, which is awesome.

01:00:52 But this is still status alpha.

01:00:55 Only the brave shall go here.

01:00:58 What's coming soon?

01:01:00 What could people look forward to?

01:01:02 All the things.

01:01:03 So many things.

01:01:06 So I think we mentioned already that we do releases every week.

01:01:11 We have, I think we have milestones as well in our GitHub so people can keep an eye out for things that are coming up.

01:01:20 We, right now, it's a lot of like trying to fix a lot of bugs that are coming up as any alpha product has.

01:01:30 We want to make sure that, you know, the type checking side of stuff is type checking stuff correctly.

01:01:36 And we also really want to, actually, maybe Danny or Kyle, Do you have any things to add to that of like big things that are coming that people should watch out for?

01:01:46 At this stage, the alpha label probably only applies to the type checking side of things.

01:01:52 I think our IDE is pretty solid and ready to use.

01:01:55 Pretty robust, yeah.

01:01:56 I would say something to look forward to, I guess, is the type checker in a good enough state to use in production.

01:02:02 I think right now people could be trying the IDE extension.

01:02:07 And what are you changing it to?

01:02:09 Beta?

01:02:09 So we thought about calling something a beta, and I don't remember what the conclusion was.

01:02:15 I think the more of these intermediate, like not done steps we have, like at what point is it ready for production use?

01:02:21 And I think we want to wait until it's production ready.

01:02:23 We're going to call it V1.

01:02:24 We're going to say the type checker will be good enough for everything.

01:02:28 Like we said earlier right now, IDE is used by every single Instagram employee.

01:02:33 If it works for that.

01:02:34 And it's used at like mega scale with that much code.

01:02:37 It's not just used a little bit, right?

01:02:38 That's a serious test.

01:02:40 Yeah.

01:02:40 I think I updated it for you here on the website.

01:02:43 I fixed it.

01:02:46 I think we can, you could just replace me as the developer advocate.

01:02:52 So what are we looking at in terms of timeframe before it maybe gets a little farther?

01:02:57 Although it sounds like the VS Code side of LSP things maybe is good to go.

01:03:01 Yeah.

01:03:02 IDE side of stuff, like definitely people should feel confident to go and start using straight away.

01:03:08 For the type checking side of things, I think it's going to depend on how fast we can get through the backlog of bugs and also how many new critical bugs come up.

01:03:23 I don't think we have a solid timeline yet for when we want to reach V1.

01:03:28 But maybe this is actually a good time for us to invite anyone who's listening to this right now to definitely go and give Firefly a try.

01:03:39 And because we are still in this alpha phase, it now is a super critical time for us to get feedback from people that are using this.

01:03:50 you know, what are the critical issues that we need to fix? Or what are some of the defaults that, you know, don't do make sense or don't make sense for you? Right now, everything is, you know, sort of up for discussion and debate. And people can open issues in our GitHub, people can come talk to us on Discord. We have office hours every fortnight, bi-weekly for the Americans.

01:04:15 And yeah, we don't want to commit to a solid V1 date yet until we feel, I think, a bit more confident that the type checking capabilities are really, really robust and where they need to be.

01:04:29 And a lot of that, you know, that's why we're open source, right?

01:04:33 Like we really need the community to help us get there.

01:04:37 Yeah, sounds great.

01:04:38 Yeah, I guess, I mean, we, I think on our, on our repository, read me, it says that we are planning to replace Pyre in CI by the end of this year. And I think we are still, you know, on track towards that. But it's not necessary to say that by the end of the year, everything will be perfect. I think there, even on the IDE side, we're missing some like refactoring related features that are not like code navigation related, I think. And, you know, obviously quality of life, things can also we can also work on.

01:05:08 And for type checking, there's like a handful of, you know, larger features that we or like larger sort of areas that we still need to be able to we need to understand a bit better.

01:05:19 So but it's like I feel like the in terms of like major things left to do, like the end is, you know, insight.

01:05:26 Yeah.

01:05:26 Oh, awesome.

01:05:27 Congratulations.

01:05:28 So how about this?

01:05:29 If somebody tries it on their project and they're pretty happy with the way it's working, maybe they could use it in CI.

01:05:35 But if they try it and they don't like it, maybe just wait.

01:05:37 That seemed like a good advice.

01:05:38 Yeah, like I wouldn't like try it today and then, you know, find an issue and then think you'll never want to use Firefly ever in your life.

01:05:47 You know, it is it is still an alpha, as we said.

01:05:50 So, you know, check back in, you know, next week.

01:05:54 Who knows? Your bug could be fixed by then.

01:05:56 So, yeah, give us give us your feedback.

01:06:00 And it's open source. You could find the issue on GitHub and click the watch button.

01:06:05 Exactly. Yeah.

01:06:07 Give it a spin in your VS Code, you know, report bugs.

01:06:10 Join our Discord if you, you know, want to just chat with the dev team or want help setting things up.

01:06:15 Like we have a, we're pretty active on Discord right now.

01:06:18 Yeah, fantastic.

01:06:19 All right.

01:06:20 Well, let's leave it there then.

01:06:22 Kyle, Danny, and Abby, thank you all for being on the show.

01:06:25 It was really great.

01:06:25 Thank you for having us.

01:06:27 Yeah, you bet.

01:06:28 This has been another episode of Talk Python To Me.

01:06:31 Thank you to our sponsors.

01:06:32 Be sure to check out what they're offering.

01:06:34 It really helps support the show.

01:06:36 Take some stress out of your life.

01:06:38 Get notified immediately about errors and performance issues in your web or mobile applications with Sentry.

01:06:44 Just visit talkpython.fm/sentry and get started for free.

01:06:49 And be sure to use the promo code talkpython, all one word.

01:06:52 Agency.

01:06:53 Discover agentic AI with agency.

01:06:56 Their layer lets agents find, connect, and work together, any stack, anywhere.

01:07:00 Start building the Internet of Agents at talkpython.fm/agency spelled A-G-N-T-C-Y.

01:07:07 If you or your team needs to learn Python, we have over 270 hours of beginner and advanced courses on topics ranging from complete beginners to async code, Flask, Django, HTMX, and even LLMs.

01:07:20 Best of all, there's not a subscription in sight.

01:07:23 Browse the catalog at talkpython.fm.

01:07:25 Be sure to subscribe to the show.

01:07:27 Open your favorite podcast player app.

01:07:29 Search for Python.

01:07:30 we should be right at the top.

01:07:31 If you enjoy the Geeky Rap theme song, you can download the full track.

01:07:35 The link is your podcast player's show notes.

01:07:37 This is your host, Michael Kennedy.

01:07:39 Thank you so much for listening.

01:07:40 I really appreciate it.

01:07:41 Now get out there and write some Python code.

01:07:53 Talk Python To Me And we ready to roll Upgrading the code No fear of getting old We tapped into that modern vibe Overcame each storm Talk Python To Me Async is the norm you