Pythonic Y2K

[Avi Gross]

Chris,

The comparison to Y2K was not a great one. I am not sure what people did in
advance, but all it took was to set the clock forward on a test system and
look for anomalies. Not everything would be found but it gave some hints.
Similarly, it is trivial today to take a machine and install only the new
python version and try it, albeit many programs may have effects far away
across the internet in some apps and harder to isolate.

But Y2K was going to happen guaranteed. The split between 2.X has been
fairly slow in some ways and with crutches designed to make a transition
smoother. As long as there are people willing to remain behind in what they
consider safe territory, there will be those happy to sell them some things
and probably raise their prices. I recall what happened with TELEX some
years ago. It was awfully slow compared to other methods such as email or
FAX but it had legal standing and clients who had to be reached in places
that had less access and so on. I recall how despite huge drops in message
volume year after year, it remained a very profitable item for my AT&T unit
and continued to be supported as we just kept raising the price for those
still wanting to use it. I was working on newer stuff and just watched
several such parts in amazement including others using what I considered
obsolete protocols. Not obsolete to those customers though.

I empathize with people using software that already works. You know, if it
isn't broken, ....

But to continue making it work may require supplying complete solutions as
customers cannot be expected to have older python interpreters sitting
around on their machine. If your application resides within your servers and
only communicates with others of the same ilk, you probably can continue
using it indefinitely. There may be someone still using an ancient PC from
the 80's running Windows 1.0 with a similarly old copy of WordPerfect and a
serial printer attached. But if they want to load a recent version of
Microsoft Office, forget it. Heck, it would not fit on their 20MEG hard
disk. 

I assume there must be tools out there that can look over your code and
point out places where it may not be compatible. But the more I learn, the
more I realize how subtle a problem may be. Some of the back-ported features
for example are not exactly identical in effect. Close, maybe. Things like
changes in Unicode functionality often are papered over and then a valid
statement in one may print a character while in the other it may print a
short int. 

If you ran such a program and it showed minimal issues like just needing to
change print statements into print functions, it might be easier to convince
your boss to upgrade. If the effort looks massive, they may even opt for a
complete rewrite or move to another language that is less likely to keep
changing, or maybe just buy a solution that is not quite tailored to their
needs.

I did have an experience along these lines years ago when a new variation of
C came across.

Years ago I worked on a project at Bell Labs that was mostly in C. As C++
was coming out, I volunteered to do my part using it as I could show why my
application would be object-oriented. I was shocked when they approved and I
set up make files that recognized what code was in C or C++ and compiled and
linked them properly and so on. It worked beautifully and guess what?

We tossed the entire project! This was back in the days when AT&T cared less
about wasting money. Our project had been canceled at higher levels and the
management spent half a year deciding what our next project would be but
felt no need to tell us! So when I offered to do something experimental,
they figured why not! And, yes, eventually we did our new development in
C++. But had they considered it, it would have made more sense to stop
developing something and take the time to retrain the staff with courses
that were available and have us use up some vacation days and be ready for a
new project. 

Bottom line here is I should not be surprised if some people want an answer
on how to keep projects in 2.X going.  But, unless there is a reason, I see
little reason in going along or teaching new programmers on what is in a
sense the less useful version going forward. The main reason to study 2.X,
FOR ME, is to be able to understand it if I encounter it and perhaps be able
to rewrite it.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On
Behalf Of Chris Angelico
Sent: Wednesday, January 16, 2019 2:15 PM
To: Python <python-list at python.org>
Subject: Re: Pythonic Y2K

On Thu, Jan 17, 2019 at 6:04 AM Avi Gross <avigross at verizon.net> wrote:
>
> I see messages like the following where someone is still asking how to 
> do something in some version of python 2.X.
>
> I recall the days before the year 2000 with the Y2K scare when people 
> worried that legacy software might stop working or do horrible things 
> once the clock turned. It may even have been scary enough for some 
> companies to rewrite key applications and even switch from languages like
COBOL.
>
> What is happening in the python community, and especially in places 
> where broken software may be a serious problem?
>
> I assume versions of python 2.X will continue to be available for some 
> time but without any further support and without features being
back-ported.

Commercial support for Python 2 will probably continue for a while, in the
same way that support for versions older than 2.7 is still available to Red
Hat customers today (if I'm not mistaken). Otherwise, well, the software
will continue without updates or security patches until it breaks. Companies
will have to weigh up five costs against each other:

1) The cost of the status quo: the risk of critical failures or external
attacks against unsupported and unpatched software

2) The cost of migrating to Python 3

3) The cost of migrating to a completely different language

4) The cost of maintaining their own local fork of Python 2

5) The cost of using a supported commercial platform such as RHEL.

For most small to medium projects, it's probably going to come down to
#1 or #2, where #1 has the laziness bonus. For many larger companies,
#1 is an unpayable cost. Everyone has to make that choice, and remember that
"cost" doesn't just mean money (for instance, the cost of moving to Linux
might be quite considerable for a Windows shop, and even within a Linux
ecosystem, switching to Red Hat may have consequences to other programs you
might need).

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list