#400: Ruff - The Fast, Rust-based Python Linter Transcript

00:00 In our code quality tools, linters test frameworks and others play an important role in keeping our code error free and conforming to the rules our teams have chosen. But when these tools become sluggish and slow down development, we often avoid running them, or even turn them off. On this episode, we have Charlie Marsh here to introduce a Ruff a fast Python linter, written in Rust. To give you a sense of what he means by fast, common Python linters can take 30 to 60 seconds to lint, the CPython code base. Ruff takes 300 milliseconds. I ran it on the 20,000 lines of Python code for our courses web app at Talk Python Training and it was instantaneous. With that kind of speed, it's the kind of tool that can change how you work. I hope you're excited to learn about ruff. This is talk Python to me, Episode 400 recorded January 18 2023.

01:05 Welcome to Talk Python to me, a weekly podcast on Python. This is your host Michael Kennedy, follow me on Mastodon where I'm @mkennedy and follow the podcast using @talkpython, both on mastodon.org. Be careful within preceding accounts on other instances, there are many keep up with the show and listen to over seven years of past episodes at talk python.fm We started streaming most of our episodes live on YouTube, subscribe to our YouTube channel over at talk python.fm/youtube to get notified about upcoming shows and be part of that episode. This episode is brought to you by Cox automotive, join their team and use your technical skills to transform the way the world buys, sells and owns cars. Find an exciting position that's right for you at talk python.fm/cox. And it's also brought to you by user interviews. earn extra income for sharing your software development opinion at user interviews. Head over to talk python.fm/user interviews to participate today. Before we get to the conversation for this episode, I have a very brief sponsored message from the PyCharm team. As you know, I'm a huge fan of PyCharm, the tool and the team and I'm happy to bring it to you. Do you like storytelling, want a job where you can work with the Python community and help people with their professional development. PyCharm is doing big things this year and they have an exciting job opening you should consider Developer Advocate. It's a good job doing good work with a great company. learn more and apply at talk python.fm/pycharm-advocate-job. The link is in the episode show notes. Charlie, welcome to talk Python to me.

02:41 Thanks so much. It's my pleasure to be here.

02:43 Yeah, it's a pleasure to have you. We're going to talk about making Python code fast built some pretty interesting tools here with ruff we'll see about integrating rust into ruff. And there's a lot of cool tools around this sort of code quality side of things, right like Black took off in ways I think even that lukesh didn't maybe imagine it would take off. And this is kind of in that same realm. And of course, it plays well with black along the way as well. So we're going to talk all about those things. It's going to be tons of fun to dig into them. But before we get to it, let's start with your story. How'd you get into programming and Python? And rust? Yeah, so

03:23 I got into programming. I guess the summer before I went to college, when I guess I was supposed to be like doing something fun. I thought when I saw Java, and I was the sort of thing that a lot of people had told me I was like, but I never really had a chance to dig into. I ended up I went to school I majored in computer science, so did a bunch of internships while I was in college. And then when I my sort of junior year internship, in my first year out of school, I worked at a company called Khan Academy, which is like an education technology company. And at the time, it was less true now, but at the time, they were really big python trout. I mean, they had one of the one of the biggest, like App Engine deployments was like Khan Academy and like Snapchat, and like a couple of their couple other maybe Spotify or someone

04:09 wow, I had no idea. Yeah, I'm obviously I'm familiar with Khan Academy sure a lot of people are Yeah, but I didn't realize that one there was such a GCP customer, and that was probably Flask, Django on GCP. Or what was it?

04:25 It was like flask on App Engine. Yeah, we did not use Django. Yeah, but they actually I mean it's a whole other story but they did a big go rewrite after I left which is also super interesting. I mean, it's not Python but it is still very interesting just like migrating asst populate from any language. Any other language is always pretty interesting. But it Khan Academy. Yeah, I you know, I did. I did some Python. I would say that, like, I mostly did web and we can talk a little bit more about this because, like, really, through my career, I've kind of jumped between a lot of different systems. And so like Khan Academy, I did, I think a year of Android and and did a little bit of iOS did a lot of web did a little bit of Python. And then, most recently, I worked at a company called Spring discovery, which is like a computational biotech company. And everything we were doing was based on computer vision. So we'd like, take really high resolution pictures of cells, and then try to model like the way that they change when you add drugs. Wow. Okay, which is, yeah, it's pretty wild. I mean, I came into that background, I joined as like second engineer and build out a lot of our like data and machine learning platform. That was kind of a crash course in building like a massive system and Python, right, we were doing scientific computing. So it made a lot of sense to use Python. So we ended up using Python or, like, almost everything.

05:38 Yeah, Python is a really good choice for the web. But it's like the de facto choice for data science, right? Like, it's

05:45 yes, yeah, exactly. There's

05:46 not a whole lot of other choices. Whereas on the web, there's, you know, five or six other platforms and languages that are also contenders for that space. Right,

05:54 right. So, you know, we built out what I consider to be like a fairly large, Python codebase. It was like a big mono repo. And, you know, I spent around four or five years, you know, building it out, and like really writing a lot of Python every day. That's where like, a lot of my Python experience comes from, and like that experience, specifically also informed a lot of a lot of rough. And you know, I can talk more about for how those experiences intertwine. But that's kind of my Python background,

06:20 it must have been really fun to explore some of this visualizing cells and interacting with microscopes. And that was amazing.

06:28 Yeah. Yeah, the coolest part of the job was just that, if you bucket it, like really crudely, like a third of our team, or sort of like software engineers, or like data scientists, machine learning researchers, and then you know, Third, we're wetlab biologists, PhDs. And so every day, I was like, working directly with scientists and like building software, or scientists, which was just like a super cool thing to be able to do as part of a small team. Yeah, but yeah, read a lot of it.

06:56 That's awesome. I worked at a place that was a bunch of PhD researchers doing eye tracking, like not Apple, but your actual eyes, like what are you looking at? Right, the software to actually control the device and get all the information off of it. And then, like, analyze that and put, you know, generate a report for the scientists and stuff. And it's, there's a, there's a special kind of cool for software that touches like reality. Right?

07:21 Yeah. I mean, it adds a lot of complication. Of course, cool.

07:27 You don't get exact numbers, you want to test it, like, you got to approximate all the things. But still, yeah, that sounds like a super fun job. How did it inform rough? Like, what are some of the experiences that yeah, totally, just so people know, rough is like a super fast. Give us a quick elevator pitch. So they they know what the heck ruff is? We'll dive more into later.

