Brett and I talk about some upcoming work on Python packaging, such as:
- editable install standardization
- other tools using pyproject.toml for configuration
- what should and shouldn’t be in the standard library
- and a few tangents
Transcript for episode 119 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
00:00:01 There are changes afoot in the Python packaging world. Brett Cannon agreed to come on the show again and talk with me about Python Packaging Pipe Project Tomoe and more. We talk about some of the upcoming work on Python packaging, such as edible installs and standardization around that, how other tools use the Pipe Project Tomo file for configuration. And then we go off on tangents and talk about things like why it’s good to have packages like Pip Tumble, Setup Tools and Wheel, etcetera. Etcetera. Not part of the standard library. And maybe we should remove some other stuff from the standard library. And how come we only can use unit test for testing, standard library stuff and even like, why do we call it C Python and not Cycle? And lots more. I always learn a lot when I talk with Brett. This episode of Test and Code is brought to you by Datadog Modern Monitoring and Security and by Circle CI Continuous Integration and deployment, and by listeners like you that support the show through Patreon. Thank you.
00:01:16 Welcome to Testing Code, because software engineering should include more testing.
00:01:24 So there’s stuff going on with Piproject Tummy.
00:01:29 There’s a lot of stuff going on with just packages, period. But yes, there’s stuff going on with Pi project packages, period.
00:01:36 Yeah, there’s stuff going on in the packaging ecosystem.
00:01:40 Well, let’s start with the Tamil stuff in place, installs, or what do they call those?
00:01:51 Editable installs.
00:01:52 Editable installs. Is that going to happen.
00:01:57 In what way? You mean Edible Installs working with Pyproject Tumble and all that stuff?
00:02:01 Yeah.
00:02:04 To be totally clear here, the concept of Edible Installs is actually a set of tools concept. There is no spec or standard backing them out at all.
00:02:12 It’s just a concept that Set Up Tools came up with back in the eight days.
00:02:17 For those of you who don’t know what Brian and I are talking about, Editable Installs, basically from Setup Tools will drop a. Pth file and an egg info directory into your site packages so that you can edit the source code of your project in place and then have it show up as if it had been installed specifically.
00:02:44 And the deal is, because it’s a set of tools concept, there is no direct support for it anywhere in the packaging ecosystem. Now, right now, literally today, there’s a thread going on right now about what standardizing Editable Installs would look like. And there’s moving on it even today discussing what such a standard would have to look like to make that work. Because at least on the Pip side of the packaging ecosystem, we’re making a big push right now to try to make the whole packaging ecosystem run off of standards because for the longest time. Right. Everything was just disutils or just setup tools, and it was just however, Setup Tools did it, which was never specified. Right. So, like, you never know if you’re really breaking anything, because I mean, Setup Tools is great project and we appreciate the hard work they put in, but they didn’t write everything. They haven’t written everything down and they never will. It’s just way too big of a project and they have other things to worry about. So there’s no way to tell Flint, hey, this is the way it should work. Because the answer has historically just been, however set up tools did it’s like, well, how’s that? And you have to just kind of figure it out and just reverse engineer it and hope you reverse engineering in a way that people agree that that’s the way it should be. So as far as that, we’re trying to move towards standards, but because editable installs are used enough, what’s happened is build tools like Flint and such will create stubsetup. Py files so that you can still use setup tools to kind of fake out the editable install for you, even if you use a different build tool.
00:04:17 That’s basically all I think you’re alluding to, because this is all coming off of that big Twitter thread in my blog post.
00:04:24 Yeah. And I was confused, actually.
00:04:28 Okay, so normally if I’m working on a project like I clone it or something and I want to use it as if it was installed. Like for instance, if there’s a command line tool or something that I want to use, I can just say Pip install.
00:04:46 I and then like dot for the current directory and the dash. I said in place install.
00:04:56 Actually if I just do not without the I if I just do the dot, it installs the current directory anyway. And that works even with Flit.
00:05:07 Yes.
00:05:10 But if you edit, it doesn’t make changes. So I’m not sure. I think I don’t actually know what happens under the hood if it builds the thing and then pops it to the directory or something.
00:05:22 Exactly. Okay, if it’s building a wheel behind the scenes and installing the wheel.
00:05:26 Okay, but the Flip has an option to do like you can do a flat install with either.
00:05:37 I can’t remember the flags. It’s either a PTH file or s for the symbolic links or something.
00:05:44 I don’t really know what it’s doing. It looks like it’s just copying your project directory or a link from your project directory to the setup directory or something.
00:05:54 Yeah, most tools either figure out where your code exists and they created some link. So Flip could easily be going like, okay, so Brian has this project called Spam. It’s in a source directory because everyone knows Brian loves source directories. So what it would do is it would Simlink srcspam into your site packages directory as spam. And then that way all it has to do, technically really to look like an edible install is create the disinfo directory, which contains all the metadata for an install package, and then to Python and all the other tools in the world, it just looks like any other installed project. Okay, but you can add the source code because it’s literally just a simple link away.
00:06:37 The other way to do this is with. P. Th files, which is short for path. And what you can do with. Pgh files is you can specify you can stick them in your site packages directory and any line in a. Pta file is not a comment or starts with import will be added onto your system path. So what you can do is you could drop a. Spam. Pth file in your site packages and have that just point back to your. Srcspam directory and then it would just stick that onto your. Syspath. Or actually it probably just put SRC and then that way when sistopath hits your. Src it’s going to know spam there and then it could just directly import it. And once again you can just edit it in place and then the install won’t look any different because that. Pth files. What’s causing Python to look over there? Okay, to deal with all this, as I said, is none of this is standardized. There’s no standard. How does Pip or how does Flip specify how any of this works? It’s all just based on just old practice of setup tools, and that’s what we’re hoping to eventually solve when someone has enough time to do it is what’s the standard for this? What’s the specification?
00:07:47 Okay, but if I want so this trick of doing like a stub setup.
00:07:52 Cfg file or something set up by stubutup. I why would I do that? Is it so that I can do pipinstall. I instead of flip install?
00:08:05 Yeah, it depends on the tool. Basically where all this is coming from. Just so everyone has background is if you use a. Pyroproject. Tomo file to specify your build tool, you technically do not need to set up. Pi file even if you’re a user got it in your project. Tom will specify that set of tools is your build tool and you specify the online that tells your bill tool how to run setup tools.
00:08:40 That’s all that’s necessary to build a wheel using set up tools, and a pipe without Tom will file. So that means you don’t need a setup. Pi, right? If you have a set up CFG, setup tools knows how to get all the details from there, period. So you can actually ditch that setup. Py file, except when you want to do edible installs. That concept is so specific to setup. Py files and setup tools that you need this little Shim of a set up. Py file. That literally is like nothing. It’s literally I think if I Mark it import setup tool setup tools set up and that is it.
00:09:14 And then set up tools itself will just go, oh, okay, I’m going to look for the setup. Cfg. I found it, I’ll parse it. I got all my information. Now I can do whatever I need but that whole idea of doing edible install tools like Tip and stuff, just assume it needs to set up. Py file and it’s going to be set up. Pyramid, I thinkdevelop is the flag. And so that’s why it exists is purely because all the tools just assume that if you say Give me an edible install of my project, it’s going to be set up pipe develop, okay? That’s the entire reason that file needs to exist, even if you have all of your details and setup CFG. This is why Flip passes one around as well. It’s basically backwards compatibility with tools that just completely assume that set of tools is what you’re using.
00:10:00 Okay.
00:10:00 And there’s typically Freddable installs.
00:10:02 And there’s a way to do this hack with Fled as well.
00:10:05 Fled does it for you automatically.
00:10:08 When you generate your Estes, it actually tosses it in for you.
00:10:12 Okay, would I do a Flip builder or something like that?
00:10:16 Yeah, I believe so.
00:10:18 Okay, cool.
00:10:22 This episode of Testing Code is brought to you by Datadog. Datadog has been a long time sponsor of Python Bites, and it’s super cool to have them support this show as well. Do you have an app in production that is slower than you like? Is its performance all over the place? Sometimes fast, sometimes slow? Do you know why? With Data Dog, you will you can troubleshoot your app’s performance with Datadogs end to end tracing, and in one click correlate those Python traces with related logs and metrics. Use their detailed flame graphs to identify bottlenecks and latency in that app of yours. Start tracking the performance of your apps with a free trial at Test And Code. Comdatog. If you sign up for a free trial and install, the agent, Datadog will send you a free T shirt.
00:11:07 Okay, so there’s discussion around.
00:11:10 Basically, if we support editable installs how and is just not supporting him an option still?
00:11:20 Or do you think they’ll happen eventually?
00:11:22 I think it’ll happen eventually. It’s basically too convenient not to.
00:11:27 The discussion has been coined in Fits and starts at PyCon 2019. At the Packaging Summit. During the sprints, the topic came up, a sketch was developed, and basically the thing was someone has to take the time to create a proof of concept. Some build tool has to support the idea of what it will take to do an edible install. And then that’s the back end tool. And then we need a front end tool like Tip to try to use the back end tools proof of concept implementation to verify that this is a reasonable standard, that there’s nothing fishy or we’re missing big holes, or we have some blind spot we’re not aware of. And so what happened is, I think literally, at least on my reading, today may have happened yesterday. I don’t know.
00:12:11 Finally, I think everyone got all the details pulled together in one spot, and now we’re just hoping some of the people interested are going to have the time to sit down and take one of the build tools. I think Daniel Hall is talking about maybe trying to update Inscons, for instance, for edible installs. Basically, as soon as one person does it, we can then hack together. One of the Pip developers can hack up Pip to try to use this new API and see if it works. If it works, then we’ll write up a Pep, we’ll put it forward. It’ll probably get accepted because the whole packaging community is working out together, and then we’ll just have a standard, and then all the tools can end up growing edible install support naturally, and not have to have this little weird Shim anymore.
00:12:51 There’s still quite a few tools that you cannot put your configuration in a Pipe project tomorrow file.
00:12:58 Yeah, well, there’s a funny history about that. So when I co authored Pep Five One Eight, which standardized Pipe project Tumult and how to specify the build tools necessary to build your project, we explicitly forbade other tools from using it.
00:13:18 Well, that was your problem.
00:13:20 Yeah, I know. So we did it. And then obviously people ignored it pretty quickly because I think everyone realized it was really convenient suddenly having a single file to store all your projects specific configurations.
00:13:33 And it made sense. It’s just basically what we wanted to do is we wanted to start slow and the idea came up. It’s just standards are hard enough as it is, but trying to be too flexible at the get go without having good insight as to where things are going to go leads to trouble. Right?
00:13:51 Perfect example. Python is our transition from Python two to three.
00:13:56 We thought the transition would not be nearly as bad because we honestly thought people’s code had a clear separation between textual and binary data. So we didn’t think it would be so hard for people to make the transition and clean up their we didn’t think there’d be much code cleanup for people to try to get a very clear distinction between what was binary data to them and textual data. But because we didn’t have insight into other people’s code bases, we’re going off an assumption. And it turned out to be wrong. People’s codes were not that clearly separated, and for people who did not have as clear of a separation, the transition was much harder.
00:14:30 So having learned that lesson, we try to when we do standards now be very tightly scoped and focused and restrictive because it’s much easier to add things later than to take things back.
00:14:41 And so in this case, we said, okay, instead of getting it wrong. And when you take back the fact that other tools can use Pipe, we’re just going to start with no one using it for that. It’s just for us. And for packaging builds, no one else can use it. People completely ignored it, and then we Cook it. Okay, you know what? It’s fine.
00:15:03 Other tools are using it and it works out great.
00:15:07 I actually updated the Pep.
00:15:09 I can’t remember when.
00:15:11 Luckily we marked it provisional, so it was totally cool to update. She marked it final, I think. Last month. I wanted to just ask why is it still provisional? I was like, honestly, no one thought to bother to make it not provisional anymore because it was one of those things we did provisional on purpose initially, and we prefer to sit on it until we got it locked down and we’re not tweaking it at this point.
00:15:30 Well, like for instance, like Black, I think it’s the only way to configure.
00:15:34 Black is the only yes, Black is one of the common tools that trips people up when they suddenly opt into Piper Tommy and isolate the builds. So for people who don’t know, Pipeline originally was a file to specify your build dependencies. It was just be able to say I use set up tools and wheel to build a wheel or I use Flit or whatever. It was the way to tell a tool like Pip, this is what you’re going to have to install somewhere in order for you to build me as a wheel.
00:16:05 Straightforward Pep five one seven then brought in the concept of specifying the API necessary to actually run the build tool. So five one eight said here’s the file, here’s how you specify I need Flit.
00:16:19 Five one seven says, okay, here’s how you say how to run to tell Pip how to run Flip.
00:16:25 Now the deal is because we are installing build tools now we have to build your code in isolation because otherwise we end up back in a situation of people are installing stuff into their global install, right? You should not be installing Flips into your global Python just to build one of your projects. It should be a per project thing, especially if you’re specifying different build tool versions. Once again, you may not have updated.
00:16:47 So if you’re doing that, what that means is that you’re going to need to build an isolation, you need to build in a virtual environment. So what Pep did when they designed their support for Pipe was okay. If a Pipe project Tumble exists, we’re going to do an isolated build of your project. Which sounds fine, but people have some really hacked up set up Pi files that are not designed to run in isolation. Like they make massive assumptions that it’s running straight from a Git repo and has not been moved and all these other things and things just fall over.
00:17:29 And it made sense when they started it because remember Five one eight did not let other tools do it. It was purely you only have this file if you were doing build, it was only for specified build stuff, but when all the other tools started to use it, it only became a bit more than just a build tool thing. It just became a project configuration file that was also used for building. So because it no longer acted as a flag.
00:17:55 And so that tripped a lot of people up, especially when popular projects like Black now, for instance, only has that, which I personally think is great because what it means is people forget that. People complain like, oh my God, black only uses Pipe project at optimal. Realize that if it didn’t do that, you’d have yet another configuration file somewhere in your project just for Black, which I think we all agree is a good thing to have less of.
00:18:17 Yeah. Or if you want to or just don’t configure it.
00:18:20 Yeah, exactly. I don’t configure Black. I just run Black and I just don’t care anymore.
00:18:26 But that trip a lot of people up is because Pitt decided to use Pipe project to flag build isolation as Pep five one seven requires things started to fall over and people just weren’t quite expecting that.
00:18:39 Okay.
00:18:43 This episode is sponsored by CircleCI. Designed for modern software teams, CircleCI continuous integration and delivery platform helps developers push code with confidence. Trusted by thousands of companies, from four person startups to Fortune 500 businesses, CircleCI helps teams take their software from idea to delivery quickly, safely, and at scale. Visit Circle CI Test And Code to learn why high performing DevOps teams use CircleCI to automate and accelerate their CI CD pipelines. That link, again is Circle CiTest And Code, and that link will also be in our show notes. And you will definitely want to go and check that out before July 30 because you can enter to win a pair of Sony noise canceling headphones. Very cool, Circle CI. And thank you for sponsoring this episode.
00:19:38 Now, is there a Tommy Parser in the Standard library?
00:19:44 No.
00:19:45 Okay, so I think that’s one of the reasons why some projects don’t want to support Pipe project Como because it just has yet another dependency that they need to bring in.
00:19:57 Well, so it’s funny, right? Okay, so there’s a couple of points on this. One is the reason there is no Tamil Parser and the Python standard library is Tommy has not reached version one yet.
00:20:09 So as we all know, anything that ends up in the Standard library doesn’t really get to evolve anymore. Right. Because there’s backwards compatibility guarantees and we don’t want to break people and all that stuff. Even at an annual release case that we have now for Python, we don’t want to break people. So the idea that suddenly you have a Tumble file and let’s say Tumbles, I think 0.5 right now and they’re about to hit one. I think they released 1.0 RC recently. And I also mentioned prejudice. One of the maintainers of Pipe is actually one of the maintainers of Tumble. So that helps a lot.
00:20:45 But the deal is because it wasn’t at one when we chose it, we didn’t want to put something in the Standard library because if the Tumble format changed in some way that broke things.
00:20:57 The usage we had in five, one eight was very basic, so it was not going to break due to any of the PEPs rerogue. But if you were using it for who knows what, and something broke, suddenly everyone’s going to go, well, you’re not following the version one spec.
00:21:13 It’s like, okay, so we update, but now suddenly broke people. So we couldn’t do it until it hits 1.0. So that’s the main reason it hasn’t gone in yet. The other thing is, you hear people go like, oh well, I can’t do this without something in the standard library or I’m going to have to vendor it.
00:21:29 Well, so the funny thing is everyone says, oh, one more dependency, but don’t you already have more than one dependency in your project? So why is this one little dependency such a hang up for people? It’s not like tomorrow’s parsers are huge. There’s not like you’re downloading TensorFlow, which is like, I think a couple of hundred Megs.
00:21:52 It’s funny.
00:21:54 I know it’s a psychological thing, but it’s funny when you say, oh, one more thing for I guess because it’s configuration or something. Why is this not in the signed library? It makes sense to me to be in the signed library. It’s like, well, it’s not. Well, I want to use it because I don’t want to have one more dependency. But I’m willing to bet almost everyone who says that has at least five dependencies whether they download it dynamically or they vendored. It like Pip or who knows what.
00:22:17 For instance, the Pit developers. Fine, they didn’t care. They vendor’s tumble parser. It’s not a big deal.
00:22:23 It’s just there poetry. They wrote their own Tommy Parcel. They have one called Tumble Kit, which was designed such that you can update Tumble file and not change the formatting. So like, if you run poetry and the poetry install and you specify a new dependency, it’ll actually only add that new line and will reformat everything.
00:22:46 It’s worked out. It’s been fine. You do run into people like that, though.
00:22:51 I get the idea. It’s like, oh God, one more thing. Why can’t the standard libraries have it? Well, do realize that basically what you’re asking is I own the tumble parser, right? This is not a freebie thing. It’s a freebie to you because it’s one last line in your configuration file. But that’s another thing for me and the core Dev team to maintain. So it’s free from a certain perspective, but it’s not free from another perspective. And once again, once it’s in the standard library, it ain’t changing because the risk of breaking people is way too high, really. So having outside the standard library makes it a lot easier to maintain, to evolve and get to where we want. Now that’s not saying we’ll end up there. It’s just at least from my personal view, it’s one of these funny things when people said, oh, God, I can’t use Tumble tilts in the Center Lib. It’s like, I’m willing to bet you’ve got other stuff in there.
00:23:41 Okay, I get that. But it is interesting to me that I can’t package Python without installing extra stuff.
00:23:49 What do you use to package Python?
00:23:52 What do you use to package your stuff?
00:23:53 Well, now I use Flit, but I used to.
00:23:56 But before that, setup tools. Well, set up tools in there, right?
00:24:01 Well, that’s what I’m saying. And it always surprised me. I was like, why not? Why isn’t set up tools in standard labor?
00:24:10 Well, look at it this way. Set up tools have been the standard library. Do you think any of the changes that have been made, like set up to see if G or anything would have happened?
00:24:17 Disseutils is the perfect example. We’re actually trying to get this utils out of the standard library because it can’t evolve. We can’t touch it because we’ll break people. So we’re actually trying to get this utils out of the standard library and just part of the setup tools so it can actually have bugs fixed and things change to be more sane because we’re too scared of breaking the world if we change anything in there.
00:24:36 Yeah, actually, that makes sense. And we were not talking about this specifically, but I think you and you were on a Python Bites where we talked about the splitting up of basically whether or not the standard library should be a lot smaller than it is now.
00:24:58 Yeah. It’s a question we have not had on the core team. Well, I take that back. We’ve had it many times. We’ve never finished the conversation. It’s a hot topic for a lot of people. Right.
00:25:10 It’s one of these things where people go, like, I would love to have this in the standard library. And you go, okay, why a lot of the time is either I think it’s my project and I think it’s great, and I think the whole world should have it, which is fine. But that’s not a reason to put it in. Or someone goes, I think this is fundamental to coding.
00:25:30 And at least half the time we have to say, actually, no, it’s not. If you look at the majority of Python developers, they’ll never need this. Now, other times it’s like, this is extremely niche, but extremely difficult to get. Right. Cross platform, like the OS module, for instance.
00:25:45 That’s really hard to do. Right. So it’s in the center library because it evolved over years and years. But a lot of the reason the standard library exists is because it predates everyone having the Internet. Right? Like, Python came out in February of 1991. It predates Linux, for God’s sake, being public. It’s one of these things where people don’t realize that it predates graphical browsers.
00:26:06 I don’t know how many people know this, but one of the first GUI browsers was almost written in Python Gradle, actually.
00:26:14 So it’s one of these weird things where the reason we have the standard Lib is because Python predates the Internet in that regard, the World Wide Web, and it’s that kind of structure. Now that we have Pip and Pip to what it’s at.
00:26:28 If we were doing the same library again, would we still have it the size it is? Would we have it be smaller? Would we have it even be larger? Would we do a Sumo release that some people have talked about and have it contain a whole bunch of things? I don’t know, but this is one of those things where now that we have a steering Council, I have a sneaking suspicion we’re going to have I don’t know if the reckoning sounds way too negative, but we’re probably going to finally have this conversation and really try to hash out what is the standard library.
00:26:57 What is its goal? How do we want to maintain it? Where do we want to go? Especially now the Python two done. Right. Because a lot of stuff we’ve kept around for a long time was specifically so we didn’t break people doing transition two to three code. Now that we don’t have to worry about Python two code anymore, there’s a bunch of modules we can drop. Like Christian Hines has a whole list of modules we can probably stand to deprecate and just get rid of. And it’s very conservative so past that, the question becomes what should the barrier of entry to be? Should we even have a standard library? Should we just have things we consider so important? The Python core team maintains it, but we still ship on Pip and you install it that way. And we just kind of have a Sumo like for lease.
00:27:40 It’s tough because we also have people come and tell us like, hey, getting any IP outside of my company is really hard. So having the standard library helps a lot because when Python is installed, I can get the lawyers to okay Python and everything that comes with it, and that’s it. So if we strip it out suddenly they can’t install anything and get anything done because they have to get approval for all those little things. So it’s really complicated. Yeah.
00:28:03 Or they could be like a layered thing.
00:28:06 I don’t really think of things have changed recently, but C plus plus isn’t just C Plus Plus. It’s the code plus standard temporary library and some other stuff that really aren’t part of the language. But you kind of use them together. So there could be like, oh, well, there’s the web stuff that you add or the data stuff, or there’s other stuff in a set of packages or something, maybe, but having the core small, but it is interesting to talk about.
00:28:42 I was just thinking Python has batteries included, even the dead ones.
00:28:46 Yeah, exactly right.
00:28:48 I mean, another really good example is look at circuit Python.
00:28:52 Yeah.
00:28:53 You’re running stuff on a little IoT device that we were given at Python.
00:28:58 Fantastic. Does it really need to have the CGI module?
00:29:05 Right, exactly. Does it need to be running PY Doc?
00:29:10 It’s kind of things that you just don’t stop. I mean, I had a really crazy I made a very outlandish comment on Twitter one day and some people really kind of one person kind of took me to task on it because they really disagreed. But honestly, does Python need a rubble?
00:29:25 Oh, wow.
00:29:26 Yeah.
00:29:26 That could be an add on.
00:29:27 Yeah. Right. Like the Python language does not require a replace, not saying it’s extremely useful. And the Python’s popularity isn’t at least partly due to having the reply to make it very accessible. But that’s not really part of the definition of what Python is.
00:29:43 Well, right.
00:29:47 Application packaging ideas is to just package Python with whatever with your application and send it to your user in various ways. And if the language itself was a lot smaller because it had none, most of the standard library ripped out and you only package the stuff you needed, those be smaller images.
00:30:12 Yeah. And unfortunately, there’s no good answer, and I don’t have one.
00:30:16 Just to be very clear here, I don’t want anyone reading into this. The Brett Cannon of the Steering Council said we should get rid of the standard Iran. That’s not what I’m saying here. I don’t want anyone to take ants out of context.
00:30:25 You heard it here the first Bret Cannon says that we should rip out the stairs.
00:30:31 This is the things we grapple with whenever this topic comes up is like where are the lines?
00:30:37 Where is reasonable? And the problem is this is all extremely subjective.
00:30:43 No one has good numbers of like what modules are people actually using? And are they using enough to justify keeping in the center library? Does it make sense? Is stuff evolving like another good example?
00:30:55 Why are people complaining about why are people not going like, well, I’m not going to use httpx or requests or any other client side networking library to download something, right? I’m only going to use URL Lib.
00:31:10 No one says that everyone uses requests or they use httpx, which if people don’t know httpx, it’s very good. I do recommend people check it out. It has full Acing supports. Awesome. Anyway.
00:31:25 But my point is everyone’s happy to download that and make that a dependency. And yet some people get a little cranky over not having a tumble parcel of all things.
00:31:33 It’s funny how everyone’s delineation of what isn’t is not acceptable, varies from person to person, and part of what makes this such a tough conversation to have.
00:31:43 Yeah. So one of the reasons I heard that unit test is in the standard library was because you want to use it to test the rest of the standard library.
00:31:54 I don’t know. The history unit test predates me becoming a core developer, but that is definitely the key use case. Now is unit test.
00:32:02 We use unit test to test Python.
00:32:05 Yeah.
00:32:09 Is that true, then? That all testing. You can’t use extra stuff.
00:32:16 We try not to.
00:32:17 Okay.
00:32:18 Basically, we’ve tried to make sure that the test suite for Python works completely from a checkout. And all you really need is all you need is a compliant C 99 parser. And you don’t need a completely C 99 compliant parser. You need a parser that implements all of C 89 and some selective parts of C 99, and that should be it. And then the autocompt tools. So you have to be able to run make. But that’s all that’s required to build C Python.
00:32:45 There’s some little extra tests that have optional bits for, I think, some external things. I can’t remember what they are, but the vast, vast, vast, vast, vast majority of all the tests don’t require anything outside of a source check out.
00:33:00 Yeah.
00:33:00 So like you can’t use hypothesis, for instance.
00:33:03 No. Although the team made a presentation at the Language Summit the other week about potentially using hypothesis to do some testing on Python?
00:33:15 I think that’d be cool.
00:33:17 Yeah.
00:33:18 I personally think they made a compelling use case. But once again, it brings up the question of, okay, does it make sense to have Pythons test suite and specifically see Python’s test suite depend on something that’s not in the standard library? How would that work?
00:33:34 How do we manage that? Do we somehow have to bundle it in and check into the source repo? Do we have to do like an insurer hypothesis thing and if it’s not installed, we just skip the tests?
00:33:48 Do we do in a whole separate repo and kind of more of just a. Yeah, these tests exist and they’re over there.
00:33:54 But it’s kind of just run and CI sort of thing.
00:33:59 Yeah. It’s a separate repo designed for different things and different requirements, and it’s just all kind of run in a different way and just kind of an isolated incident.
00:34:07 I don’t know. Once again, that discussion just happened.
00:34:13 When was that was Language Summit last week. I think it was last week, maybe two weeks ago. Fairly recent idea.
00:34:23 Okay. So now that I’m thinking about the CPython a little bit, do you know why CPython is C Python and not like Cython?
00:34:36 So it’s C Python because Guido likes C and not C Plus Plus.
00:34:40 Okay.
00:34:41 It will totally work with C Plus Plus. We have all the proper Extern C headers stuff that are gated appropriately and. H file so that you can totally embed that cyclone in a C application. So that’s not a problem. But you also have to remember, Guido started this back in 1989. C was a lot older than C Plus Plus at that point. And I think honestly, we just preferred C.
00:35:02 Okay.
00:35:04 Yeah, I was just curious about that because even Mike C Code that looks like he is running on a C compiler anyway.
00:35:14 Cool.
00:35:15 Well, thanks for letting me pick your brain on all this stuff.
00:35:18 Of course.
00:35:18 Anytime and we’ll talk to you later.
00:35:22 All right. Talk to you later.
00:35:23 Cool.
00:35:26 Thank you Brett. As always, I learn a lot when we talk and thank you Datadog for sponsoring check them out at testandcode.com Datadog. Also thank you to CircleCI for sponsoring check them out at circle ciTest And Code and thanks to listeners like you that support the show through Patreon join them via by going to testandcode.com support all those links and links to many of the items that we talked about on the show are in the show. Notes at Test And Code.com 115 that’s all for now. Now go ahead and test something.