Python is a dynamic interpreted language that has gained a lot of traction in the past 12 years, even though it is actually 26 years old. It is a general purpose language fit for different kinds of tasks, not a one-trick web pony like PHP was. And it is the 4th most mentioned language by the TIOBE index today ( up two points since last summer ).
Python is used for system administration, testing automation, GUIs, game scripting, web development, and data science. And the secret to its popularity is its philosophy. When we ask others, “Why did you chose Python for this job?” …. the most common answer we hear is “because of its rich ecosystem.” Indeed, Python is famous for its ease of installation and diversity of third-party packages in addition to its “batteries included” approach. From database abstraction layer or API to some rarely used payment gateway — “there’s an app for that!”
Perl has a rich ecosystem that includes a renown CPAN libary. However, it is on the demise. Startups do not use it, and companies that have built their systems in Perl often have trouble finding new developers.
There’s always something that propels a language community to grow, and Python seems to have that X-Factor. One of the keys to its success is Python’s approach and understanding that computers just execute — people build. Programs are compiled by computers, but people need to understand and interpret the intentions of the program’s author.
The Zen of Python is readily available in any Python interpreter by invoking the “import this” command. Here are the principles:
- Beautiful is better than ugly
- Explicit is better than implicit
- Simple is better than complex
- Readability counts
- There should be one — and preferably only one –obvious way to do it
- If the implementation is hard to explain, it’s a bad idea
- If the implementation is easy to explain, it may be a good idea
In sharp contrast, Perl’s motto is “There is more than one way to do it.” This approach helped to build Perl’s reputation as a language which is fun to use, albeit hellish to maintain later.
These Zen of Python principles were adopted by core language designers in addition to ordinary Python programmers. And this was the key to building a rapidly expanding community in diverse areas of computing that welcomed newcomers.
Evolution
The needs and requirements that users have of a software language change over time. It’s not surprising to find language designers discovering new approaches and solutions to old problems. Unfortunately, some design decisions turn out to be sub-optimal. This process is analogous to constructing roads.
Some roads grow in popularity, but they are not wide enough to accommodate everyone’s needs. Eventually, these roads must be replaced by modern highways. Other roads become narrow and obstructed which results in low usage. In either case, a new taxi driver to this city must learn how to navigate this diverse terrain.
Over time, the burden of legacy systems grows heavier. And once in a while, similar to snakes shedding their skin, rarely used features are shed for the sake of keeping the system clean and consistent. Backwards compatibility is important, but certain changes are often justified because they fix initial design decisions that turned out to be problematic. Applications do it, frameworks do it, and programming languages do it too.
The current version of Python is 3.5 which indicates that this language had two major jumps in its history. In the year 2000, version 2.0 came out which added the Unicode string type in addition to the 8-bit string type as well as many standard library cleanups. Version 3.0, approved eight years later, dropped support for implicit 8-bit strings while requiring the user to explicitly convert bytes they were receiving into Unicode strings. And this exposed many bugs in programs that were, in 2008, still unaware of non-ANSI characters.
The 3.0 version turned out to be much rougher than the 2.0 one. The language was already growing in popularity in 2008. Developers decided that it was better to do the fix now rather than later, and an influx of newcomers will help the community to migrate to version 3. Although the expectations for growth were met, the expectations for easy adoption were not.
For several years, the Python 3 ecosystem became stuck with major third-party packages being incompatible. Basic questions like, “So how do I connect to Postgres?” started to occur. And since Python 3 did not have an adequate answer, people grinded their teeth and went back to Python 2 because it had “a package for that.”
Fortunately, this has all been resolved now. The vast majority of major third party packages and frameworks currently support Python 3 and changes in deployment and software building best practices have made it easy to deploy services built with different language versions.
In contrast, the Python 2 support drop is scheduled for the year 2020, and no improvements have been made for the past 5 years. ( However, Red Hat will probably support it along with many other legacy software for another decade. )
If your project is not “legacy software” but is instead an evolving product, it makes sense to invest in Python 3 compatibility now. The first step in migration is a good test suite. The next step is replacing obsolete tricks with new common best practices while keeping your Python 2 project running.
New packages are now more often created in Python 3, with a compatibility layer for Python 2 added later, rather than in opposite direction. New projects are started in Python 3 or are choosing version 3 when migrating to Python, like Patreon did. New micro-services are commonly developed in Python 3. Most CS courses are now teaching students Python 3.
A software development company leveraging Python 3 has the following benefits:
- Less errors due to a cleaner language
- Better tooling and type hinting
- Future-proofing
- Long list of new features developed in the last 8 years ( ie: async support )
- Developer credit which makes it easier to find new people and keep them happy
And happiness goes hand-in-hand with productivity.
