Python's best times may be yet to come. The language is broadly popular and widely deployed, and it's a staple presence in many fields enjoying explosive growth, such as machine learning.
What lies ahead, apart from version 3.6 of the language debuting later this month? Here are four possible developments for Python in the months and years to come.
1. Python 2.x may live on
The 2.x branch of Python is scheduled to stop receiving updates in 2020, with Python 3 slated as the long-term future of the language. That hasn't stopped a great many people (and organizations) from sticking with Python 2.x, especially since lots of software is still 2.x-only or backward compatible.
Python 2.x might also get a continued lease on life if independent developers decide to keep the branch going on their own. At least one such effort exists -- Naftali Harris's "Python 2.8" project, which backports improvements and bug fixes from Python 3 into the Python 2.x branch.
In the longest run, it makes sense to make the 3.x leap, but it's likely we'll see a lot of keep-the-2.x-flame-alive efforts like this in the years to come.
2. Requirements.txt may be replaced with something better
Python packages installed with the pip package manager list their external dependencies in a file called requirements.txt. It does the job, but nothing more, and there's plenty of room for improvement.
Pipfile has been proposed as a possible replacement by the folks at the Python Packaging Authority, which is "the working group that maintains many of the relevant projects in Python packaging." Pipfiles allow far more specific dependencies to be described with a Python package and in a syntax that's consistent with the rest of Python. Dependencies can be specified separately for release and development versions of a package, making it easier to reproduce the exact conditions needed to install a package. It's a work in progress right now, but the basic idea seems clear.
But Pipfile potentially is overkill; in many cases, you may want simply to list requirements and be done with it. If Pipfile comes in side by side with requirements.txt and eclipses it gradually -- and if we get tools for automatically generating one from the other -- it'll be even less of a problem.
3. Python could get more enterprise editions
Python's default version is where most people start. As the language has gained traction across the board, it's also appearing in versions aimed specifically at solving enterprise-grade problems.
A common example is the long-standing enterprise version of Python produced by ActiveState. But the trend is not only for other enterprise-friendly versions; it's toward versions that specifically complement data science in the enterprise. Intel, for instance, elected to repackage the Anaconda science-and-math distribution of Python after outfitting it with extensions that give it a speed boost, albeit only on Intel processors. Anaconda is itself produced by Continuum Analytics, no stranger to enterprise data-analysis needs.
At first this seems narrow, as not everyone does data science with Python. But other the performance enhancements created in such distributions are likely to trickle down to the rest of the world. The Numba project, for instance -- another Continuum Analytics co-creation -- can provide a performance boost to any Python project, regardless of what distribution is in use.
4. Python's new software repository system could lead to enterprise-friendly Python package management
Python package management has come a long way, but little of it reflects the in-house needs at enterprises. One possibility being floated in this vein is the concept of an enterprise-grade package index for Python, as discussed by Cristian Medina of Nimble Storage:
Businesses always have a need for an on-premises, secure, encrypted and highly available distribution mechanism of compiled binaries. Together with setuptools providing various install capabilities that can cover non-Python code just as well, it seems like we could put together a decent product. Something like a Docker Trusted Registry.
Work is already well underway for a potential starting point for just such a project: the next-generation replacement for the Python Package Index, Warehouse. It runs in a Docker container by default and is already suited to modern enterprise deployment -- although the more high-end stuff Medina muses about would still need to be added by an enterprise willing do the heavy lifting. Any takers?