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....@python.org> On Behalf Of Chris Angelico Sent: Wednesday, January 16, 2019 2:15 PM To: Python <python-list@python.org> Subject: Re: Pythonic Y2K On Thu, Jan 17, 2019 at 6:04 AM Avi Gross <avigr...@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 -- https://mail.python.org/mailman/listinfo/python-list