07:46 Sure. Yeah, so ruff is what I call an extremely fast Python linter. If you've used linters, and Python in the past, you've probably used something like placate or Py lint, or maybe like py code style, you know, maybe use other tools to help manage your code style like black or like auto Pip, all this stuff that deals with effectively code style. So Ruff is a linter, it looks at your source code, and it tries to report back and tell you as your flag and tell you about issues with it. And those to be stylistic issues like this variable name is not great. Or they could be you know, like logical issues like your actions variable here. And that isn't defined, right. I think there's a lot that distinguishes rough, but like, the thing that I think caught a lot of people's attention was just how fast it is. So I started hate benchmarks like because no matter how much time you like, put into a benchmark, like it's always wrong, from like a certain perspective. And like, People always complain about them. But I think ruff is comfortably like, somewhere in 10 to 100 times faster. Some people even say like 1000 times faster on their setup. So it can be like really, really dramatically faster. And you can also do a lot of auto fixing, which is kind of a distinctive feature that I don't know that many other tools, there are certainly tools that you code transformation in Python, like Pylint, and flake 8 and such, don't do this. So for lots of errors, that ruff will flag, it can actually fix the code for you and fix the issue for you. Which is okay, a big time saver.

09:11 I don't know if there's one, but just give people an idea. Like one of the errors or warnings, rather, that it'll give you is you have an F string, but you're not leveraging its F string capabilities, right? It'll just say F quote, and then it has this static text, a literal, literal string. So it doesn't need the F, right, theoretically, you could say Autofix. And it just drops the F for you. It's like, Yeah, you don't need that, right. Yeah. And

09:33 you know, we can also like, go the other direction. So like, if you're doing a bunch of like percent string formatting, or you're using like the dot format, style helpers, we're actually we can fix at least one of those. Right now. Strings are really complicated, but like, we can actually rewrite I think the dot format calls into strings, which is cool, so fantastic. You know, another thing we can do is we can kind of keep your code like modern, in a way we've taken a lot of inspiration from other tools, like Py upgrade to has like so much cool stuff and functionality in it if you haven't seen it, and we've, we take some of the rules from py upgrade and basically re implement them in rust and package them into a single interface in a single tool. So you just install one thing, and you get, you know, 370 Something rolls,

10:20 I can assert that it is indeed fast. Well, a little bit later, but I ran it on Talk Python Training courses website, I haven't I think that's got 20,000 lines of Python. And it's, it's instant, it's like you press enter, and then out, the stuff is just printing out. These are the things that found which is pretty awesome. So back to your data science work. Yeah. How are you what you're doing influence your creation of ruff? Like, why not just use some, Flake eight or something like that,

10:51 you know, like I said, I'd like worked in a lot of other ecosystems where, what sort of like stricter languages, right, like Java and whatever else. And some say those ecosystems are better. But I often come at this stuff from a perspective of wanting a lot of, like, static analysis tooling. So we had like, a really heavily typed code base, we use, like, we use mypy, you know, we use black, we use like, flake8, we used eyesore, we used, I don't know, like Doc format, or there's like a lot of different stuff that we use, yeah, you know, really, my job was like, I was the maintainer of this big system. And like, most of like, a lot of people in that team are effectively like, clients of that codebase. So they were kind of like, using the stuff that, you know, I and some others were building as, like a library. And so I had to maintain like, it's really big system. And like, the more static tools you have, you know, in my opinion, it just like, greatly increases the leverage that you can have as a maintainer. So we use a lot of tooling. And I think like a couple things happened. One, you know, I was spending a lot of my time in Python, but I was also doing a lot of web. And so you know, like, one week I'd be doing Python the next I'd be going and doing like React and Typescript and whatever else. And so people complain a lot about web tooling. And like, you know, there are certainly lots of valid complaints about it. But there's been a lot of interesting innovation, I think, in that space. And I was certainly influenced by some of it, just seeing some of the tools that came out, and how fast they were sure. And the fact that a lot of those tools, were not being written in JavaScript, sort of intentionally to make them super performant was pretty interesting to me. So like, I don't know, I don't want like name drop launcher tools. But you know, in the web ecosystem, more tooling is being written in like go, rust, even some other sort of more out there languages like Zig. And to me, that was kind of an interesting thing. It was like, Well, does the Python tooling have to be written in Python? Like, what does? Like why does that have to be the case? And like, what is it by you? And what do you lose? So that was one thing. The other was, we actually started to do a lot of rust, Python, hybrid stuff in our own code base in our code base was fully Python. And over time, we took some of the like, really performance critical pieces, and started to rewrite them in Rust, and expose them to the Python side, using some of these like really great Rustoss Python hybrid tools that, you know, maybe we'll get into later. So like, one example is, we were dealing with image data. So like, a common thing we had to do is just like, download one image files, like really, really fast. And so we, you know, we wrote that in Python, we wrote like a bunch of versions that use all sorts of like, multiprocessing, threading, and like, we tried everything. And then eventually, we like, rewrote it in rust. And so we had a really simple, you know, rust module that would just download files really fast. And we expose that as a Python API. So like, from the Python code, it just looked like Python, but the actual code that was running and the way it was built and executed, all went through rust, right?

13:41 So you have these big data big, say, big computation problems, where you're like, you know, this, this could be better. The same time, you're looking at what's happening on the web, side, you know, web pack, or whatever it is. And it's like, this is this is way better. We can do this in Python, but we aren't. So let's start right, probably your experience there. And you're like, what else can I build with for us now that I know how I was seeing,

14:01 you know, the way that this innovation was happening in the web, I was seeing specifically the rust Python, like opportunity from what we were doing. And then I was, you know, frankly, like feeling a fair amount of frustration, just with the performance of a lot of the existing tools. Like, I don't know, I'm always really careful with how I talk about this stuff. Because I hate being I'm really like, not a hater. And like, I've actually gotten like, so much value out of like, all of those tools, but I was being like, in well, I should it really take like one to two minutes to lint, my code, like couldn't it be much faster, right? Like, it's like a big codebase. And like, as you add more plugins and everything else, you really like changes, like how you feel about the tool, right? Like it's no longer like something I just run and get feedback. It's like, I'll have to run the linter now. And I was sort of craving that. Yeah. And

14:49 if you're doing it on a team, my experience at least has been some people in the team continue to run it because they find more value than stress and others are like, I'm not running stupid thing, but then their problems get pushed on to the people who still care. And so then it creates this kind of like a tension like, Joe's code is always kind of crappy because he won't lint it but then like when I check out his code, my stuff starts reporting. Like, those are the weird dynamics that happen from tools that are like super slow unit tests, or superslow linting are those types of things where certain people stop working with them and others don't? And then then you get these weird questions. So having a fast there's like real value to that. This portion of talk Python to me is brought to you by Cox automotive, with brands like Kelley Blue Book, autotrader, dealer.com, and more. Cox, automotive flips the script on how we buy, sell, own and use our cars. And now the team at Cox Automotive is looking for software engineers, data scientists, Scrum Masters and other tech experts to help create meaningful change in the industry. Do you want to be part of a collaborative workplace that values your time and work life balance? Consider joining Cox automotive visit talkpython.fm/cox today, thank you to Cox automotive for sponsoring the show.

