Sometimes the forward progress of a technology doesn’t proceed in an orderly and predictable manner. I first ran into this when I was representing Microsoft in ISO/IEC standards discussions around the Office Open XML file formats a few years ago.
XML 1.1 had been published in 2004, but its changes from version 1.0 were controversial, and therefore many XML tools continued to only support version 1.0. A typical perspective was voiced by Elliotte Rusty Harold in his book “Effective XML,” where he had this to say:
Everything you need to know about XML 1.1 can be summed up in two rules:
1. Don’t use it.
2. (For experts only) If you speak Mongolian, Yi, Cambodian, Amharic, Dhivehi, Burmese or a very few other languages and you want to write your markup (not your text but your markup) in these languages, then you can set the version attribute of the XML declaration to 1.1. Otherwise, refer to rule 1.
The Office Open XML spec (ISO/IEC 29500, published in 2008) included a normative reference to XML 1.0, which some people had suggested needed to be “upgraded” to XML 1.1. This change would have caused many problems for implementers, and after some debate in the Open XML working group it was decided that the reference should continue to point to XML 1.0, in its 4th Edition at that time.
The Python community has a similar schism regarding the differences between Python 2.x and 3.x. Some Python programmers don’t care for the changes introduced in version 3.0, and even today, over six years after its release, there are some popular Python libraries that have never been upgraded to Python 3.x. Consequently, many Python developers need to have both a 2.x version (usually 2.7) and a 3.x version installed, and once you add a few modules to the mix (which need to be written for one or the other, due to some syntactical breaking changes in version 3.0), things can get very messy.
There is a great tool for managing this mess called virtualenv, but it’s based on the premise that you have a set of Python projects that are each associated with a specific Python version. In my case, I’ve found that I sometimes want to try some code on Python 2.x or 3.x spontaneously, switching back and forth on the fly.
Well, today I learned that there’s a handy way to do this, which comes built right in to the latest Python versions and requires no additional tools or preplanning. You can simply use the py launcher instead of python.exe, and it will run your highest-numbered Python 2.x version installed. Alternatively, you can use py with a -3 command line parameter, and it will run your highest-numbered Python 3.x version installed.
For example, on my laptop I currently have Python versions 2.7.9 and 3.4.3 installed, and here’s how it works:
This is very handy!