Python - current versions and implementations (CPython, Jython, IronPython etc)
Archive - Originally posted on "The Horse's Mouth" - 2011-11-13 19:07:16 - Graham EllisVersions
Python originated in 1988, I am told.
Think back to decisions YOU made in 1988, and they may have been good ones at the time. But it's likely that a good decision such as "which camera would I buy" made NOW would come up with the same model. And it's the same thing with programming languages too. Python is much better than other languages in this respect. Because it started out with a simple and forward looking framework, its issues as regards modernity are not great, and it's far more fine adjustments that rewrites of the core that are needed. It's been good for coming up for 25 years, but a few tweaks are needed (and have been applied) to make it good for the next 25 years too. And a few of those do lead to changes in the source code - "incompatibilities" you may call them, although tools are provide to help in the transition.
Python 2.0i originated in 2000. Versions have moved up 2.1, 2.2 etc to 2.7, with sub-releases such as 2.7.1 and 2.7.2
During the life of Python 2, features and facilities have been added such as generators, new style classes and decorators (the full list would be a long one). Some elements have been deprecated - i.e. they remain, but their use is no longer encouraged and you're given fair warning that they'll be removed at a future date.
Python 3.0 was released at the end of 2008. Version have moved up 3.1 and 3.2, with sub-releases such as 3.2.1
Python 3 is not an instant replacement for Python 2. Some deprecated elements have been removed, and some features have been moved around / renamed / redesigned to reflect changes 20 years on from the original Python. And that means that the program sources is not compatible. Which is to be regretted in the short term, but applauded in the longer term. And a utility - "2to3" is provided to help you.
The switch from Python 2 to Python 3 by users will be a slow one. There are so many modules written using Python 2 that need to be converted, and with things like numpy that's major work, I understand. And there are so many computers out there, so many distributions loaded with Python 2 that it would be a very brave author of an open source product that specified "Python 3" for quite a long time. So we're seeing a gentle drift rather than a calamitous switchover. Indeed, Python 2.7 was a new release of Python along the "2" track long after Python 3.0, so the Python folks themselves are in total support of this gentle drift.
Implementations
Python runs on many platforms. Implemented internally in the C language, it's a standard part of Linux. You'll find it as standard in virtually every modern Unix too, such as Mac OS X, and it's freely and easily available (but not supplied as standard) with Windows operating systems from Microsoft. This version is sometimes referred to as CPython
Both source code and internal binary code can be transferred between systems / operating systems with ease for the most part - indeed, I'm happy to teach Python to a mixed classroom running Windows, Unix and Linux systems. The biggest differences relate to the environment on the computers - which editors to use, and where the Python 'interpreter' is located. Code wise, the following should be noted:
a) If you call a method to say "go run this operating system command", you had better be running your Python on a computer that supports the command
b) Methods in the os and os.path modules may be called cross-platform, but the modules themselves (os.pyc and friends) have to be implemented on a system by system basis; this is how Python provides the ability to support things on different operating systems as far as the regular programmer is concerned
An open source-download - "py2exe" - provides the tools that allow you to bundle all the necessary Python components into a single file with your own program, so that you can distribute Python executables on Windows systems without having to ensure that Python's also installed on the target computers.
Jython (formerly JPython) is an implementation of Python to run on the Java Platform (Java Virtual Machine). It consists of a compiler to compile Python source code down to Java bytecodes which can run directly on a JVM, a set of support libraries which are used by the compiled Java bytecodes, and extra support to make it trivial to use Java packages from within Jython.
There are a number of differences between Python and Jython . First, Jython programs cannot currently use CPython extension modules written in C. These modules usually have files with the extension .so, .pyd or .dll. If you want to use such a module, you should look for an equivalent written in pure Python or Java. This may be fixed in a future release, but there are a number of other differences between the two implementations that are unlikely to go away. These range from the trivial - Jython's code objects currently do not have a co_code attribute because it is not possible to directly access Java bytecode from a class, without loading the file; to the significant - Jython uses Java's true garbage collection rather than Python's reference counting scheme.
IronPython is an open-source implementation of the Python programming language which is tightly integrated with Microsoft's .NET Framework. IronPython can use the .NET Framework and Python libraries, and other .NET languages can use Python code just as easily. IronPython is an excellent addition to the .NET Framework, providing Python developers with the power of the .NET framework. Existing .NET developers can also use IronPython as a fast and expressive scripting language for embedding, testing, or writing a new application from scratch. The .NET framework (base class library, presentation foundation, Silverlight, etc.) gives developers a large amount of functionality and power.
I've spent today writing an update to our training materials on Python - a fresh lick of paint, if you will - and the thing that changes the most with any good language is the versions and implementations. I fully expect the above comments to look old very much more quickly than Python code looks old!
The full (new) "fast start" module - for use on private courses where the delegates are all old hands, but just not at programming, may be found [here].
I've also added a new module on calling functions and methods in modules and packages - that's [here]. Previously, we've taught our delegates how to write functions and methods in the same module as we've taught them how to use such named pieces of code. However, the courses (and this applies to public courses too) are now going to encourage delegates to make early use of existing functionality provided with Python in a much more forceful way!