16:13 Left spring in like mid to late August, I started working on uff along with like a couple other projects. And I never built a linter before. So like I didn't really know what I was doing. But it felt maybe this is like a little bit of hubris or not, I guess because like it seems to be working. But like I was kind of like, I'll start with a linter because it feels like a tractable like scope of problem. I was like, type checker. I know that's hard. And like I don't really know much about it a linter I feel like I can learn like some of the concepts I have a good understanding of like, of like how it might work

16:48 to me when I look at I think linting people's code, like abstract syntax trees and stuff. Like, that doesn't sound Yeah, the problem to me, but it's good that you saw it that way. You did it get through it. Yeah, well, the

16:58 first version I released was, like, very limited. It was sort of, I sort of needed to get it out. Because I wasn't sure that people would actually really care that much about like what I was doing. Yeah. Because like, I'm describe to you a lot of like, pain points. They're also sort of like opinion, right? But like, you know, I wasn't like, like a faster linter. Like, like, who cares? I was sort of, I wasn't sure, yeah. So you know, when I released it, I was like, I want to prove it's possible. I want to like have reasonable confidence that the performance won't get worse, or much worse as I expand it. But I only supported like, I don't know, maybe like 20 rolls, which is fine with me, because I was really trying to prove a point more than, you know, get people to adopt it even

17:37 right, well, and a lot of times go into that experience, even if very few people used it, you learn fantastic things, right? Yeah,

17:44 I learned so much. And I read a ton of code. Like I read all I've read like a lot of cipher, like a lot of source code now that I read, like all of like, you know, Py flakes, like, Py Doc style, Py code style, like, you know, because I've spent time like trying to reimplement a lot of those a lot of those rules and like understand how they do things are you just learn a lot from like reading and trying stuff? Yeah, Rust does sort of like a whole nother thing where, you know, I did some rusted spring, but I would say that building ruff was really like my rust learning experience. I think I had to kind of try to build something from scratch to like, really understand the language. Sure. Everything I didn't spring, you can do all the tutorials. Yeah. And I was like, I'm trying to get in and out as quickly as possible. No, no, I just like, you know, I didn't do the initial my rust migration. At spring, I worked with another like super talented engineer who did that. And so every time I went into it, I made a bunch of changes to it. But every time I was going in and out, I was like, I just need to like ship this and like, move on. Like, I'm not going to spend a bunch of time like really understanding everything that's going on here. I just want to get it to work. And so I needed to like sit down and like really, like focus and be presented with like a blank slate I think, to learn and just like fail a lot and like build stuff that didn't compile, right. Figure out how to resolve those problems. Yeah, it's honestly it's the top is the top learning curve.

19:05 I'm sure that it is. I started out in C++. And so I know are harder languages and they're easier languages. So as far as I'm never you're not missing that much. I would say Eddie is out there says ruff is so awesome. I actually changed all the switch statements in my Python 310 code back to if else blocks I could switch to Ruff, which is well, pretty awesome.

19:28 That's super nice and slightly embarrassing, because we don't support Match. We don't support match. So this is what the match. That's the one big language language feature that we don't support. Yeah,

19:38 you could just kind of comment it out. Like it just we're gonna just ignore whatever's in the switch. It must be fine. On to the next part. Yeah, exactly. Right. Yeah, I mean, not for your code. But for linting. Let's start our dive in with this comment from Tyler. He says what are the differences between linters like ruff and flaky? Those vs. Code styles are formatters like black and maybe ruff lives in them. middle of that spectrum, I'm not sure.

20:01 Yeah, there's a certainly like, like, like you said, it's like a spectrum. Right? So I guess there's a couple different ways to think about it. And it with those tools, specifically, like some of the responsibilities have, like, in my mind at least shifted a bit over time. So for example, like dlake 8, it does a lot of it doesn't change your code at all. And it'll just tell you about issues. And those issues could be style issues. Like you have extra whitespace here, or Yeah, I don't know what the other things that you're this line is too long. Yeah. But it could also be like a logical issue, which is something that black wouldn't touch. So it might be like this import is unused. So on the one end, you have like, different collections of rules, and maybe not really changing the code, just kind of telling you about it. Black is different in that black. Just reformat your code. So it does not actually aware of like the logic in the code. Like it doesn't know that and imports on us, it doesn't know that function is never called Yeah, it just takes, you know, that abstract, well, not not exactly the abstract syntax tree, but it basically preserves your code as is just tries to restyle it. And so, you know, it's interesting, because like, if you use black, you probably don't need a lot of style linting. Like, if you're using black to format your code, a lot of the rules in flake 8 aren't that relevant anymore?

21:16 They'll say something like, you should have followed the rules of this, but black automatically follows those rules for you. Right? So they're kind of Yeah, you don't need to correct the line length, because Black will wrap it because that's what Black does. Right? Yeah.

21:28 Or even like, you know, a scale of like, x equals one with like, no spaces between the x and the equals, and that equals unborn, like the linter will yell at you for that. But Black Sticks is that for you. So a lot of people will turn off those roles. You know, this is why I say the responsibilities have shifted a bit over time. Yeah, I think you're right there Ruff. Like it kind of sits in the middle, we do less stylistic linting for this exact reason. Like I use black alot black is like, immensely popular. So I actually like strong like heavily de prioritized like all the stylistic walls that are made redundant by black. The differences we do do a lot of that automatic fixing. So like we'll we can remove unused imports for you. We can even do like a lot of more complicated rewrites, like if you're using, if you're using like a dictionary constructor, like the actual DICT parenthesis, arguments, we can actually rewrite as a literal, if you have the roles enabled, and you want to do that, you know, there's like a bunch of rules around like comprehensions and literals. And we can do those rewrites, too. So you know, it can do like style and reformatting. But it's somewhere in the middle.

22:33 Yeah, the fact that it makes some changes, but it doesn't go completely all in like black. It's kind of I think it looks a little bit in the middle there. Yeah, one of the things that I think might give people a lot of brought a lot of faith or willingness to give it a try. There's a lot of projects out here that are large projects that people would know that have adopted, actively adopted and started using rough I saw a quote from Sebastian Ramirez from FastAPI. Right now in the audience. We have all Ofec says the next release of hatch, which I hope to do this, this weekend will have all the new projects generated with config for Lintian environment that uses rough, which I think is pretty excellent. We we speak to speak to some of that like about these these projects adopting it and how that's helped you.

