Eliminating upgrade risk
johnroth at ameritech.net
Fri Jul 27 17:46:30 CEST 2001
"Peter Hansen" <peter at engcorp.com> wrote in message
news:3B5FAD11.FB9D737E at engcorp.com...
> John Roth wrote:
> > After enduring the PEP 238 threads for far too long, as well as other
> > threads, I've come to the conclusion that Python is simply too unstable
> > for real use.
> Do you really mean "is" too unstable, or you mean it looks like it
> "might be" unstable, solely because of the proposals about changing the
> way the / operator works?
I mean is. Notice that I said "among others," therefore PEP 238 was
**NOT** the sole proposal involved.
> I've used Python for about a year and a half in dozens of practical
> areas in industry. I consider it *bar none* the most stable language
> I've ever used. Not only with respect to the stability of the
> applications I write, but also the runtime (I can hardly recall a crash,
> although I'm sure I've had a few when using calldll around third-party
> DLLs) and definitely *even the language definition*.
Runtime stability was not the issue. That's a given before I even start
evaluating. And I don't consider the existing problem with Win 9x
console mode and Tkinter to be a point in Python's favor.
> Changing from 1.5.2 to 2.1 required us to do, let me see: nothing!
> I reviewed the list of changes, predicted we would not be impacted,
> and so far (after several months of ongoing development and continued
> use of our many utilities and applications) I've been proven correct.
Many shops want something a little more concrete than a statement
by the top technical expert. A compatibility scan tool would be
> So I'm guessing you really just mean that this PEP 238 proposal
> is scarey. I agree, to the extent that code breakage is never nice
> to contemplate, but with the ongoing consideration being given to the
> issue by the developers, I'm reasonably satisfied that even this
> drastic change will end up having relatively little effect on my
> opinion of Python's stability. Planning over two years in
> advance and guaranteeing the breakage will only occur when
> a major upgrade (Python 3.0) is released is pretty much the
> best you could hope for from any language. After all, by convention
> major upgrades are where you are supposed to *expect* code
That last sentence is what is scarey, not PEP238 or any of the
other specific proposals. There's an endemic mindset in the xNIX
community that simply doesn't understand the risk aversive behavior
of many of the large shops. If compatability isn't guaranteed, then
an upgrade is a project - which has to be scoped, justified, planned,
and then prioritized with all the rest of the projects.
> > Hopefully, this is going to provide more food for thought than fuel for
> > flames.
> I hope you don't consider this a flame. But I'm not responding to
> the suggestion of "required" other than to say I don't think it's
> really necessary (because I don't think it's really necessary...
> as should be evident from the above).
I think we're going to disagree on this one...
> Peter Hansen, P.Eng.
> peter at engcorp.com
More information about the Python-list