Where will Python be in 100 years? It’s a question that MIT-based AI researcher Lex Fridman posed to Python’s creator, Guido van Rossum, near the end of a three-hour interview.
This is just one of the ways they explored the evolution of a popular programming language, as well as specific questions about Python’s future. How will they improve Python’s standard library? Will Python ever see a static type checker? What are the prospects for improving Python’s global interpreter lock that slows performance? And what steps would they take to avoid another painful change like the transition to Python 3…?
But along the way, Fridman also posed van Rossum’s most hypothetical question about the role of language in the distant future a century later. “Have you ever imagined a future of human civilization – we live inside the metaverse, on Mars, humans and robots everywhere.
“What role does Python play in this? »
The year 2122
Python has been around for over 30 years, so van Rossum has already seen the ebb and flow of popular programming languages. So, in response to Fridman’s question, van Rossum replied that given enough decades, the immensely popular Python “will eventually become a legacy language – which plays an important role, but which most people have never heard of talk and don’t”. need To know.” While people can build on it, Python would be buried somewhere lower, in this hypothetical world with many layers of abstractions – continuing our continuous progression. “I mean, most programmers these days have rarely need to do binary arithmetic, do you?”
The meta message seems to be that van Rossum remains confident in the language’s enduring appeal – and here in the present, van Rossum says he’s not actively monitoring gaps that need to be filled in Python’s standard library. “Usually, when something is missing from the standard library these days, it’s a relatively new idea, and there’s a third-party implementation – or maybe several third-party implementations. But they’re evolving at a much faster rate than they could when they’re in the standard library…I like that there’s a vibrant package ecosystem.
Now that he has stepped down from his role as “benevolent dictator for life” – handing over control of the language in 2019 to a Python steering council – van Rossum still sees continuity in the clarity of Python’s vision for the future. The advantage of the old hierarchy was its predictability – Guido charting “a clear and fairly straight path”.
“Fortunately, the successor structure with the board of directors has found a similar way to steer the community in a fairly stable direction without stagnating.”
“And for me personally, it’s more fun, because there are things I can just ignore!” ‘Oh, there’s a bug in multiprocessing? Let someone else decide if it is important to solve this problem or not! I’ll stick with asynchronous input and I/O and the fastest interpreter.
Revisit 1991
Van Rossum is now part of a team at Microsoft working to speed up language performance. And in October, a blog post from Microsoft indicated that Python 3.11 had brought 10-60% speedups to parts of the language. When asked how this was achieved, van Rossum felt that they had fixed design decisions that go back to the origins of Python. In the search for ways to speed up Python, the “low hanging fruit” was the interpreter, on which they had focused almost all their efforts.
An example? Something as simple as a plus sign has multiple meanings, with entirely different “add” functions depending on the type of data being added. Was it an ordinary integer or a floating point number (with extra digits after the decimal point) — or was it a string? Or was it a combination of different Data types? “We know statistically that the result is almost always yes, they’re both integers,” van Rossum explains, “so we quickly do that check and then we do the Add Integer operation.
“And then there’s a fallback mechanism where we say, ‘Oops, one of them wasn’t an integer…'”
It all boils down to something fundamental about the language: that Python doesn’t require its programmers to declare the type of a variable. This makes life easier for programmers – but it introduces a quick inefficiency into the interpreter. “So we’re trying to make the interpretation more efficient without losing the super-dynamic nature of the language. That’s always the challenge.
But what about the possibility of a Python that instead only offered static typing – with variable types declared in code, to speed up performance. Fridman pointed van Rossum to mypy, Python’s experimental (and optional) static type checker, asking “where is mypy now – and what is the future of static typing in Python?”
“It’s always controversial,” van Rossum says. “But it’s much more accepted than when mypy and Python Enhance Proposal #484 were young….” aspect of it…” (Fridman cited estimates that today 20-30% of Python 3 codebases now use type hints.)
And van Rossum noted that Google, Facebook, and Microsoft have since each developed their own static type checker for Python, which speaks to the interest in it. “My guess is that many, many people developing Python software professionally, for some type of production situation, use a static type checker. Especially anyone who has a continuous integration cycle – probably, one of steps in their test routine that happens for pretty much every commit is “Run a static type checker”…so I think that’s a pretty popular topic.
So, will there be a future where a static type checker is built into the language, Fridman asks. “No one is currently enthusiastic about working in this direction,” replies van Rossum, before adding “That does not mean that in five or 10 years the situation will not be different.”
But he also points out that since new versions of Python only come once a year, type checkers “evolve at a much faster rate than Python and its annotation syntax.”
van Rossum also points out that once you introduce a new feature in a language, you have to assume that people are using this. Which means: “Once we all agree that we’re going to put in a new syntax, we can never take it back.” At least deprecating an existing feature requires many releases…”
More possible futures
The conversation turned to Python’s infamous Global Interpreter Lock, which prevents “race conditions” by allowing only one thread at a time in the interpreter. For this reason, it is often criticized for slowing Python performance. (It’s a design decision that van Rossum traces back to when multi-core processors were rare).
When asked if there are any ideas for removing it from Python – perhaps replacing it with several sub-interpreters – van Rossum replies “Yeah, there are a few possible futures there. The future the more likely is that we’ll have multiple sub-interpreters – each running a completely independent Python program, but there’s still an advantage to faster communication between these programs…”
But it does open up the possibility of these dreaded concurrency bugs catching programmers by surprise – what van Rossum calls “the downfall of the multithreaded programming model.”
And here van Rossum reiterated his position that “concurrency bugs are just harder… It would be nice if Python didn’t have a global interpreter lock, and it had what’s called free threading – but it would also cause a lot more software bugs.”
And yet “There is still a possible future where we actually go, or where we could at least experience this.” He notes Facebook’s CPython fork with an improved interpreter that eliminates the lock entirely (along with other optimizations). “The single-threaded case doesn’t run too slowly, and the multi-threaded cases will actually use all the cores you have. So that would be an interesting possibility – if we, as core Python developers, were ready , to maintain this code indefinitely, and if we’re willing to bear the extra interpreter complexity and extra overhead for the single-threaded case.
But that also might not happen. “Personally, I’m not convinced that there are enough people who need the speed of multiple threads with their Python programs to make it worth taking that hit in performance and that hit in complexity. And I think the Global Interpreter Lock is a nice “Goldilocks” point between no threads and all threads all the time. But not everyone agrees on that. so that’s definitely a possible future.
And meanwhile, “Sub-interpreters seem like a pretty safe bet for Python 3.12, so let’s say a year from now.”
When Python 2 became Python 3
Thinking back to the history of Python, Fridman recalled Python’s long transition to Python 3 (which was not backwards compatible with Python 2). Fridman asked if such a breakup would ever happen again – and immediately van Rossum pointed out that even hypothetically, “if there is going to be one, we’ll plan the transition very differently – because clearly we underestimated the pain that the transition caused our users in the case of Python 3. And if we had known, we could have designed Python 3 a little differently, without making it worse. We just thought we had a good plan. But we underestimated where – what users were capable of when it comes to this type of transition….
“If we’re going to have a Python 4, we’re going to have to have both a different reason for having it – and a different process to handle the transition!”
#Guido #van #Rossum #Types #Speed #Future #Python