Intro

Learn about contributing to Python:

Python List of Issues
3 Mailing Lists to sign up for to get started with contributing to Python:

Video

About the Speaker

Carol Willing is a member of Python’s Steering Council and a core developer of CPython. She’s a Python Software Foundation Fellow and former Director. In 2019, she was awarded the Frank Willison Award for technical and community contributions to Python. Carol is a long-time contributor and ACM Software Systems award winner for Project Jupyter. She sits on its Steering Council and works as a Core Developer on JupyterHub and mybinder.org. She serves as a co-editor of The Journal of Open Source Education (JOSE) and co-authored an open source book, Teaching and Learning with Jupyter. Carol has an MS in Management from MIT and a BSE in Electrical Engineering from Duke University.

GitHub: @willingc
LinkedIn: carolwilling

Video Outline

NOTE: the timestamps are marked in the video description.

00:00 Reshama introduces Data Umbrella
04:20 Reshama introduces Carol Willing
05:25 Carol begins talk
08:28 Python Steering Council
10:00 Slides recap
11:41 Kind of contributions needed in Core Python
14:44 Contributing to Data/Scientific projects vs to CPython
20:01 How to start contributing to CPython
23:05 Reasons for contributing to CPython
24:05 CPython Dev Guide https://devguide.python.org
29:23 How to build and test CPython
32:27 Resources to learn about CPython Internals
35:35 Resources for contributing to python
37:10 CPython community
38:21 Getting started with Q&A
38:38 Q: Is it needed to reproduce old bugs against new versions?
40:40 Q: Multiprocessing vs Threading to increase performance
41:19 Q: Does the project have any process to find a mentor?
44:00 Q: Form your viewpoint what is the future of Python?
48:47 Q: What are the efforts of the Python Steering Council to make the community more inclusive?
52:29 Q: What will be the impact of the PEG parser?
54:12 Q: Development time vs. Code performance optimal performance

START of Carol’s presentation

Full Transcript

Reshama introduces Data Umbrella

Hello, everyone. Thank you for joining our webinar for today. Thanks for joining Data Umbrella. I’m going to do a quick introduction. Carol Willing is going to do her talk and we’ll have a Q&A session at the end. And this webinar is being recorded. A little bit about me. I’m a statistician data scientist. I’m the founder of Data Umbrella and I am on Twitter, LinkedIn, GitHub as “reshamas”. Feel free to follow me. We have a code of conduct. We’re dedicated to providing harassment-free professional and respectful experience for everyone. This applies to the chat as well. Thank you for helping make this a welcoming and friendly community for all of us. About Data Umbrella, we’re an inclusive community for underrepresented persons in data science. We welcome allies to join us. And we are a volunteer-run organization. So how can you support Data Umbrella? The first and foremost is to follow our code of conduct. The second is we have a Discord community chat. So feel free to join it. The link is on our website. And there you can ask questions and answer questions as well for the community. We have an open collective. Feel free to also, if you want to donate there, to cover our meetup dues and other operational costs. And we have a new initiative called, you know, we’re doing transcripts for all of our talks. And it is – the transcripts are on GitHub and it requires knowing some markdown and how to submit a PR, either via terminal or GitHub. So check out this link, GitHub.com/dataumbrella/event transcripts for more information. We also have a job board, which is under jobs.dataumbrella.org. If you are looking for a position or just curious, feel free to check it out. We have two highlighted jobs today. The first is a software engineer position at Oscar Health, which is based in New York City. It’s a health insurance company. And they are developing seamless technology and provide personalized support to members to navigate their health care. And they have some other roles open as well. So check it out. Our next job that we’re highlighting is a machine learning engineer by Development Seed. They are based in Washington, D.C. or Lisbon, Portugal, or they can be a remote position for now. And what they do is they’re mapping elections from Afghanistan to the U.S., analyzing public data and economic data and leading strategy and development behind Data.World Bank and other social enterprise initiatives. These are just a sprinkling of what we have available on our website. There’s a lot of resources on responsibility, on accessibility, on open source. So check that out on your own. We have a monthly newsletter. It is dataumbrella.substack.com. So feel free to sign up for it. We only send it out once a month. So we promise not to spam you with too much email. We are on Data Umbrella is on a bunch of different platforms under Data Umbrella. So depending on what your preference is, the best place to actually be a member is the Meetup Group because that’s where all the events are posted. Our website has resources. We are on Twitter. We are on LinkedIn. We are on YouTube. If you want to subscribe to our channel, I will post some of these links once I finish this interview presentation on the chat so you can follow it. Before we begin, I just want to let you know that next week our upcoming event is using Streamlit for data science with Thomas Fan. Thomas is also a core contributor to scikit-learn. Streamlit is a way to build and share data apps in Python. I think it’s going to be a great presentation. I’m so glad that Thomas said yes when I invited him and asked him.