23:21 Yeah, totally. Yeah, I never expected that like this. Maybe that goes without saying, I think you'd have to be like super arrogant to release something and expect a bunch of these people to use it. Yeah, it's been kind of wild. You know, initially, there were a couple big projects that I would call like, really early adopters. And they helped shape the project a lot. Like Pydantic was very early adopters. Zoo lib was a very early adopter FastAPI was actually like, pretty early adopter, too. And then like pandas, and airflow and stuff, those kinds of are more recent, okay, it's been a very interesting like to reflect on how that's happened. Because on the one hand, it's like, sort of ridiculous that all these projects would migrate over me because I'm on, I don't even really have like a proper versioning system right now. Like I'm on V 00225 or something, I basically release like every day. And I consider like, I don't really make we've made like very few breaking changes. But like, in theory, we could make a change. I don't want to but like, if you ascribe, December, like we can make changes like that. You know, there's not really like docs, like the docs are just like this huge readme. It's kind of wild, right? We don't support like all python 3.10 features, I do not support match events. So on the one hand, it's kind of wild that all these projects would move over. I think there are a couple things that help a lot. So one is that the entire time I've been like very, very focused on compatibility with existing tools. And that comes out a lot of cost. Like if there are things that I like don't agree with, right or whatever else, like I sometimes still support them or implement them. And you know, but the but the upside is like It's very easy for people to migrate,

25:01 right? it might change nothing, potentially, right? It just, it just goes faster,

25:06 slowly. And over time, like, you know, we don't have like a third party plugin system, we've just like implemented everything like in rust. Like as part of Ruff, I viewed that as like, I'm just gonna look at the most popular plugins, and then most important roles, and I'm just going to figure out like, what's a blocker? For whom? And like, what do I need to implement in order to like unblock people and like, make sure they can use it? Is there

25:29 a way for people to let you know which of those are really important to them? Like, for example, if there's some big project out, there's like, we would love to move to rough but there's this one, one plugin we're waiting on? Yeah, I

25:41 mostly hear about it in issues. And there are a couple issues where it's like, kind of a big GitHub issue. It'll be like, implement this plugin. And a lot of people will come and like, give it a thumbs up or whatever. We have pretty good coverage. Now actually, like, I mean, there is a long tail, like there's a big ecosystem of like flaky plugins, you know, sometimes someone will come along and ask for a plug in that I haven't haven't really like seen before. And then it's just a calculus of like, what do I want to prioritize? Or how much work? Is it?

26:12 Exactly? Is this a super easy line? thing to do? Like, oh, the line is too long? That's easy, or is it? You know, rewrite this? Yeah. This generator and this other interesting way?

26:23 That happened with a lot of people want, like, I don't know how to pronounce this library, but like dark lint, like Dr. Glynde, I don't know. Anyway, that would go

26:32 that as well. Yeah, dark, man. Let's go that it's very popular.

26:34 But I've looked at the source pretty complicated. So like, I need to, you know, that's something I can just like, turn around the day. But like, you know, I hear like, what people want. And I mean, some of those migrations, though I didn't even know about them until they'd happened. Yeah, of course, people come they submit issues, I look at their profiles, I see what they're working on, I get a sense for what the projects are. So sometimes I know, and then I'm kind of fixing things, knowing that hopefully, it's unlocking them in different ways. But I think like I said, I think the compatibility piece is like really huge. And I actually think that like black and I sort and like the popularity of those things, has made compatibility for me, like a little bit easier, because I can just, like adhere to what they do. And then hopefully, there's like, no code changes.

27:16 Yeah, they centralized around what, like black is the truth. And then we'll, then we'll, we'll start, we'll debate beyond that. But like, we're just going to accept black because it's no fun to to go, commas of the end of the line, no commas on the trailing thing in the list, you know, like that. Those kinds of debates? Just go on and on. Yeah. And I think Black kind of solves that by just making the decision for you. And not everyone's totally happy with every choice. But it stops the debate. And that actually probably wins the day for most of them. One thing that's interesting here that I'm noticing about these projects in the large open source projects that have adopted ruff, not all of them surely, but many of them like Pydantic, and polars, and so on themselves are adopting rust. Do you see a synergy of those like, Well, where are we writing Pydantic core and Ross like Samuel Colvin is, or the folks behind polars aren't like that's the core of it is about rust. And that's the RS on the end? I think. So there might be a little extra draw there. And I think it's

28:16 just more like, like, your ritual alignment? Because it

28:20 doesn't matter. It's not like, No, it doesn't. But spiritually,

28:25 but there's yeah, there's a little bit of a bug, sorry, bug in the sense of like, like, once people start writing some stuff and Ross and improving their Python, they're kind of like, more open to like, you know, trying out all the things that are written in rust and so on. So it's, I mean, that community is, like, been very interesting to sort of watch and be a part of the like Ruff Python community, it still feels like pretty nascent, but there are tooling is actually like, really great. And, you know, we could talk about that more, but like, yeah, there was definitely like, a bunch of initial setup for actually like distributing Ruff, PyPI and pip install. But now that that's over, it all just works. And I mean, I wouldn't say it's, like, requires no effort, but it's actually pretty amazing. Like how, like the degree of integration and how much you can do now with these tools like PyO3 and, and matcher in and some others.

29:18 That was one of the things that was really nice surprise for me as well. It's how easy it is to install. Right? Like, unless you told me unless it wasn't part of, you know, the elevator pitch, you know, the little one sentence subtitle Yeah, on the project, like you would know, from interacting perspective, which is kind of exactly what you want. I also think that it's really there's some value to having these popular projects adopt ruff because Martin and audience for example, since I found out about rough by looking to see what FastAPI does because presumably, it's a ton of respect for fastApi and Sebastian, his choices. So that's got to sort of create the snowball effect as well. This portion of talk Python to me is brought to you by user interviews. As a developer, how often do you find yourself talking back to products and services that you use? Sometimes it may be frustration over how it's working poorly. And if they just did such and such, it would work better, and it's easy to do. Other times, it might be delight. Wow, they autofill that section for me. How do they even do that? Wonderful. Thanks. While this verbalization might be great to get the thoughts out of your head, did you know that you can earn money for your feedback on real products, user interviews connects researchers with professionals that want to participate in research studies, there is a high demand for developers to share their opinions on products being created for developers. Aside from the extra cash, you'll talk to people building products in your space, you will not only learn about new tools being created, but you'll also shape the future of the products that we all use, it's completely free to sign up and you can apply to your first study in under five minutes. The average study pays over $60 However, many studies specifically interested in developers pay several hundreds of dollars for a one on one interview, are you ready to earn extra income from sharing your expert opinion head over to talk python.fm/userinterviews to participate today? The link is in your podcast player show notes. Thank you to user interviews for supporting the show.

