How the development of a programming language is influenced by its environment: the example of Python

13 May 2019
All programming languages are constrained by the environment in which they develop. In this article, Jérémie uses Python as an example to illustrate the concept.

The TIOBE index is the reference standard for ranking programming languages. It measures popularity based on the number of pages returned by a search engine when the name of the language is entered. This measure rewards the best progress. TIOBE again nominated Python as the programming language of 2018, following its previous nominations in 2010 and 2007. In March 2019, Python came third (behind Java and C). This Technical News article will therefore be based on this language.

A “portable” and “interpreted” language

In theory, a raw Python script will run on any implementation. This means that a script written under Linux Ubuntu with a Python 3.7 install, and executed under Windows 10 with a Python 3.7 install will give the required results.

However, we shouldn’t be overconfident. For instance, a script written in Python 3.x will behave badly if it is run in a 2.y environment. To a lesser extent, a script written in 2.y will cause difficulties in a 3.x environment. In addition, a script written in Python 3.x may pose problems with an interpreter from a version before 3.y where y < x, if it uses the language’s latest developments.

There have, in fact, been several changes to the language between Python 2 and Python 3. Python’s authors justified the lack of compatibility between versions 2 and 3 by the volume of changes. Here are some examples:


Python needed substantial revision, and an experienced programmer finds it appreciably easier to use Version 3. The Python site also offers a comprehensive strategy for porting a program from Python 2 to Python 3.

In a language like C, which has not changed since 1999 and is virtually frozen, adaptation is much less of an issue. However, less portable languages pose problems when changing machine (Linux to Windows).

In simple terms, delivering a Python script to a customer requires it to install a Python environment.

However, there are a number of ways to get round these problems. Ausy recommends the Nuitka compiler, an impressive project written by a German developer. Nuitka transforms Python code into C or C++, then compiles it into an executable (without enhancing performance). You can thus deliver just the executable and all the libraries and hope to see the program working on the customer’s system. Nuitka does not, however, resolve potential compatibility problems between versions of dynamic libraries: they contain code loaded dynamically as the program executes, so the local library must be up to date.

There are several techniques for producing programs:

Mode A. Standard compiling (C, C++):

Source file → Compiler → Object code file → Link editor → Executable file → Execution engine → Result to screen

There has never been a standard compile sequence for Python. In practice, the language is very quickly compiled automatically on execution without the user’s knowledge, by creating a x.pyc file for each file.

Mode B. Interpretation (Shell, Python, Perl)

Source file → Interpreter → Result to screen

Mode-B execution is very useful for quickly checking an element of the language that the programmer does not remember exactly.


Mode C. Virtual machine (Java and Python)

Source file → Compiler → Bytecode file → Interpreter (virtual machine) → Result to screen

You can run Python in command line (Mode B) and as a script (Mode C), whereas Nuitka allows us to use Mode A.


A good developer works with the right tools: the importance of the environment

To develop good code in a particular language, we need a good integrated development environment (IDE).

This IDE must at minimum provide:

  • Syntax highlighting:



  • Auto-complete and navigation

Auto-complete offers us appropriate choices of attribute and variable as we write the program, whereas navigation lets us enter a class or function from the calling routine using the mouse.

  • An integrated means of checking code quality

The “lint” command was originally a Unix command to check C code in more depth. It is a static verification, i.e. the source code is checked without being run. The homologue of archaic lint for Python is PyLint, and there are also other alternatives.

The Python language is developed via “Python Enhancement Proposals” (PEPs), documents outlining possible improvements to the language, some of which will be rejected by the Committee. The best-known is PEP8, which standardizes how coding is done in Python: for instance, it requires capitals for class names, etc.

Our IDE must therefore incorporate PyLint (or an equivalent) so we can check that the code complies with PEP8.

  • Corrections in “step through” mode

Some programming errors are very hard to spot, and to identify the anomaly, the instructions need to be executed one by one, while observing changes in the values of the variables. Two of the author’s projects were already using the console (via the “curses” library), and in such cases, the display cannot be used. The Wing-Python IDE gave me two separate windows, one to execute the program and the other to step through the Python program.


There are several free IDEs for developing in Python:

  • IDLE is supplied as standard from the official Python site because it was written by Guido Van Rossum, but is not considered very user-friendly.
  • Visual Studio code is Microsoft Visual Studio’s variant of Python and is very efficient although it takes a long time to install.
  • The Python version from Eclipse, Pydev, is very efficient. The author uses it in fact in a work context.
  • Although often mentioned on the Web, Eric has never been used by the author. I will not, therefore, pass judgement on this IDE.
  • Pycharm is specifically for Python, and has free and paid-for versions.
  • Wing-Python IDE is also specifically for Python with free and paid-for versions. This IDE allows great precision and so is the author’s choice!


One of the main criticisms of Python, apart from its slowness, has been its laxity regarding data types, with the unfortunate corollary that error detection was delayed until execution time. But the good news is that you can remedy this weakness with versions since Python 3.6, and so make large projects written in Python significantly more secure.


j.lefrancoisJérémie Lefrançois, an Ausy consultant since 2004, wrote his first programmes in Basic on a ZX Spectrum back in 1982. He gained a postgraduate qualification in IT in 1989, and has worked with many computer languages on a personal and professional basis. He enjoys exploring and comparing the possibilities of different languages - especially Python - which has been his preferred language since 2014. He thus takes a keen interest in monitoring developments in this dynamic language, which he likes for its ease of implementation.


And you may be interested in our Big Data product

Let's have a chat about your projects.