Python (2016)
CHAPTER 1: Python’s History
Many Python fans say that Python has quite a lot in common with the alphabet—most commonly the fact that both start with ABC. Of course, in programming terms, ABD refers to a general-purpose programming environment and programming language, first developed in the Netherlands. The language was born at the Centrum Wiskunde & Informatica (CWI). And while rarely talked-about today, it has as one of its greatest achievements the merit of influencing Python’s design.
Python was first conceptualized by Guido van Rossum, back in the late 1980s. At this time, van Rossum was working at a CWI project called “Amoeba” -- this was supposed to be a distributed operating system. He also worked on the ABC language, and he used everything learned in this project to come up with Python.
Part of Python’s design grew with van Rossum’s frustrations with ABC. Like any good innovator, he decided that he wanted a product with the same set of strengths, but without any of ABC’s weaknesses. The first product of this endeavor was a simple set of virtual machine, parser, and runtime. Van Rossum adapted the parts he liked about ABC, creating syntax and data types such as a hash table, strings a list, and numbers along the way.
Rather than making a language with everything built into the core, Python was meant to be a highly extensible language. It can also be embedded into existing apps that are in need of a programmable interface.
What’s in the name?
As the project developed, its creator knew it had to have a name. Most people nowadays believe that the name was derived from the world of snakes (as shown in the Python logo). However, the name was actually derived from the famous British television sketch comedy program, Monty Python’s Flying Circus.
At the risk of upsetting theorists, there is no real deep meaning to the name (as van Rossum himself wrote in 1996). Apparently the name sprang forth during a particularly irreverent mood as he looked for a name to describe his Christmas week project. He also wanted a name that would appeal to the subset of Unix/C hackers. And of course, he was also a fan of the said comedy.
The Python philosophy has been summarized in the neologism “pythonic”—a word that can have many meanings related to this programming style. A pythonic code is essentially something that uses the Python idioms well, and that shows minimalism and fluency. It is also something that emphasizes readability. An “unpythonic” code, on the other hand, is something that is difficult to understand or something that seems to be a rough translation from another language.
Admirers, users, and adherents to the Python philosophy are hence called “Pythonists”, “Pythoneers”, or “Pythonistas”.
The Python Philosophy
There is a set of rules that describe the Python philosophy, which has since then been known as “The Zen of Python”. This was documented late into Python’s lifespan (in 2004) by a programmer named Tim Peters. This set of 19 aphorisms aptly describe the way Pythons works as a programming language, and has been initially created as an entry (the 20th) in the Python Enhancement Proposals. Any person into Python programming can access this—the Zen appears as an Easter egg when entering “import this” into the interpreter.
Below are the 19 aphorisms:
1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.
7. Readability counts.
8. Special cases aren’t enough to break the rules.
9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one—and preferable only one—obvious way to do it.
14. Although that way may not be obvious at first unless you’re Dutch.
15. Now is better than never.
16. Although never is often better than right now.
17. If the implementation is hard to explain, it’s a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
19. Namespaces are one honking great idea—let’s do more of those!
This philosophy puts Python and fellow programming language Perl “at odds” with each other, as the latter steers clear of the sparse and uncluttered grammar implemented by the former. Perl explicitly aspires for the “there is more than one way to do it” philosophy, which Python users claim invite unnecessary confusion into the coding.
Part of the Python philosophy is the dislike for premature optimization. Python’s developers reject patches to the non-critical parts of the language if it means the marginal increase in speed is offset by the loss of clarity. When speed is desired, a programmer can instead move the time-critical functions to different extension modules written in other languages (like C). There is also a “just in time” compiler (PyPy) available.
And of course, there is another goal that Python’s developers have is to make the language as fun to use as possible. This is also reflected in how the language was named. Even tutorial and reference materials are approached with a playful outlook. For example, some exercises refer to Monty Python-inspired spam and eggs instead of the standard foo and bar.
Python’s Development
The first version of the Python code was published at alt.sources (version 0.9.0 was its number) back in February of 1991. This was quite remarkable as a first release since it already handled exception handling, some core data types, and functions. It had a module system, and was object-oriented.
In January of 1994, Python's version 1.0 was released. This included some major improvements such as new functional programming tools map, filter, reduce, and lambda. After six and a half years, in October 2000, Python 2.0 was born, which in turn included a full garbage collector and new list comprehensions. The new release was also supporting Unicode.
In the next 8 years that followed, Python version 2.x grew leaps and bounds in popularity. Each of these releases was backwards compatible with the previous Python release. This continued until the introduction of Python 3.0 (also known as Python 3000 or Py3k). Aside from not being backwards compatible, Py3k emphasized removing duplicate programming modules and constructs. This is in fulfillment (or, at least, close fulfillment) of the 13th Zen—“There should be one—and preferably only one—obvious way to do it”.
Here are some of the prominent changes in Py3k:
n Print has now been turned into a function.
n The system now uses views and iterators instead of lists.
n The rules for ordering the comparisons are simplified. For example, a heterogeneous list may not be sorted, since all the elements of the list should be comparable to each other.
n There is just a single integer type left.
n When two integers are divided, a float is returned instead of an integer. However, one can use “//” to have the old behavior.
n Instead of Unicode vs. 8-Bit, there is now a difference between Text vs. Data
The development process throughout all these years is conducted through the PEP or Python Enhancement Proposal process. This is a mechanism that the developers use to propose for new features, as well as for collecting community input on any issues. This is also used to document the design decisions that have been built into Python. Any outstanding PEPs are in turn reviews, commented upon, and subsequently worked on by the community and by van Rossum himself (Python’s Benevolent Dictator For Life).
The language enhancement goes along with CPython development and its reference implementation. The “python-dev” mailing list is considered the primary forum for discussion about development. Any specific issues are to be discussed in a “roundup bug tracker” that is maintained at the project’s website (python.org). There is also development taking place on a self-hosted repository of source code, which runs Mercurial (a distributed revision control tool).
There are three types of public releases from CPython, distinguished by the part of the version number which is incremented. First are the backward-incompatible versions which happen when the code is expected to break (hence demanding manual porting). Here, the first part of the version number will be incremented. These releases are fairly infrequent. Version 3.0, for example, was released a full 8 years after the preceding version.
The next one is categorized as “feature” or “major” releases. These are largely compatible, even though they introduce new features. The second part of its version number will then be implemented. These are scheduled to go out about every 18 months, and are then supported by bugfixes for the next several years after its release.
Lastly, there are the bugfix releases, which do not have any new features. However, they fix known bugs, providing more stability to the users. In this release, the last part of the version number is instead incremented. The releases are made when there is enough number of bugs fixed upstream ever since the last release (coinciding with roughly every quarter). Any security vulnerability will also be patched in a bugfix release.
There are also some alpha, beta, and release-candidates that are sent out as previews for testing before a final release is announced. There is, however, a rough schedule that is followed for the releases, even though this can be pushed back if an issue renders the code not ready. The developers will monitor the code’s state by running large-scale tests during development. This is usually done through the BuildBot continuous integration tool which helps in automating the compile/test cycles needed to validate any change to Python’s code base.
As of January 2016, the Python development community has contributed more than 72,000 software modules to the PyPI, the Python Package Index. This is the official repository of third-party Python libraries. Major academic conferences are also held, such as PyCon (currently the largest of its kind). There are also mentoring programs available, like Pyladies, which is an international mentorship group meant for women who desire to actively contribute to the Python development community.
Development Environments and Implementations
Most of the Python implementations, like CPython, function as command line interpreters for which users enter statements in sequence. In return, results are immediately shown. Basically, Python acts as a shell.
To add capabilities, other shells beyond those provided by the basic interpreter may be used. These include IDLE and IPython. While following the Python shell’s visual style, they also implement other features such as auto-completion, session state retention, and syntax highlighting. There are also other standard Python IDEs for the desktop, just as well as there are IDEs for the browser. Other options include Sage (meant for creating math and science-related Python programs) and PythonAnywhere (a browser-based Integrated Development Environment which doubles as a hosting environment.
Python Implementations
CPython, which is the main Python implementation, meets the C89 standard and is written in C. It is used to compile the Python programs to intermediate bytecode, which can then be executed by a virtual machine. It has a large standard library written both in C and Python. It is also available for multiple platforms including Microsoft Windows (XP support had been dropped, however) and most Unix-like systems. This proves the cross-platform philosophy that was present since Python’s inception.
As previously mentioned, there is also PyPy, an interpreter for Python 2.7 and 3.2 which has gained reputation for speed (over CPython) and compliance. There is also a version in the pipelines that aims to increase speed by using software transactional memory to take advantage of multi-core processors.
Stackless Python is another implementation, coming as a significant port of CPython. It does not utilize the C memory stack, instead implementing microthreads. This allows hugely concurrent programs. It is to be noted that PyPy also comes in a stackless version.
Aside from these, there are other just-in-time compilers that have since fallen into hard times (i.e., lack of developmental support). One comes from software giant Google, which launched the Unladen Swallow project back in 2009. This had the original aim of increasing the speed of the interpreter by at least 5 times through the LLVM (Low Level Virtual Machine) infrastructure. This improves the ability to multi-thread, allowing scaling for up to thousands of cores.
There is also the “specialising just in time compiler” called Psyco, which integrates with CPython. This transforms the bytecode into machine code at the runtime. This produces a code that is specialized for specific data types which can also run faster than standard Python codes.
Google is far from being the only big name to dabble in Python compilations. Back in 2005, mobile phone company Nokia also released its own Python interpreter for its Series 60 mobile phones. This was called Psy60, which included a lot of the modules from CPython along with added modules for Symbian OS integration. This project, unlike the Google counterpart, has been kept mostly up to date with many third-party modules available. The Nokia N900 even supports the language with its GTK widget libraries, allowing programs to be written and run on the phone itself.
There are also different compilers available to high-level object languages using as its source language unrestricted Python, its restricted subset, or a language similar to it. Examples are:
n Jython, which compiles the language into Java byte code. This can then be executed by any implementation of the Java virtual machine. This will also enable the use of Java library functions from the program in Python.
n IronPython, which follows an approach similar to Jython except that it runs programs on the .NET CLR (Common Language Runtime).
n RPython, which can be compiled into Java bytecode, C, or Common Intermediate Language. It is also used to build the PyPy interpreter.
n Pyjamas, which is used to compile into JavaScript.
n Shed Skin, which can be used to compile to C++.
n Pyrex and Cython, which can be used to compile to C.
Discussion on different Python implementations can be very lengthy, and we will be reserving that as the final chapter of this book.