Introducing Carol Willing

A little bit about today’s speaker, Carol Willing. Carol has an MS in Management from MIT and a BSc in electrical engineering from Duke University. She is a core developer of Core Python. She is a member of Python Steering Council. For Project Jupyter, Jupyter Notebook, as many of us have used, she’s on the Steering Council and works as a core developer on Jupyter Hub and MyBinder. She is also co-editor of the Journal of Open Source Education and she co-authored an open source book, Teaching and Learning with Jupyter. There’s a lot more that Carol has accomplished, but I was running out of space. So I will let Carol take it over from here. Oh, and just one more thing. We have a Q&A tab on this platform. So if you have any questions, just post them there. If you do post them on the chat, it’s not a problem. I can easily move them over to Q&A. And if you want to upvote them, you know, I think we’ll have time to answer everyone’s questions, but feel free to upvote to see what’s really exciting and important for you. And I will hand it over to Carol.

Carol begins 05:25

Thanks, Reshama. Thank you all for being here and thank you for the sponsors and everybody who organizes groups. It’s really important and it helps us as an ecosystem get stronger. I am going to start sharing my screen, hopefully, and once Reshama lets me know that you guys can see everything, then I will start. There was a little bit of a lag before, but okay. Well, I’m going to assume you can see my slide deck. Otherwise, somebody please shout. So today, I’m going to talk about contributing to core Python. But I’m going to do it from the lens of a scientist or a data scientist. So it’s going to be my opinionated view of working in all of these communities. And for those that are advanced users, you will find something useful in this. For those of you that have never contributed to open source, you should also find a lot of really useful stuff. As Reshama went through my bio, the ending part talked about education and using tools. And that is really where my heart and passion is. Less about the technology and more about building tools that empower other people to do good things in the world. And I think our science and data science ecosystem helps us do that really well. So let’s get started. So, yes, core Python and CPython are the same thing. You will hear them used interchangeably. And for all intents and purposes, you can just assume that they are actually the same. So for today’s talk, we’re going to look at this from a data and science perspective. So the primary audience is data scientists, scientists, data engineers. But other folks that might get value out of this are computer science, compiler engineers, operating system experts, language geeks. But that won’t be the focus of the talk. It will be the data folks and science folks. Okay.

How Python is Organized

So contributing to core Python today, I’m going to walk a little bit through how core Python is organized today. Then I’m going to compare it to other open source projects in our ecosystem of data and science. scikit-learn is a great example of that. And then we’ll talk about getting started and how you can go further with your contributions to either CPython, open source, your local community, and more. So we had an interesting thing happen a couple of years ago. Guido van Rossum, who had been the benevolent dictator for life of Python, stepped down. And we were faced with having to create a new governance for core Python. And what we came up with was a small steering council. These are the members currently who sit on the steering council. And really, we are to sort of do and set the direction of things that Gita did by himself in terms of organization in the project and direction of the project. And in specific, we are tasked with ensuring the quality and stability of the language, moving towards contributions that are accessible, inclusive, and sustainable, fostering a stronger relationship with the Python software foundation, continuing to facilitate the decision-making process for PEPs, which are Python enhancement proposals. When there are large changes made to the language or proposed to the language or workflow, that’s something that is open for everybody to read and comment on. And our goal is to seek consensus both with each other, but also the community at large, because we don’t want to be a dictator of the direction of Python. So, as we look at core Python, what kinds of contributions are needed? Lots. But I want to first step back and look at the Python software foundation, which is a sister organization to the core Python developers.