31:24 One thing that's a little bit overlooked about like why that adoption is useful is that it actually like feeds back into the project. And like so many great ways. So, you know, for example, like if dagster adopted Ruff and like they, they have like a really big like Python mono repo with like, I don't know, like 50 or 100 separate like Python modules or packages in there. And they filed like a bunch of issues about around how can we make ruff better for Monorepos. And so now they can run ruff ones. And it runs over all their separate projects that can all have their own configuration. And that's like a really, really powerful thing. And something that like, if I was just sort of sitting around like building ruff, like I don't know, that I would have known to prioritize that or what it should look like. And so like, actually like working with people who want to adopt ruff, and like figuring out what stopped using it provides a ton of value to the project. And just prioritization like a lot of the isort stuff, I pushed on it a lot when I started because ruff import sorting, so you can use it if you want in lieu of isort, and we implement a lot of the same configuration options. Not all the same. eyesore just is like really configurable. So we went, we started to implement them as they get requested. But anyway, I prioritize that stuff, because why people wanted it and they were coming to the issues and being like, hey, it's really helped me adopted blah, blah, blah. So just like getting the feedback and like hearing what's blocking people like that itself is like, so valuable for the project,

32:52 right. And you have a lot of people involved in these larger projects. So they and they have specific, polished needs, right? Like, there's a lot of people who work on pandas are FastAPI, and those are mature code bases. It's not just a PEP project, right?

33:07 Yeah. Yeah. Those

33:07 are very mature. Yeah. Yeah, exactly. That's good. But also, it's a challenge. One other thing I would like to point out, you know, you started off by introducing Ruff saying maybe people will be interested, I don't really know if they will, maybe they will. That'd be cool. You know, 6.5 6.4 1000 stars. That's a non trivial amount of interest. That's a lot of love. Yeah.

33:29 Yeah. And like, I don't know, one thing that I, I guess I'm, I feel weird, like highlighting all the big projects, because one thing that I really appreciate, it's just like, anyone who's willing to try a tool like this. Sure, like moving tools, and trying new tools is like a big decision. I just like really appreciate everyone who says nice things about it or ever. And he's like, willing to give a try. Give it a try. Like no matter what they're working on. Yeah, let's have a platform to say that out loud. So

33:56 people hear. Yeah, absolutely. See the other thing I want to highlight about the repo here, not just the stars. But when I look at a project and I want to sort of assess, I really want to adopt this thing. Do I want to make this part of my dependencies, or things or layers that I got to live with here? And if it goes sideways, I got to change something is, you know, how old is the project? How active is the project and so on. So, look, we started this podcast 40 minutes ago, the last commit was 52 minutes ago. Yeah, that's kind of that's awesome. Maybe you're like, but you're looking here. And it's been it's yesterday. It's last week. I want to point out there's just a lot of activity 78 contributors. It's a very lively project, and not just something that's cool. But you know, there's a lot of interest in energy, and it which I think is a very strong signal that it's something people should be comfortable adopting. Thanks. I

34:52 appreciate you calling that out. I think I guess companies one that's actually something that when I talked before about why were these big projects adopt this thing that like seems really experimental. That's actually something that comes up a lot is and I'm not in the conversation, but obviously I'm sleuthing a little bit. Yeah, on the PRS, right. And they're saying, well, it doesn't support x, but it's like, really actively developed. And I'm, like very competent, that they will support that, you know, at some point. Yeah. And so like, just like having something that is clearly very actively worked on, I think, is quite like appealing and comforting to people. Yeah, I actually, like do feel bad saying this, but like, one of my favorite, not favorite, but it kind of an interaction that happens on the repo is someone will file an issue. And they'll say, this is actually also a bug that exists in the, let's call it the upstream implementation. So the existing Python version of that tool also has,

35:47 like pilot leads or something like that. Yeah, it does this, but we think it's wrong. We didn't agree with it or something, right,

35:54 where there is an issue where, you know, the maintainer is like, oh, yeah, this is broken. Yeah. Okay. It's really not like, the reason I saw that thing is like I you know, every project is different. And like every maintainer, like most, everyone's doing this, like for free, right? Like, I'm not, I'm not here to, like, call out other maintainers. But I think it's a very satisfying interaction for people when they link to an issue it's been open for, for maybe for like years. And then I can actually just, like, fix it in like, like, pretty quickly and ship a release in the same day. And like that, I think that's like, a really, like, powerful thing that resonates with people a lot is just the feeling of like, stuff getting shipped. And like, Yeah, and he's getting, and yeah, I'm like, you know, I'm working on this full time. So like, I'm fortunate to be able to do that. And like, I totally get it that, like, other projects are in different states that by right, I get a lot of, you know, and people are always super appreciative. And so I'll just like funnels into, you know, giving me energy,

36:49 it is called you a commit machine. Literally, every time I update my logic dependencies, I'm guaranteed to see new stuff on ruff on new version ruff.

36:57 I appreciate that, you know, it's I do appreciate that, like, Yeah, I do try to write a lot of code. But you know, it's obviously not, not just me. And like the contributors, the contributors have been awesome. And I think one thing I'm particularly impressed by is just the number of number of people who, like I don't even know if I always believe that when they say this, but like, just the number of people who are like, this is my first time writing rust, like I'm really not good at roster like blah, blah, blah, here's something that they just like, yeah, and they just like, make a great contribution. They're like, Hey, I'm trying to learn Ross. And I obviously love that stuff like that are interested in learning Rust actually think Rust is like a great, great project and like a great place for that. But I mean, there are people who are working on stuff, especially the stuff that I just like, I like big things I can't like, focus all my time on and just like having great contributors who are like, really, you know, like, thoughtful, and like, prolific. Every project is lucky to have people like that. How old is

37:53 the project? When did you start it? In August? Yeah, so not that old.

37:57 My brain is like melting, but it's somewhat it. I think it's like, like, somewhere between four and six months.

38:02 Would you say you're working on this full time? As like your full time job? Yeah. Okay. So how's that work? Is that GitHub sponsors? Or are you employed by someone to completely work out? What's the story? That sounds

38:13 awesome. Still figuring out? You know, I'll probably share more on that soon. Okay, I know, a sponsor is enabled right now still figuring out exactly what, like how I want that all to evolve. Right. I am working on full time. I don't anticipate that changing in any way. Like I I really happy and getting so much I this and are Yeah, I think there are lots of ways to make it work. And if not ruff, I want to be working on like other Python tooling. So you know, I think there's like more stuff to come. Well,

38:38 it certainly is neat tooling. Let's go. Let's go through the GitHub page here a little bit. So we've talked about speed a couple of times, we talked about ways in which that happens. You know, Rust is an important part, but it sounds like it's not the only reason that it's fast. You have a chart with the obvious little asterix caveat benchmarks.

38:58 It's reproducible, you know, like, readme, but yeah, that's fast

39:02 in this situation, but my situation is different. In which case, you know, such and such, right, but for some large code base, we've got ruff in point three seconds, auto flake at six pylintat over 60 seconds, just barely. This is on the CPython code base from scratch, which is it's pretty ridiculous. And I already told you the numbers, I don't have a millisecond number, but it appears to be instant on 20,000 lines of Python code that I wrote, and it found some issues, which I thought would already be discovered. So that's, that's pretty excellent. Nice. It's nearly Python 311 100% compatible, right? You said the one major language features the match statement, but other than that, it's, it's compatible, right? Correct.

