Pythonic Y2K

[Avi Gross]

Well said, Joseph.

Unfortunately, many companies are run these days with a view toward the
IMMEDIATE bottom line. I mean numbers like revenues or expenses are seen
short-term. If a project stops development on new things and spends time
redoing old things, there are expenses recorded with no revenues. Another
organization might go ahead and get up to date and a few years down the road
their projects are sailing along while the first employer keeps running into
obstacles and is not able to get new developments and so on. But often, the
manager making the decision will have taken their bonus or promotion and
perhaps moved on or retired.

Not to be political, I note many government entities, especially including
the state I live in, have gigantic pension obligations they have no easy way
to meet. Over the years in negotiations with unions they have often traded
rich promises for the future instead of immediate pay hikes. The costs may
largely be invisible and did not impact their current budgets so they could
waste money on other things such as giveaways that help them get re-elected
to ever higher office. But the costs are getting very visible now, and
especially when the stocks they invest in decline.

Back in the computer world, Y2K gave such managers some cover. There was a
FIRM deadline. I wonder how many used the impending arrival of the year 2000
as an excuse to perhaps clean up other parts of their act and charge it to
prevention. I mean they might suggest they rewrite some legacy COBOL or even
machine language programs into something more modern or other improvements
like getting a new database including new hardware.

I also wonder if jobs for some programmers declined sharply in the years
after when not only were they not desperately needed, but perhaps not needed
at all unless they developed new talents.

Just FYI, the name Y2K always struck me as similar nonsense. They
abbreviated Year and 2000 from at least 8 characters to 3 and did it wrong
as 2K is 2048. As far as I know, nothing special will happen in 2048 and I
also have no special vision for 2020.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On
Behalf Of Schachner, Joseph
Sent: Thursday, January 17, 2019 1:46 PM
To: Python <python-list at python.org>
Subject: RE: Pythonic Y2K

I'd like to add one more thing to your list of what companies will have to
consider:

6) The ability to hire and retain employees who will be happy to program in
an obsolete version of Python.  A version about which new books will
probably not be written.  A version which new packages will not support.  A
version which most other companies will no longer be using, so programming
only in Python 2 will place the employee at a disadvantage compared to
others who have gained experience with Python 3 if they ever have to change
employers.

--- Joseph S.

-----Original Message-----
From: Chris Angelico <rosuav at gmail.com>
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