Language change and code breaks (fwd)

[Peter Hansen]

Aahz Maruch wrote:
> 
> In article <3B5505A0.F89ADB86 at engcorp.com>,
> Peter Hansen  <peter at engcorp.com> wrote:
> >Lulu of the Lotus-Eaters wrote:
> >>
> >> I go away, no longer available.  The client's web hosting company
> >> upgrades the Python installation to Python 3.7 (this is in the future
> >> :-)).  Client's scripts break.
> >
> >In this case, I would argue that the client's hosting company should
> >not upgrade Python (especially across a major revision) without either
> >notifying everyone who is using it (may be hard to do), or keeping
> >the old version around for legacy use.  After all, if they support
> >Python for customers, they presumably are interested in and somewhat
> >responsible for keeping the customers' applications functional when
> >they do such an upgrade.
> 
> For how long?  I just checked on Panix, which I believe is considered to
> be a well-run hosting company, and they don't have Perl4.

About six months.  Not a moment longer. :-)

I seem to be having a little trouble getting my point across.

Am I really the only one who seems to think that, so far, the
arguments against this change on logistical grounds seem to 
be based entirely on hypothetical situations, and require
increasingly contrived examples to make their cases?

I'm suggesting that it is neither practical nor realistic 
to avoid making such changes to Python solely on the basis
of potential difficulties for some hypothetical classes of 
users who seem to have the following unlikely combination 
of traits:

 1. They are inactive in the Python community and are 
    therefore unaware of the upcoming code breakage.

 2. Their code is dependent on the existing integer
    division behaviour, and yet they are not amongst  
    the classes of users identified in this newsgroup
    as being the most likely to be impacted.

 3. They are incapable of maintaining their code, 
    and simultaneously are entirely at the mercy of
    outside forces who may choose to upgrade them
    against their will or without their knowledge to
    the new and incompatible version of Python. 

    Or, they are not at the mercy of outside forces,
    yet mysteriously cannot *avoid* upgrading their
    Python installations and thus breaking their
    own code (which they somehow cannot maintain).

 4. Were we to develop and make easily available to
    them a scanner capable at least of identifying
    the probability they will suffer code breakage,
    they would be unable to use it, whether for
    (1) or (3).

Have I missed anything?

In the end, clearly there will be *some* users who
are affected against their will, without their 
advance knowledge, and in situations where it will
be difficult for them to recover easily.  I'm not
saying there are not.

I am saying that I don't think the numbers of 
such users is large enough to weigh that heavily
on our minds.  We shouldn't try to be baby-sitters
for ISPs who don't care about their own customers.

We needn't try to ensure that every possible current
user of Python, no matter how bizarre or unlikely
their situation, never ever has to touch their code
again even if somebody upgrades their environment 
right under their feet!

Or am I really overlooking a significant contingent
of users here? (in which case I apologize to them 
in advance for what I'm suggesting we do. :)

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com