39:46 Yeah. Okay. It supports some of the other language features like that are maybe less I profile like the parenthesize with statements and stuff like that, but it doesn't support the pattern structural pattern matching yet

39:59 got it. So Got the auto fix support near parity with flaky rule set, which is cool. You talked about the way that you keep the performance fast but still have Yeah, apparently with like eight is you have native reimplementation of the flake eight plugins. That's right. Yeah.

40:15 So we re implement, we re implement everything in Rust. And a lot of the time, that's like me, or whoever's working on it, like looking actually at the plugin, and like, the logic it uses and trying to mimic that in a high fidelity way. And often will like try to use the same test suite, and really try to make sure that we're compatible except in cases where we think there there is like an actual sort of factual error, why ruff is fast, the plugin stuff, there's a lot of interesting stuff to say about like, plugins, because I think Rust is a big part of why ruff is fast. But there are a couple of other big pieces. So we take a lot of care in the code base to, like, only do unnecessary work, if that makes sense. So you know, we support 300 Something rules, but depending on which exact rules you have enabled will skip a lot of unnecessary work. Okay, that can help a lot. So you know, it's basically tailored to how much you're using it. So like, you're not using it as an import sorter is a bunch of stuff that we get skip, we think about it. But the other like really big one is because everything is sort of implemented in like one system, there's a lot of work that would normally be duplicated between a lot of different tools that can actually just be done one. So the way to think of that is like, if you look at like flake eight, with flake 8 doc strings is maybe one example, which is py doc style. So I know it's like a huge, like a tree of tools, you know, if you added that plug in, so pyflakes is going to parse your source code and turn that into an ASD. And then py doc style actually has basically its own parser, that will go back over the source code and look at all the tokens and extract the doc string. And if you have a bunch of different tools, like some of them will share that abstract syntax tree, but a lot of them end up doing work that other tools are also doing

42:04 right, because they can't count on necessarily that being done or that the plugin system doesn't provide work that's already been done to them. So they got to start over anyway. Right? Yeah.

42:14 Or they might want to do things in like a slightly different, maybe you have like three different plugins, like I guess one example is a lot of plugins, like need some way to tell if a function is like public or private? And it's not like super complicated, but you know, it's not like totally trivial, like you need to account are functions that are in inside of classes, like is it a public method or private method, you consider an item other function, right? So there's like, a lot of rules actually, for like determining what's like public and private. And, you know, you might have one lint rule, that's like, all public methods need to have doc string. And you might have another rule that's like, all public methods, and you'd have type entity. And if you have two separate plugins that are doing that, they both need a way to actually, like extract that information. And, you know, it's not necessarily the case that like, it'll be way faster to do it with one pass. And one, I think it will, it may not be like orders of magnitude. But the only thing is, you have a lot of like consistency. So like, you know, it's defined in one way, you're not going to be at the whims of like, small decisions that the tools have to make for us as like maintainers. And like building rough, you know, there's a lot of stuff you like, don't have to learn multiple times, right? I can leverage that. And like, go and implement other lead roles. And I don't have to like figure out from scratch, how do I determine like, what's public and private? And how do I like extract all the docstrings from a file? Like, we already have all that infrastructure? So it's kind of like I see economies of scale, I guess, to like, implementing new stuff, like it's sort of snowballs a little bit like the tool gets more powerful gets kind of easier to do things. I mean, I think you'd be surprised like how much of building a tool meant, I don't know about you personally. But like, I was surprised by like, how much of building a tool like this is done. It's like settings and like configuration, and like, how do people express their settings? What is the command line interface look like? How do you find all the Python files in the directory? Like, it sounds trivial. But like, yeah, you also want to respect like getting more is do you want users to be able to ignore files, like there's a lot of rules. And so again, it's like CLI look, a new Python tool, you know, that wants to go off and implement something, they might have to implement all that stuff themselves. But for us, it's like, we have all that infrastructure in place. And so if we want to build a new func piece of functionality, it's just sort of defining the rule. And we get all this other stuff for free.

44:27 Yeah, you can definitely build on the layers that are in place because it's it's all together. It's cool. Yeah. All right. Let's let's look through here a little bit. Like I said, there's the testimonials from the different projects like Brian from Beaucaire Sebastian from FastAPI and, and whatnot there. But let's start with installing it. Like I said, you would know that this wasn't just a Python tool you could use pip install ruff is the way to go but when I installed it, I didn't pip install I pip X installed it. Are you a fan of pip X? Yeah, I used to have an X Yeah, to me. It seems like we're For some time, I want to run on different projects. And I just kind of want ruff in my tool set. And so I pick x installed rough. What do you think? Good idea? Is it better to put it say like in a per version at per project?

45:12 Like everything? Right? Probably depends. I mean, I definitely saw some of the PEP back. I think the one thing that I the one issue with Ralph, and I guess I recognize widens can be annoying for some people, for sure. Like, we release a lot. And so they projects don't pin their dependencies, then they can start to see like new errors as we add new roles, which, I guess in some sense is like a breaking change, but I don't really consider it as such. It's like, you know, they are here. It's like, they have the like, let's say they have the like, like a simplified rule set enabled, and we add a new rule, and that gets turned on for them. So anyway, the point is, like, people, I guess I recommend pinning rough if you're using it for a project, which I mean, with pipx you're just gonna stay on one burger, right? So

45:55 you run pip X, upgrade, dash all or whatever, or upgrade that thing. Yeah, exactly. It's doing it's a sense. It's kind of a pin, but it's been globally, and it gets upgraded globally. And that not not per project. Yeah, yeah. For me, that's kind of okay. But if I was on a large team, you know, lots of people who are working on it, you might want to control that more, I can see that

46:14 we have a homebrew distribution, and conda distribution on conda. Forge, and then I did those, and then there's everything else was done by other high other people. So I'm like, which is cool, but mostly being like, less familiar. Yeah, sure. I mean, I don't know, publishing on homebrew and kind of word was like, pretty interesting experience. For me, I play because I've never done that, and didn't actually really know that much about how those worked. So yeah, that was cool. Hopefully, it's useful for people who's definitely some complexity with like, the packaging and release stuff, which I don't know if you want to buy that or not. But you know, because we're building rust, there's like a couple of things that we need to do that are a little different from a standard Python back end,

46:54 maybe just touch on it a bit. Because what do you deliver is a wheel right? But it's got the compiled rust? Yep. bit for me on my arm. 64 macOS build, right? Yeah, that's

47:05 right. Yeah, that's right. So basically, it just means we have to the wheel in some sort of pre compiled version of the package, as opposed to just giving you the source code. Like, if I just gave you the source code, and not the wheel, you'd actually need to have rust installed, because you'd have to actually build the thing and install it, which is, of course, an extremely unreasonable expectation for for the kind of people who are using this for the most part.

