[Info-vax] Python on VMS

[Stephen Hoffman]

On 2019-01-17 17:36:23 +0000, Arne Vajhj said:

> On 1/17/2019 11:17 AM, Stephen Hoffman wrote:
>> Upward-compatibility is most definitely very desirable and very 
>> important.  But in very specific and selective cases, app compatibility 
>> has to be broken to make forward progress.
> 
> Yes.
> 
> And many are relative good at doing that.
> 
> But I don't think Python fall in that category. Changing the meaning of 
> the / operator and changing print from keyword to function does not 
> seem to have been really needed the same way as VMS need longer 
> password hash.

Whether or not what the Python folks chose and did here is what you'd 
choose and do might be interesting discussions, but breaking changes 
are what happened here.  We have what we have.

Which means that Python users either port our code forward, or we port 
our Python code elsewhere, or we fork the whole Python project and pick 
up ongoing support for Python 2, or—and this is the classic OpenVMS 
approach—we decide stay on the old version until forced into a decision.

As for the future of Python or other tooling, if the tool is important 
enough to the platform, then the users or the vendors involved join the 
project, or acquire or fund the project. This to gain a more 
participatory role in the decision processes and the tradeoffs.   Same 
considerations for LLVM and other dependencies.

Providing fixes and updates upstream is also part of this, and OpenVMS 
tends to be insular and weird, and with old tooling.  VSI is addressing 
some of the tooling with the LLVM port, but this is an ongoing issue 
and far wider than clang.

But we have what we have now, which is no Python on OpenVMS by default, 
an old Python port for OpenVMS, and no statements around the inclusion 
of any Python support into the OpenVMS distro.   By all appearances, 
breaking changes will happen in Python, OpenSSL and in many other 
contexts.  So y'all can ignore this likelihood, or y'all can figure out 
how to deal with it in your environments.  OpenVMS is just not good at 
multi-version, discussions of Oracle Rdb multi-version support and 
recent and very limited VSI work around OpenSSL support aside.

Even entirely within OpenVMS itself and irrespective of outside tooling 
and compiler language standards and interoperation and security 
standards and all the rest, we're still going to be contending with the 
necessity of breaking changes.  Because you cannot compatibly fit 
thirty-two bytes in an eight-byte field.

Y'all can pine for the simpler times and the previous millennium and 
the forever-upward-compatible DEC dreams, and it just ain't coming 
back.  If it even ever was.



-- 
Pure Personal Opinion | HoffmanLabs LLC