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

[Stephen Hoffman]

On 2019-01-05 00:43:32 +0000, Dave Froble said:

> On 1/4/2019 4:32 PM, Stephen Hoffman wrote:
>> On 2019-01-04 16:05:50 +0000, Dave Froble said:
>> 
>>> 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?
>> 
>> Ponder whether fixing stuff is utterly impossible with OpenVMS, for 
>> those cases that cannot be fixed compatibly.
>> 
>> The password hash length being a salient example.
> 
> You've been dwelling on this point for too long maybe?  VSI has, I 
> believe, made the improvements to this issue, or at least plans to in 
> the x86 product.  Don't know, haven't been following it.

I've been dwelling on the point for far too long, yes.  Because there 
are folks that thinks that changes can be made compatibly; that VSI can 
promote an eight byte field to thirty-two or sixty-four, when that 
buffer is embedded in app code.

> Yes, it needed enhanced, and is being done.

And until the change ships, it's roadmap material.

> Further, I don't believe this will break anything, because if anyone 
> actually did anything with the data in any production apps, it was an 
> improper and stupid move, and stupid doesn't deserve to be supported.

The APIs ($getuai, $setuai, $hash_password, $acm, etc) and the size of 
this buffer (8) are all entirely documented.

This is the only supported way to verify a password.

Apps that are comparing hashed passwords are not particularly unusual.

Which means that buffer definition gets embedded in the apps.

Apps that have migrated to $acm for password-related processing are 
somewhat less common.

And code using $acm has similar limits here, too.

That eight-byte-buffer declaration gets around.

More generally, $acm is a example of where OpenVMS API design and with 
similar efforts toward traditional APIs can go wrong—solving every 
problem and with great flexibly for future expansion, and at the cost 
of simple usages and simple interfaces, and with hand-rolled parsers 
for complex and variously chained and entirely untrusted data 
structures, and the results still with fixed and hardcoded buffer sizes 
in calling code.  Itemlists and TLV structures and descriptors and 
related approaches are good ideas from the 1970s and 1980s, while other 
API abstractions have become feasible and even preferable given the 
hardware common in this millennium.   All fodder for another discussion 
or twelve.

> The only thing x86 has going for it is volume.  Very large volume.

Which is most of matters in commodity semiconductor production.   Few 
entities have the scale of production to make that work competitively.  
DEC certainly tried with Alpha and other chip designs.  Most folks 
creating custom products now use TSMC or GloFo or another fab, and 
semi-custom Arm designs or similar.

>>> Similar to the advocates of OO.  The vision of some just may not be 
>>> adopted be others.
>> 
>> Have you tried OOP, David?   Blows the sneakers off itemlists, in terms 
>> of its support for upward-compatibility.
> 
> I do believe I was doing some of the things that led to OO, long before 
> there was the OO concept.  It's just good design practice.  But I'm not 
> a fanatic about it.  Fanatics usually go too far.
> 
> Item lists are not the worst thing ever.  I will admit that on a scale 
> of 1-10, they fall somewhere below 5, or 4, or 3.

Until I started using and creating OOP system APIs else-platform, I'd 
have agreed with all of that.

OOP provides a way to be rid of much of the glue code, whether it's 
itemlists being created or itemlists being processed, or the related 
coding work, or the use of fixed-size buffers since both APIs and data 
are passed around as objects; as what amounts to substantially upgraded 
and entirely-opaque versions of various descriptors. It's an 
abstraction that provides better flexibility.  There are times when 
iterative programming or SQL calls or similar still works better too, 
but I'd suspect much of what's running on OpenVMS could benefit, and 
particularly whatever new code is being created.  Not that a lot of the 
existing OpenVMS app code is ever going to be revisited, short of a 
port.

> At this time I doubt I'll be doing much outside Basic, and VAX Basic 
> does not have formal OO stuff.  If it did, I'd use it when appropriate.

As I've mentioned before, BASIC would be an ideal candidate for OOP, 
though that effort is likely in the distant future at VSI, at the very 
earliest.


-- 
Pure Personal Opinion | HoffmanLabs LLC