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

[Dave Froble]

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

And when they are upgraded for the new stuff, they should work well, for 
those who used them, I'd think.

> This is the only supported way to verify a password.
>
> Apps that are comparing hashed passwords are not particularly unusual.

They should be very unusual.  As in not exist.  Very poor design.

> Which means that buffer definition gets embedded in the apps.
>
> Apps that have migrated to $acm for password-related processing are
> somewhat less common.

Just ask me why that is.  I was rather unhappy doing a few simple things 
with ACM.  I'd hate to be tasked with anything complex.

> 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.

If it ain't broke, don't fix it.

>> 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.
>
>


-- 
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