[Tutor] changes in Python 2.2
Jeff Shannon
jeff@ccvcorp.com
Wed, 26 Jun 2002 09:58:28 -0700
I do understand the concern about the rate of change in Python lately, however
I must say that I haven't really seen it as a problem yet. I've been using
Python since 2.0, and the scripts that I wrote for 2.0 work just fine under
2.2. Most of my newer scripts use 2.1 features but nothing more (even since
upgrading to 2.2). Despite all this talk about how quickly the language is
changing... it really seems to be mostly the same, to me.
With that in mind, I have a few specific comments....
"Scot W. Stevenson" wrote:
> Third, I was under the impression that one of the ideas behind Python was
> to create an easy to learn, easy to use, easy to maintain programming
> language that avoids "esoteric" features in the first place. So what is
> Kuchling telling me here about the Python philosophy? Or, to rephrase
> that: If these features are "esoteric", why were they included at all?
Well, *one* of the ideas behind Python is that it be easy to learn. One of the
*other* ideas behind Python is that it be a powerful, flexible general purpose
language. Sometimes the needs of these two ideas conflict with each other, and
Guido and the rest of the Pythonlabs team have put quite a bit of effort to
resolve those conflicts as best they can. Usually this means that the advanced
features can be safely ignored until you need them.
> And PEP 283 tells me that Python 2.3 is due to be out before the
> end of the year...and I bet 2.4 is planned for Summer 2003...and 2.5 for
> the end of 2003...
Meanwhile, a new version of Visual Basic is out only once every few years, but
none of the code written for old(/current) versions will work with the new
version. I'd rather have lots of little incremental changes, which gives me
time to slowly update my code, improve my programming methods, etc. It's a
philosophical difference -- Python is following the open-source dictum of
"Release early and often", which allows much more chance to fix bugs and
misfeatures in the interpreter. This does create an issue with the language
itself being something of a moving target, but at least it's a *stable* moving
target. ;) And GvR & Co are aware of the difficulties this poses, and they
*do* go to great efforts to avoid breaking old code, and to provide plenty of
time to upgrade code when the old style *does* break.
> The problem is that the rate of change has far outstripped the ability (or
> interest) of the people writing documentation to keep up, especially
> documentation in book form.
This is (sort of) true -- there *is* a lack of documentation, especially books,
that cover the new features and changes of the most recent version(s) of
Python.
However, it's also *not* true -- if you sit down with a 1.5-era book in front
of a 2.2 interpreter, and work through the samples, you'll find almost nothing
that doesn't work as you expect it.
> (Say - wouldn't it be easier for all involved just to freeze Python at, for
> example, 3.0, and then have all of these people with these great new ideas
> sit down and design a new language from scratch, one that has all their
> cool features, is stackless, doesn't have a global interpreter lock, is
> great for numeric computation, etc. pp.? And leave the rest of us with a
> stable language that doesn't take a step forwards every time you try to
> throw your saddle on its back.)
No, it wouldn't be easier.
Besides, you can do that anyhow, at any version -- just stop upgrading your
interpreter. You'll never have to worry about learning new features. Yes,
eventually, there will be people writing new libraries and packages that use
newer features, and you won't be able to use those -- but then, if you froze
Python and started a new language, those people would be writing those
libraries and packages for the new language, and wouldn't bother re-writing
them for the now-stagnant Python. And all the new users would be a lot more
interested in that new language, so you wouldn't have any fresh ideas and
idioms coming into Python. Before long, Python would be... well, about like
ABC or Icon or Snobol, known only for what grew out of it, but pretty much
pointless on its own.
I recognize the difficulties of the current path, but I think it's better than
the alternatives.
Jeff Shannon
Technician/Programmer
Credit International