Sorry, just in general, we see you, but we don’t see your slides. » Uh-oh. » So, maybe if you can just share again, maybe… » Let me stop sharing and resharing. » Yeah, that might work. » Ah, that might work. Let’s see if escape will do it. Worked in practice. Let’s do it again. Okay. Now you should see my whole desktop. Is that correct? » Okay. It takes just a couple of seconds for the lag. It is loading, which is good. And now we can see your whole desktop. Yep. » And now you should be able to see the talk? » Yep. Now we can see the talk and we can see you. » Okay.

So, speed version. The title of the talk, core Python opinion guide for scientists and data scientists. Yes, core Python is the same thing as CPython. I’m targeting this to the scientists and data scientists and data folks in the audience. We’re going to go through a few different ways of contributing to core Python and beyond. I started with a quick discussion of governance, our introduction to steering council, what the steering council is responsible for. And now back to you. Which contributions does CPython need? And looking at the mission of the Python software foundation is a good place to start. The Python software foundation is a sister organization to the core Python group. And its goal is to promote, protect, and advance Python the language as well as to grow a diverse and international community of Python programmers. So, as you think of making contributions, keep that in the back of your head because those are really going to be the most valuable contributions. Some ways you can contribute. And oftentimes, people look at writing new code as the only way to contribute. And it is a great way to contribute. But in many ways, a lot of these other ways to contribute are equally, if not more, important. When you’re adding new code, it’s got to be with backward compatibility. We’re a 30-year-old language. People are using this in production. They don’t want things breaking. Maintaining security, anything you can do to maintain the security of the language. Or improve core development workflows. So, Mariatta has put together a lot of bots that make our core development workflow much easier for folks to get started. And also, for GitHub and the power of technology to help with some of the more tedious tasks.

Writing and running tests.
Writing and editing documentation. Both of those are absolutely critical to the success of any open source project. Python as well.
One huge need we have is folks to triage bugs for reproducibility. And in addition to that,
people to review open PRs.

Right now, we’re split our code bases on GitHub. But our bug issue tracker is on bugs.Python.org. So, there’s sort of an extra step between the two. So, it’s helpful with decreasing the backlog of PRs and bugs for people to help triage and review PRs. And in the last year, we’ve actually started a triaging team which is in many ways a stepping stone to core development. And then, really,

anything that you do to share your knowledge with the community,
maintain projects,
give talks,
write blog posts,
10? meetups, that is a contribution to core Python. So, congratulations. You’ve all made your first contribution to core Python. Or at least the Python ecosystem. So, I’m going to spend a minute comparing the different projects. And comparing and contrasting Python versus other projects that are younger like Jupyter, Matplotlib, scikit-learn, and more.

So, what’s similar?

Well, most of these projects use a GitHub workflow.
And with that, I mean we host our source code on GitHub or GitLab.
And we operate with a pull request mindset. And what that means is a pull request is, hey, I would like you to take my code and add it to your code base. And then a maintainer will either say, yes, that sounds like a great idea. I accept it. Or, gee, could you make these changes and then resubmit it? Or in some cases when it’s just not an appropriate contribution, we might say, you know what? This would be better as a third party project or another project.
All projects have code review. And that’s when maintainers and core developers look through code that’s being submitted or documentation that’s being submitted. And make suggestions, hopefully very kindly, about what could be changed or improved.
And many strong projects have automated testing and continuous integration. And it’s really valuable to have that as part of your project because it provides sort of an independent view of what’s going on. So, as a contributor, it sort of provides you guidance. Okay, I’ve done, like, the correct syntax or formatting if I’m submitting code or documentation. And one thing that I forgot to mention but
it is really important is healthy open source projects have not only a code of conduct, but also
an onboarding guide or a developer guide that helps new contributors get started and helps existing contributors build their skills.

