Eliminating upgrade risk

[Steve Holden]

"John Roth" <johnroth at ameritech.net> wrote in message
news:tm336a7vjqjq5f at news.supernews.com...
>
> "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.
>
And the breakages you complain about are ... ?

> > 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.
>
Excuse me. Are you saying that you don't want any new features in the
language even if your existing programs continue to operate in a perfectly
satisfactory manner. From my personal experience in over thirty years of
software development I cannot remember a single language environment where
so much care was taken to minimize the effect of language changes on
existing programs. I wasn't entirely happy about PEP 238 originally, but the
approach now proposed is definitely preferable to the usual commercial
approach, which basically says: "You've upgraded for the new features, now
fix all that we broke in your programs".

> > 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
> appreciated.
>
And I am reasonably sure that one will appear without my having to do
anything about it. But, of course, you must be *buying* your Python. I mean,
if you were getting it for nothing, like I do, your demands would surely not
be so peremptory.

> > 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
> > breakage.
>
> 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.
>
Ah, I see. You don't use Microsoft tools or languages. Have you *any idea*
what the forthcoming transition to VB.Net is going to do the the millions of
lines of code currently written in VB? And do you know what Microsoft's
answer to those who can't, or don't want to, upgrade is? "Run your
applications as unmanaged code." Which is to say, forego most of the
benefits of the .Net environment.

> > > Hopefully, this is going to provide more food for thought than fuel
for
> the
> > > 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...
>
That may be so, but please tell us why. What broke, when?

regards
 STeve
--
http://www.holdenweb.com/