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

[Dave Froble]

On 1/4/2019 10:24 AM, Stephen Hoffman wrote:
> 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.

Not everyone has the same perceptions of reality ....

Now, I know nothing of Python.  But the little I "think" I understand, 
from reading here in c.o.v, is that some people who are working on 
Python 3 have a vision that is incompatible with older versions of 
Python.  Is that a fair assessment?

If so, then this might be a fair test of the acceptance, and therefore 
viability, of visionaries attempting to drag others along into their 
vision.  Regardless of the merits of the vision, remember the classic 
case of VCR and Batamax.

Similar to the advocates of OO.  The vision of some just may not be 
adopted be others.

Perhaps sometimes the visionaries will not be followed.  Perhaps 
sometimes they should not be followed.



-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486