47:29 Yeah. But before the wheels really became popular, that was part of the step. Right? It would totally build for you. Yeah, yeah. Wouldn't go for you, which was frustrating. But that was part of the step, right? Yeah,

47:39 yeah, we just build wheels for all the platforms that I know

47:44 is that I'll see ICD, just push it to some branch and magic happens. And then we'll start appearing in places,

47:50 whenever I cut a release on GitHub, like I just use, like GitHub releases, basically, I just use github releases, it kicks off our release route. And then that fall through GitHub action. So it just as a big matrix, right of all the different operating systems, we only have to build. Thankfully, we only have to build one wheel per operating system, we don't have to build one wheel per Python version, which is something that can happen sometimes. And then you have like a massive closure and number of wheels, that's all facilitated with a tool called matcher. In which I'm a big fan of, which is it's sort of like IRL, like setup tools and a bunch of other stuff bundled together, but specifically for shipping mixed rust Python. So I don't actually I don't have to, like do anything to her as far to make that work. Yeah, my Pyproject.yaml has you no matter and at the top, and I have a rust project. And I call it my turn build and it creates a wheel. So it's all like, I don't know, I think it looks super cool.

48:45 That sounds very, it sounds super smooth. And super neat. Yeah. And like I said, as a consumer of it, also very smooth, right? It was so quickly, I didn't have to wait on some build, I need build tools or config that I don't care about or don't use, I pretty sure I do have rust, rust C as a CI option I can use here, but you don't want to depend on that right now. So you run it on the command line, you say ruff and you point at either a file or a directory or some pattern of files, right startup type of thing, which is cool. And that gives you the output. You can also do it with a --watch, and just run it constantly, which is pretty cool, right? It's fast enough that as you save it if there's problems that will just appear in the terminal, right? Or wherever you run it. That's kind

49:33 of a funny example. Because I based or it's a good example is I I'm pretty sure I took that exactly from probably from TSC, which is the TypeScript compiler. Yeah, they have a watch setting. And I like how it works. And so I wanted that for that. So it's just that's a very literal example of me looking at another tool from the gallery space and being right. Oh, that's really nice. And I wish we had other tools. I have it here.

49:57 Yes. Was this terrible and not terribly difficult to implement? Right, you take the pattern, and you put a watch in the OS watch implementation, and you say, Call me back when something changes. And because it's fast, it just reruns, right? But it's still Yeah, that's exactly right. It's very handy, though, that it's there. The other thing that's interesting is, you can do it as a pre commit hook, which is nice. Yeah, that

50:19 works pretty well, for people. I think a lot of people seem to use it. I'm glad that it exists. Yeah, well, a bit of a weird setup, because maybe it's actually not that interesting and talked about, but it's in like a separate repo for sort of like theory, like I can't even really remember.

50:31 Okay, I think now she can figure it, it has a, let's say, comprehensive CLI set of options, I can remove 15 or so command line options, you can pass it, but you can also put put it into the Pyproject.toml. With things just like tool that ruff put your various settings in there, right. So it just sort of integrates along that or you can have a ruff.taml and then put it in there.

50:57 Yeah, so that's something that I took, basically from hatch. So within hatch, you can have a Pyproject.toml or a hotshot.toml, and the hats on tomo kind of like unmasked the configuration. Like if you use a ruff.toml, you don't need to have like tool that ruff at the top and stuff like that. Yeah, I think one thing that I'm quite happy that we have is like the configuration is very, like typesafe. So if you try to, like, you know, so that line select equals E F, those are like error, like rule codes that are defined in ruff. And so if you put, if you replaced F with some string that wasn't, you know, a real rule, you'll get an error immediately saying that your pyproduct toml hadn't valid was valid, and like these ways, blah, blah, blah, interesting, okay. And similarly, we create what are called, like JSON schemas, or the configuration. If you're in PyCharm, and you open up like a byproduct.terminal, and you type tool that Rob, it'll actually like, show you all the options, it'll actually surface, the documentation we have for the options to have nice. So it's pretty cool. Yeah, I'd like more tools to do that. Because I think it's like, super useful. I think poetry has it, but not too many others do get it in VS Code, as well. But you need to install a an extension. It's called like, even better toml, I think, right. Okay. But I'm happy with those things. I think it makes it like, I think small things like that add up and glad we're able to do Yeah, when

52:21 I looked at the configuration settings, like the Exclude directories and various other things like that, it's kind of a lot to put on a command line. It would be nice if you could just put it in, say ruff,toml or pyproject.toml and then we just type rough. The thing is, it sees that and it uses it right?

52:35 Yeah, I've kind of like intentionally like not put a lot of these arguments on the command line. Like for that reason, like you can imagine taking everything here and exposing it on the command line. But the command line really just deals with like, how should we think execute? And not like, I don't know, what should the Max complexity be? Yeah, complexity, Jack. And so I

52:54 think that's fair, like put the common stuff in the command line and then say, and if you need to go crazy, here's your --config. Pass that in, right and put it in there. Right? Yeah, one thing that I did want to talk about and you kind of touched on, there's much of the command line arguments, one of the things I didn't want to talk about is the editor integration. There's a huge bunch of rules here. All you got to scroll through the homepage to get get is awesome that or no, no, it's good. I mean, these are like, all the things that checks I don't have to think about anymore, which is great. Eventually, though, she's I forgot it was as long as Eventually though, it has plugins, or maybe that's not quite what I said it has a an extension for VS Code. And it has ways to basically add it as a command to PyCharm right, which is, yeah, those are both awesome editors that are kind of very friendly to thinking about code formatting and exposing the errors that this would as well. So that's great. You might want to just talk about that just real quick.

53:52 Yeah, totally. So yeah, we the VS Code extension, that was my first time reading VS Code. And actually the these extensions use, or they conform to something called the language server protocol. And effectively, that's sort of like a standard, I believe, I'll probably like go into the history wrong, but I believe it's Microsoft that like, publishes and maintains that back. The nice thing about that protocol is you can actually use like, the lot like most, almost all of the code behind the VS Code extension is actually published as a language server, rough LSP. And what that means is you can actually get, like the exact same behaviors and all sorts of different editors, if not confined to VS Code. So if you use like Neo Vim, or like Sublime Text, or whatever else, right, well, it's all worth this standard protocol. And they all have ways to tap into that ruff language server protocol. So we have sort of like the standalone LSP, which we have instructions for, like Sublime and and, you know, other tools. And then we have the actual extension, which is published on the marketplace and was things I definitely want to like, keep supporting and I view them has like official arms, right of the project, which I think is nice. So people should know that like, you know, those are official and like, I fixed bugs in them and all that kind of stuff.