Differences in

So, what differs? Well, there’s a fair amount of stuff that differs between CPython and other data science projects like Jupyter and Jupyter hub and binder that I’ve been involved with. And one of the most important or biggest ones is the velocity at which new features are added to the project. Pythons, a 30-year language, has a long history and a lot of code out in the wild that are being used in production, in scientific research. And as such, we can’t just go and change things as quickly as we could in a newer project because we have more embedded users. The other thing that’s different about core Python is it’s a language that’s used far beyond just data and science. So, not only do we have to satisfy the data and science community, but we also have communities around web development, sysadmin, DevOps, embedded systems, teaching, and so forth. So, when we look at Python, we’re looking at, okay, how do we keep stability and backward compatibility and security while adding new features? And in many of these other scientific projects, it’s a bit flipped. We’re looking for adding new features while also creating, you know, a stable, though often changing environment. We might deprecate things, which is stop using things or offering things in a two-year window where Python, it would be much longer, it could be five years, it could be ten years. And then the context in which these projects are used is also different. CPython is a tool that we use to build things. And it’s a tool that is used as a foundation for many of these projects like Jupyter or Matplotlib to create their own project. So, the stability of CPython is critical to the stability of our entire data and science ecosystem because what we don’t want to do when we make a new Python release is break a whole bunch of other projects. And so, yeah, so that should give you a sense of the fact that Python is going to move a little slower, really emphasize code and quality and security, whereas some of these scientific and data science projects are going to move much quicker. And you’ll see a lot of change in even a year or two years. So, how do you get started contributing? Or if you’re already contributing, how do you continue and perhaps grow your skills? Well, if you’re a first-time contributor to open source, I want to strongly encourage you to consider making your first contribution be a contribution to a project in the scientific data science community. And I’m going to go so far since it’s my opinionated talk to say I would encourage you to do that over making CPython your first contribution. And the reason why is you will find going back to the differences between the projects and Python language, the velocity of change is much higher in these projects like Scikit-learn. So, it actually winds up being a way to learn while doing and make an impact while you’re learning, which is much harder to do in CPython. And I highly encourage you to go watch both of these or read the transcripts. They’re excellent. So, as you get ready to contribute to CPython, and this would apply to most open source projects as well, you want to kind of get into a mindset that will set you up for success. And one of the first things you can do is sort of check your intent or really identify why you want to contribute. And the reason I say that is when things get bumpy along the way, it’s easier to persist in the process when you have clear goals of what you’re trying to accomplish and why. And I would encourage you to think about your initial impact and initial scope. Keep it small. It’s much easier to start small and then work up to big. And I want to also say that patience is probably one of the best things that you can have along with communication skills in open source. Most projects are run by volunteers. The vast majority of core developers for CPython are volunteers. All the stuff I do is as a volunteer on my time, notable gives me a lot more latitude than most companies to work on open source, but it’s not my primary job. And there’s less than a handful of folks within the core development team where it is their primary job. All right. So, you’ve got the right mindset. You’re setting yourself up for success. What are some of the common reasons that people contribute to open source? And these are just a few of many. You’re using a project, whether it’s a scientific Python project, and you hit a bug, and that bug possibly is related to something in CPython. So, you might want to fix something in CPython to make your other project run better. You might have come across something that perplexed you or was complicated to learn. So, you might want to improve the documentation so the next person doesn’t have to go through the same process. A lot of people just think it would be cool to contribute to Python, which is a totally valid reason. Many people want to just understand more about how things work and to strengthen their development skills. So, this is just a small subset, but some things that come up time and again. So, your most important resource when contributing to core Python is what we call the dev guide. And it’s located at devguidepython.org. It is a comprehensive guide to contributing to Python. And it’s maintained by the core developers that also maintain the language. It is pretty much everything you ever wanted to know about contributing to Python and then some. As such, there is a quick reference guide, which is really a great place to start. And we’ll talk about it in a little bit. But there’s also things about how to submit a pull request, how to get help, how to run tests, and many other resources. This is sort of your one stop, if you will, towards getting started. And many other projects have something similar, perhaps not as long. But, yeah. So, some other helpful prerequisites that will improve your contribution experience to see Python is to take a little time to understand see Python’s culture. And that can be – there’s different aspects of the culture. Because we have people that have been with the Python language for 30 years versus are relatively new in the last five years to core Python, you’re going to have people with different perspectives and different work styles within the language. Personally, I spend a lot of time looking at discourse, which is discussed.Python.org. And less time looking at mailing lists. Partially because I find more value in discourse than in the mailing list. But there’s a lot of core developers that do the reverse. And then I also spend a lot of time looking at the pull requests and the code itself. So, understanding the culture and where to find information and how the pace at which things happen is really important. Also, understanding the difference between the core language and the standard library. The core language is a smaller subset of what you would think of as core Python. And then the standard library is actually many other smaller libraries that provide additional functions that gave Python the batteries included name. And core Python – the core language is really things like data types and really the fundamentals that you would have in any software development language. Again, I can’t reiterate enough that core developers are volunteers and be kind. Many of us are wearing many different hats. On the flip side, the core developers should be kind to you as well. So, we do have a code of conduct. And, you know, I encourage you, if you’re seeing behavior that is not professional, please let folks know. Understanding Git and GitHub workflow is, I think, very important for contributing to core Python. At the point where people are contributing to core Python, the general assumption in the community is that you have basic Git and GitHub workflow experience and understanding. And if you jump back to where I said, oh, I’m encouraging you to also consider contributing to other data science and science libraries, partially it’s because those projects tend to be a little bit gentler with new contributors that are still learning Git and GitHub. And there’s lots of information out there about doing it. Software Carpentries have a great guide. And there’s a talk which maybe we can link to in the future. Unfortunately, it wasn’t recorded, but a slide deck that I put together, gosh, probably 2016 for complete beginners at write speak code who are learning Git and GitHub. And it really is a very gentle introduction to both but has been very popular. And then the other prerequisite is some familiarity of Python. It’s not necessary to know C. It’s not necessarily to know C++. So, most of the language is written in Python so you can be very effective without really understanding much, if at all, from C or C++. So, that’s a lot to digest. And I want to – for those of you that want a great exercise later or when you’re ready, I want to just give you the brief directions on how to build core Python from source. And people often think it’s a really super complicated process. And the quick reference guide in the dev guide actually runs through these steps. There may be some subtleties based on the operating system that you’re running. But essentially, what you’re going to do is fork and clone the source code from GitHub, which is that Python C Python. Then you’re going to use a C compiler and most of the time C compiler is kind of available with your operating system to configure and build Python. It’s one command to configure and build it with Unix, Linux, and Mac. Make is what will actually do the actual building. And then Windows, there’s a bat file that combines those same steps. So, to configure and build Python is one step. So, what would you want to do as you’re starting? Well, a good place is just to run the tests and again, like building and configuring Python, it’s one line of code. And there are – this should look pretty familiar with folks that have done Python. It’s just basically executing the test library. So, there you go. You have now learned how to build, configure, and run tests for Python. The dev guide will definitely give you additional questions and answers on how to contribute. Again, remember, changes to the language are submitted as GitHub pull requests. Our continuous integration will run the automated test just like you’re running them locally. It will run them in an automated way across all operating systems and a number of different versions of Python. The next step in the process, if you submit a PR, would be to wait for some review from a core developer or a contributor. Address the feedback as appropriate. And hopefully then you will have a final core developer review. And if luck will have it, it will be merged into the code base and folks can use it from then on. For those of you that want to go deeper in your understanding of CPython, there is a wonderful blog post which is now a book by Anthony Shaw. About a guide to CPython source code. It is the most accessible yet highly technical explanation of how CPython works, you know, down to the lowest levels. In fact, it was so good that when it first came out, I took the entire blog post, copied it all, had it bound in a spiral, you know, thing so that I could refer to it on a day-to-day basis. And I encouraged Anthony to write a book based on it and he did. So we’re very lucky that there’s many ways of accessing his materials. And he’s also a very prolific speaker. So there’s lots of stuff on YouTube as well. Another great resource for learning about Python. I don’t know if you can see me or if you’re just seeing my slides. But there is a book called High Performance Python by Misha Gorlek and Ian Osvold. And it is, I think, an outstanding book for both learning Python and how it is built and comes together. But also the things you can do to improve the performance of Python. One of the things you might hear in the media is Python is slow, Python, you know, isn’t performant because there is this global interpreter lock or Gil. And the global interpreter lock or Gil, what it does is it limits at certain points the processing to one thread, if you will, at a time. And that tends to be a bottleneck. Because right now we have many multi-core processors and things like that. You’d want to use all that and not have to bottleneck into things. But this high performance Python, it runs through things like how to profile your code, how to use multiprocessing, how to use Sython, which is a great project in our ecosystem in terms of – that allows us to do a lot of more CPU intensive stuff. I believe it also covers Numba, which is another great project that uses time compilation to get around the Gil. So, yeah, there’s lots of ways you can improve your performance. And these two resources are just some of the many that are out there. In addition to those resources, there are many core developers, keep websites that have a lot of technical content, Victor Stinner, Brett Cannon, and Guido, a lot of historical information from Guido as well. Much like the sprints that have been held for Scikit Learn, see Python typically runs sprints when we have in person conferences, which sadly 2020. But the hope is that there will be some being done virtually. And if anybody wants to run a CPython sprint, let me know. I’d be happy to kind of help guide you with that. Many of the Python – PyCon talks, both from PyCon US and beyond explain how to contribute to core Python. I think my PyCon talk from 2015 was how to contribute to core Python when you’re not a core developer. Marietta has given great talks about contributing both to the language and to the workflow, Victor Stinner. And for those of you that have any interest in asynchronous programming, Lukasz has a great series on YouTube about async.io. It’s about seven parts. And it’s a really great introduction. So we can always use help from folks that are interested in asynchronous. And this is just a small subset, maybe a third of the core developers. As volunteers, our time is limited. But the community is key. And it’s what lets Python, both as a language and ecosystem, thrive. So I want to encourage you to go forward and contribute. Join the discussion on discourse, which is discuss Python.org. And whether you’re contributing to Python or any of the projects in the ecosystem, you are creating real change and helping others solve important problems in the world. So I want to thank you for listening to me. And thank you to Rishama and the organizers. And I’m going to shut off my screen. This is already available on speaker deck. And it will be available through data umbrella as well. And I am happy to take any questions that might have come up. » Okay. So there’s a question about the slides. So I will find speaker deck for that. » It’s on speaker deck. » Okay. So the next question is, is the need to reproduce old bugs against the newest version of 3.9 a need of the project? » Depends on how old the bug is. If the bug is like within two years old, I’d say, yeah, it’s probably useful to reproduce those. If in general my view, and it’s strictly my view, it’s not an official view in any way or shape or form, personally, I would close the vast majority of issues that are over, let’s say, three years old. And because they’re still accessible to people to find if needed, but the likelihood of them being worked on, I think, is fairly low. We are going to move the issue tracker to GitHub. There is work in process to do so. And that should make the whole process more streamlined. And it will let us do some things with notebooks and some of the tools that we have in our ecosystem to help surface issues that haven’t been looked at to help recognize contributors. There’s many different things we can do with the data that is available within the repo. Hopefully that answers the question. » Okay. The next question is, GIL is a problem, but the advice I’ve seen is avoid be limited to one core is to use multiprocessing over threads. » Okay. So there’s a lot of different perspectives. And the GIL or GIL, which is the global interpreter lock, there are different ways of getting performance that gets around the limitations of the global interpreter lock. Multiprocessing is a great way. I would say threads would not be my first choice in how to do that. But things like Sython, Numba, depending on the use case, asyncio. But, yeah, it’s a great question. And the resources that I mention, particularly high performance Python, will give you excellent advice on how to get the most out of your deployments in a safe and efficient way. » Okay. And the next question is, what is the best way to attract a mentor from the core team? Does the project have a formal process for being mentored? » So there is a core mentorship mailing list which used to be more active. Right now, mentors, you know, because we’re all volunteers, people mentor as they’re able to. I typically, my mentoring is basically being welcoming and answering questions that people directly ask me. I just don’t have the time and bandwidth to mentor individuals. But one of the things that we do have is the triage team. So if you’ve been involved for a while, somebody may ask you, hey, do you want to join the triage team? And the triage team, you know, has some additional capabilities that can do things like make comments or attach labels to different issues. And that’s really a great way that recently folks have found mentors as a result of the work that they were doing within triage. And then Victor Stinner has been really great at mentoring folks as well as Barry, Raymond Henniger. There’s a lot of people that do Eric Snow, Pablo Salgado, who’s our release manager for 310 and 311 have also mentored folks. And Victor’s got a lot of writing on it. So hopefully that helps. And feel free to reach out to me directly. And I can probably provide additional resource. » What’s the best way to reach you, Carol? » Reshma knows this. I stink at email. GitHub is really the best way to @mention me on something. But, you know, my DMs are open on Twitter. And, you know, I will get to it when I can get to it. It’s not that I don’t want to respond. But the volume of stuff that comes in is I could spend my whole day doing email and nothing else. So, you know, I tell folks that I meet, you know, be persistent if you don’t hear from me once or twice. Do not hesitate to email me a third time. And I will do my best to answer. » The next question is from your viewpoint, what does the future hold for Python for instance for the next 30 years? » Wow. That’s 30 years. I hope that Python is as vibrant today as 30 years from now as it is today. I think in many ways, you know, the whole data science, scientific Python ecosystem has been one way that has really revitalized the language over the last five years. Another place that we’re seeing a lot of growth is in embedded systems, things like micro Python and circuit Python. And, you know, that’s really exciting to me from an open hardware and education standpoint and getting young folks or folks that maybe aren’t computer scientists to start with involved. I would love to see us improve the performance of the language. And what that will look like, I’m not entirely certain. There’s definitely going to be efforts over the next five years to do that. Some of it is time, some of it is funding. But I – the one thing I hope stays the same 30 years from now is the readability of the language. And I think because Python is so readable, that actually makes it much more accessible for folks as well as tools like the notebook kind of break down and provide a good education tool for learning more about Python. So the community is going to be the one that drives where Python goes. And truth be told, there’s another language that I also find really interesting that probably is relevant to many members in this community, and that is Julia. It’s still a very young language, but I think it has a lot of potential and promise. And it’s very similar to Python in a lot of ways, but gets around issues like the gil and relies more on C, C++. And should you ever want to compare Julia code with Python code, Tom Sargent’s quant econ website is excellent for doing that because even if you’re not an economics person, it has economics code written in Python and similar economics code written in Julia and it’s a good compare and contrast when you’re learning. So I don’t know. That’s about all I can say for the future. » There’s been a lot of discussion I see going on because O’Reilly published a report too about Python. And I guess speed is the thing that’s most under discussion, right? » It’s interesting because oftentimes, and this has been historically, I’m 54, I’ve been in this industry a long time. Speed has always been at the key. Is this faster than the other? Is VIM faster than Emacs? Speed is relative. And it depends on what you’re measuring. I would say one of the things that is not often discussed and really should be is the speed to create a project. And Python is a really efficient language for going from no code to prototype to production. And there’s a value in that beyond just pure processing power. And now, that said, there are certain things that if you’re CPU bound, like high CPU operations versus I/O operations, and web is going to be different than pure number crunching, your performance is going to vary. And one of the things I think that would be really useful is to try out, like profile your code, look at the other tools for increasing the speed. There’s tradeoffs regardless of what language you use. And I encourage you to try other languages as well. » There’s another question about, you mentioned the global reach of the tech community. Aside from events like this, what is the role of the Python steering committee in making the community more inclusive? » So, the steering council has been a part of some of the code of conduct decisions and discussions related to core developers. And we have this year taken some actions to redirect or remove folks that were probably not contributing constructively to the community. So, you know, adopting the code of conduct throughout the project was one way. The steering council also looks at efforts, whether it is the core language summit or the core developer sprints. Those used to be exclusive to only core developers. And in more recent years, we’ve invited more people to it that to both increase the diversity on a number of dimensions as well as just even use cases. My hope has long been that diversity will benefit from the move to GitHub. I was an early proponent of moving the code base to GitHub and have been a strong advocate for moving the bug tracker to GitHub or it could have been GitLab. But something where the tooling is modern and is more accessible to more people. Because one of the things I personally feel when you’re an underrepresented group, your time is more limited than if you are in the majority. So, you have to pick and choose what you work on much more carefully. And by having a roadblock, like having to learn an issue tracker versus using tooling that you’re used to from your day-to-day work, I think that adds a barrier to inclusion. So, yeah. So, it’s really trying to shift the culture towards more inclusive culture and more inclusive. And I think that’s a really good question. And I think that’s a really good question. And I think that’s a really good question. And I think that’s a really good question. And I think that’s a really good question. And I think that’s a really good question. And I think that’s a really good question. And I think that’s a really good question. Because, you know, Python software foundation is also connected to improving inclusivity in the Python space. Yes. Yes. That’s a great suggestion or comment. Because we also have within PyLadies, there’s the ability to ask questions. Just like with our ladies, there’s an ability to ask questions on core development within those channels. Another question here is, what will be the impact of the new PEG parser in future Python tools and libraries? And maybe you could explain what PEG means to someone like me who doesn’t know. So, we affectionately call it the PEG parser. And when you’re creating a language, you have a grammar. You know, your syntax. And the language has to have a way to sort of know, okay, this is a key word. This is a variable. This is an operation. Things like that. And that is the job of the parser. I believe that the PEG parser will give us more flexibility over time. It is probably equally as performant as the prior parser. And there was a lot of extensive testing done during an entire release cycle to make sure that, you know, it wasn’t introducing weird regressions and things like that. But one of the things, it is much easier to write grammar rules now with the PEG parser than it was with the old parser that we have. So, hopefully that answered a little bit what it is and why it is. And someone who can provide far more answers than I would be Pablo Salgado and do reach out to him. He’s probably got some talks on the PEG parser as well. » And one last question, which is, I heard a talk that is a twist on the speed demand. Instead of focusing developer time expertise on optimizing to a capital O of 1, go with N squared performance because developer time is more expensive than RAM is. What are your thoughts on that? » I think it really comes back to use cases. And I think the difficulty with Python is because we serve so many different communities, what is optimal for one community may not be optimal for other communities. So, you know, it’s an approach. Is it the approach? I don’t know. To be really honest. It wouldn’t be my first approach, I guess is what I’m saying. » So, with that, we are reaching the top of the hour. And so, thank you so much, Carol, for taking the time to join us and sharing about core Python. I have a link to the slides. I put them in the chat. And I’ll include them in the video when it’s uploaded to YouTube. And there’s a bunch of links that you’ve mentioned, which I’ve been putting in chat. And I will link to it in the YouTube description or somewhere very convenient. Thank you so much. » Great. Thank you. And thank you, everybody, for attending. I hope you learned something about contributing to open source. And I hope you do so as you’re ready to do it. » Thank you.