The proposal by Python Core Developer Lukasz Langa suggests updating Python every 12 months, but making releases smaller with fewer features to compensate.
Codementor lists the struggling languages that may not be worth your time.
Python developers could get their hands on new features and bug fixes more frequently under a proposed change to programming language’s update cycle.
At present, a new version of Python is released every 18 months, most recently version 3.7, which added new debugging and type annotation features to the language.
Now there is a proposal by Python Core Developer Lukasz Langa to update Python every 12 months, but to make releases smaller with fewer features to compensate.
In the proposal, PEP 602, Langa argues the change “puts features and bug fixes in hands of users sooner”, and “creates a more gradual upgrade path for users, by decreasing the surface of change in any single release”.
“This change does not accelerate the velocity of development,” he points out.
“Python is not going to become incompatible faster or accrue new features faster. It’s just that features are going to be released more gradually as they are developed.”
He suggests that bundling fewer features with each release would also reduce the risk of new features “being accidentally incompatible, which makes the upgrade cost relatively high every time”.
Developers working on new Python releases would also benefit, he argues, as it would reduce the urge to rush new features into the latest release to avoid them slipping for 18 months.
The period during which new versions of Python receive security updates also would not change, with each release still receiving five years of security patches.
“Consequently, while this change introduces the ability for users to upgrade much faster, it does not require them to do so. Say, if they upgrade every second release, their experience with Python is going to be very similar to the current situation,” says Langa.
The period during which releases would receive full bug fixes would be reduced, however, down to one year after release, to allow the Python Core Developers to put out new releases more frequently without “increasing the biggest maintenance cost”.
Under the proposal, around 17 months would be spent working on each release, including a pre-release period of five months that would overlap with the development of previous release, followed by a seven-month period working on the alpha release, a four-month period on the beta release, and a final month working on the release candidate.
Each release would be issued in October, which Langa says would help Python Core Developers to fit work around busy periods throughout the year.
Elements of the proposal have been challenged by some other Python Core Developers, with Antoine Pitrou concerned it would add to the workload for teams packaging releases for Windows and macOS, asking for more evidence that a 12-month release cycle is the perfect “sweet spot”, and expressing doubt that releasing fewer features would meaningfully improve compatibility with earlier releases.
“I have no personal disagreement with the proposal of switching to a 12-month release cycle, but I also don’t find the overall argumentation very convincing,” he says.
Langa responds that he doesn’t believe the Python packaging teams have said the change would impact on their workload and points out that Python creator Guido van Rossum is on record as saying “a somewhat faster release cycle would be good for us”.
Millions of developers use Python each day, and there’s little sign of the exponential growth in users tailing off, with Python used extensively, for everything from web development to data science.
For more on Python in the enterprise, check out “How to write four million lines of Python: Lessons from Dropbox on using the programming language at scale” and “Python is eating the world: How one developer’s side project became the hottest programming language on the planet” on TechRepublic.