Jay Tee wrote: > Let's see if I can scare up something I wrote about ten years ago on a > now-dead language that I really wanted to use (wound up sticking with > python instead because "it was supported" ;-) > > ======================= > to figure out how to work things. The fact that there are three (or > four depending if you count Linz V4) different Oberon System > implementations, and several different compilers, and even four or > five separate dialects of Oberon with none of them appearing to be > really "official", gives the impression of a fragmented, directionless > development effort, and a probability bordering on 1.0000 that > whatever you try to do will be incompatible with all but a small > subset of what's available (unless you stick to writing small programs > like in the books.) It does not matter if you tell people that this > is not so; something has to clearly stand out as being THE STANDARD > STUFF and all the other stuff as INTERESTING BUT NONTHREATENING SIDE > PROJECTS. The STANDARD STUFF must include a sufficient number of > =========================
Well, the problem of multiple standards shouldn't really apply in the same way to Python. Right now, Python 2.X is the standard. Python 2.6, 2.7 and any later 2.X versions are intended to be transitional versions while the standard is migrating to Python 3.X. At some point, the 2.X line will almost certainly be discontinued. So as a Python programmer, the path is clear. As soon as possible, you should make your code compatible with Python 3.0. That will likely mean taking advantage of some new features in Python 2.6, so "as soon as possible" may still mean many years for projects that need to support older versions of Python. Still, once Python 2.6 is installed everywhere by default, it shouldn't be difficult to start making code compatible with the new standard, Python 3.0. STeVe -- http://mail.python.org/mailman/listinfo/python-list