55:09 Nice. And then for PyCharm, you just add it as an external tool, and then you have the ruff command around or for both of these, if you prefer, you just add it as a pre commit hook. Yeah, it's also Yeah, yeah, that then like, as you interact with it, it'll run the pre commit hook as well, if you try to check things in. Super cool here. I think this is a neat project. I ran it into my project. And I thought, you know, everything is pretty much good to go. Where, you know, when I'm using PyCharm, for example, it'll often tell me when any of these things like it'll say there's a local variable that's unused, or it'll automatically remove unused imports. And yet, I'm looking at 331 issues. 108 are potentially fixable with a --fix option. So it sounds like there's still a lot of value to like, make that part of my tool chain.

56:00 Yeah. You know, and feel free to have some of your own opinions. Well, which of those rules actually matter?

56:05 Sure. And I suspect you can disable them in your config file, right? You can say this rule I don't care about

56:10 Yeah, and this is another sort of compatibility thing like we API for actually, like turning rolls on and off is like, essentially identical to the floodgate API. So that's also useful for people migrating over

56:21 to the no QA. Is it the like column? Yeah, like comment? No, QA is one option. Yeah,

56:26 we were. Yep. We respect those two. We also respect like, I saw its action comments. So yeah, we we like do a lot of stuff to try and maintain compatibility. Nice. Maybe another, like interesting thing in that vein is that we ship a tool called Les gay to Ross, which does sort of what it sounds like. So you point it to a flake 8 file, and it spits out a toggle for rough that's compatible. And it also tells you if there were things in the file that we don't support, which is useful to like, Oh, hey, you're using these roles, those actually aren't implemented yet. Yeah, that's also maintained as like part of the project. So I recommend checking it out.

57:02 Excellent. Let's try that. I think we're getting short on time, but not short. On topic. There's a whole lot more to dive into. I think it's, it's really cool project. I think it's gonna be a

57:12 big wasm section. Okay, I'm kidding. We don't have time for that. We could do

57:17 a wasm section. We even have some great chat gpt questions in the audience. I don't necessarily think that there's time for those, unfortunately. But there is one final question that I want to ask. It's kind of inspired by the audience. But I think it's good for everyone. John Gabriel asked, is there a roadmap or timeline for ruff development out there? Like, what's next, basically,

57:38 like, I guess the short answer that is no, like, there's not like a published timeline. Unfortunately, like most of this stuff exists in my head. And in issues, like everything happens on issues, like we were just talking about on issues, I'll maybe talk a bit about, like, the things that I'm thinking about. So one is fixing, like the structural pattern matching issue. And so like getting full, like Python compatibility, which is sort of like one bug, but then on locks us doing what I hope will be like a stable release, even if that's not that much changes, and it's just kind of, you know, the marketing of it. But hopefully, we'll fix that. And then we can do like a stable release. The, there are two other kind of big things on my mind. So one is, this is like a really big project, but not not ruff, the thing I'm about to talk about, but I want to extend ruff to do like full code, auto formatting, so that people could use it in lieu of block if they wanted to, I think it's like a really natural fit for what Ruff is doing. And a lot of people asked about it, the way that that will, there's an issue where we talk about this, like on the repo, it's not like some big secret reveal. But the way that I think about that, like, like with all things is I want it to be like sort of incrementally adoptable. Like right now you can use rough with isort, or you can use just Ruff, or you can use rough to your input sorting, but like not as a linter. Like you can kind of pick and choose like what you want to use. And I view like thought of where matter is the same way, like I fully expect that people will keep using ruff and black. But it's just like, the kind of functionality that makes a lot of sense, given what we're already doing, and like the way that the product is evolving. So I need to like a bit careful, because like if like that blog work. And so I'm not like saying exactly when that will be done, but I do want to start working on it. And then the other thing, which is maybe like a little bit less exciting to other people. And it's like, you know, I think at some point I'd like rough to get to a world where it kind of stands alone a little bit more at ease, and you'd quite as much as a compatibility as this compatibility layer. Like right now all the rules kind of map back to, like a are under Tools. And when you're using rock, you're kind of thinking in the mindset of those other tools, like what are the rules and how do I configure them? At some point in the future. I'd actually like, you know, ruff to sort of have its own API like own indexing of the rules and to view that as kind of a compatibility layer that will not go away like this won't put a burden on users. But I'd like to get to a point where like conceptually a lot All this stuff is like, first class and rough. And it's not viewed as representations of other extensions, which I think will enable us to do a lot of cool things. But I'm hopeful that we plan on doing that in a way that has no disruption to users. So we'll continue to support the existing API and such. Yeah, exactly.

01:00:15 Very exciting. Very exciting. Well, congratulations on projects that people seem to love it's got a lot of traction and definitely doing some cool stuff. So for you get out of here though, final two questions. If you're going to write some Python code but editor are using these days,

01:00:30 I use PyCharm for everything that includes rust, lead, you only rust and my Python and PyCharm.

01:00:35 Nice. Is there a cool plugin that basically address support to

01:00:39 yeah, there's just an a fit. There's an official IntelliJ rust plugin.

01:00:42 Got it nice works really well. I've used IntelliJ for like that platform for Dart and flutter. But I haven't tried to plug rust into it. But yeah, it does. It does a lot of things. Cool. And then notable PyPI package something out there, named a couple that do the rust integration nicely. But anything you want to give a shout out to Yeah, I really

01:01:00 want to give a shout out. I've already mentioned it a few times. I think if you're interested in doing Rust Python stuff, you should really look at Maturin Maturin. Alright, It's just, it just like makes the publishing really easy. And you still have to learn rust, which is not easy. I do. It's worthwhile, I think. But it's not easy. But it makes publishing rust code to PyPI Sorry. Really easy. Awesome.

01:01:23 Well, great recommendation. Thanks for being here. Final call to action. People want to get started with ruff. What do you tell?

01:01:28 The main thing that I would like to say is like if you're interested in contributing, even if you don't know that much Rust and are interested in learning, like, I'd love to see you on the repo. And I hope it's a place that people feel really welcome to like come and contribute even if they aren't 100% Sure if their code is right, or anything like that. So definitely really excited to have more contributors and have more people coming into the project. And of course, you should also try using it yourself.

01:01:55 All right, excellent. Well, thanks for being here. It was a great, great conversation with you.

01:01:59 Yeah, thanks so much for having me. It was really, really cool opportunity. Appreciate it. This has been

01:02:04 another episode of Talk Python to me. Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show. Join Cox automotive and use your technical skills to transform the way the world buys, sells and owns cars. Find an exciting position that's right for you at talk python.fm/cox. Earn extra income from sharing your software development opinion at user interviews. Head over to talk python.fm/userinterviews to participate today. On level up your Python we have one of the largest catalogs of Python video courses over at talk Python. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription in sight. Check it out for yourself at training.talkpython.fm Be sure to subscribe to the show, open your favorite podcast app and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, the Google Play feed at /play and the direct RSS feed at /rss on talkpython.fm. We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code.