[Info-vax] Python 2 support ends 1-Jan-2020

[Stephen Hoffman]

On 2019-01-04 02:25:51 +0000, Dave Froble said:

> Sounds like an interesting predicament.  Maybe this could be a preview 
> for Steve's ideas breaking things in order to move on.  Somebody keep 
> track of this.

The Python 3 division change—switching from an integer result to a 
floating point result—has been underway for most of twenty years.

Python source code migration tools and testing tools have been 
available for a long while too, with a tool that allows Python 3 code 
to also operate on Python 2, and another that allows migrating Python 2 
code forward to Python 3.

https://docs.python.org/3/howto/pyporting.html

The Python migration has messes undoubtedly be similar to those of any 
hypothetical DCL migration, too.  Some mixture of added floating point, 
64-bit integers, and/or unsigned integers isn't a stretch in some 
future DCL or DCL replacement, after all.

The addition of IPython would be a more isolated and probably 
pragmatically better approach than DCL2 or VCL, in the shorter-term.  
https://jakevdp.github.io/PythonDataScienceHandbook/01.05-ipython-and-shell-commands.html 


Independent of working with Python and the Python 3 migration "fun", 
I've been working with tooling that migrates source code from older 
APIs, which is something that's been comparatively rare within OpenVMS 
environments.  That tooling has often worked fine, and—even when it 
doesn't completely resolve the necessary source code changes—having the 
routine changes automatically migrated is still handy.  OpenVMS has had 
documentation for many of these (sometimes not, such as with SMTP), 
sometimes had binary translation tools, but seldom much in the way of 
developer assistance.  And the app migration 64-bit addressing is going 
to be causing us grief for the foreseeable future, when it's not simply 
ignored.

We're in a world where there'll inevitably be breaking changes to APIs, 
and which means we're going to have to deal with that.  And deal with 
that better than we have.   TLS, password hashes, and (soon) 64-bit 
file I/O among these areas.  And with older and particularly 
problematic APIs that eventually get deprecated and removed, and 
OpenVMS just has not been good at that.  I care rather less about the 
removal of $crelog and other retired APIs here, nor whether you're 
still using K&R C syntax and its problems, and rather more about 
retiring and removing hard-coded 8-byte password hash buffers and 
DECnet and telnet.  And some apps will fail when migrating to 64-bit 
I/O, too; to apps running with and on SSDs and HDDs larger than 2 TiB.  
64-bit flat virtual addressing would be handy too, but I don't see VSI 
having the fortitude for what that would involve.

And yes, there'll be Python 2 source code around for decades.  There 
are still VAX systems around, and there'll remain a 
hopefully-decreasing apps and code that uses $crelog and ODS-2 and 
DECnet and telnet, too.  Same for old Windows versions, DEC PDP-11 
boxes and whatnot.  Some folks will run stuff into the ground, and for 
whatever reason.  Those same folks often aren't much of a market for 
sales and support, though.  Or keeping those folks with the older 
configurations happy slows down support for the folks that are buying 
in larger volumes.

Feature-competitive operating systems are ginormous projects, and the 
VSI budget is very far from ginormous.  Which means VSI gets to pick 
from a very long list, and targeting what will keep the installed base 
buying. Which has historically been different from what new folks might 
or would want.  And while the installed base is the future of VSI, the 
oldest parts of the installed base... aren't.  Not unless they start 
moving forward.



-- 
Pure Personal Opinion | HoffmanLabs LLC