In article <[EMAIL PROTECTED]>, Sverker Nilsson <[EMAIL PROTECTED]> wrote:
> No one forces me, but sooner or later they will want a Python 3.0 and > then a 3.1 whatever. > > I don't want that fuzz. As about the C versions, I am not that > worried. What's your point? > > I just like want to write a program that will stay working. And maybe > I can go on with something else hopefully than just compatibility > fixes. They take some work afterall. > > It seems hard with Python. Esp. 2 -> 3 Welcome to the world of Python. There was a period of relative stability in the '90s, culminating with version 1.5.2, which just happens to be about the time that people started taking Python seriously. It turns out that this stability was only due to lack of resources, though. I think most of us are working under two imperatives here that really boil down to the same thing: we want a programming language that lets us focus on the goal of the program. On one hand, that means things like automatic memory management that are brought to us by newer languages (i.e., less than 30 years old.) On the other hand it means stability that allows our deployed code to go on working without constant intervention, which usually we find in languages that have become utterly boring and out of fashion (i.e., more than 30 years old.) It's hard to find a good compromise between these two, in an interpreted language. I don't know what the current party line may be on this matter, but some years back it was that you should consider the interpreter part of your application. That is, each application should deploy with its own dedicated Python interpreter, complete with libraries and everything. This naturally relieves some of the maintenance issues, since at least you can upgrade on your own schedule, but of course it has its costs too. Anyone who might be thinking about using Python for an application should seriously think about this. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
