Language change and code breaks

[Terry Reedy]

"Terry Reedy" <tjreedy at home.com> wrote in message
news:wdo87.35525$EP6.9091573 at news1.rdc2.pa.home.com...
stuff that was not completely clear.  The following is a completely
re-writen replacement.

Deletion Criteria, v.2

On 2001 July 10, I classified changes into deletions, additions, and
replacements.  The functional definition of a deletion is that it
breaks code in the forward direction only (some old code no longer
works, new code works even under old language rules [1]).  Similarly,
additions break backwards, replacements in both directions.  Pure
deletions in Python have been rare; 'access' removal is the only one I
have noticed.  I propose that a feature should only be deleted
(without a more than compensating replacement) when it is rarely used
and not considered useful even when it is.  'Cleanup' and the like
seem insufficient reason to break code more than rarely or to
eliminate a useful construct.

Some few days thereafter, Guido injected into the discussion a
proto-proposal to delete case sensitivity from Python.  This proposal
soon dominated this thread.  If the implementation were to reject
names that differ only in case from a previously bound name, it would
be a program-history-dependent deletion.  If it were to forbid one
case from all names, it would be program-independent.

If the implementation were to treat upper and lower case as the same,
the change would be a semantic substitution that adds the 'feature' of
seeing all 2**len case variants of a spelling as the same word.  This
identification would mute the breakage of old code by shifting its
overt appearance elsewhere, if anywhere.  It would also introduce
breakage in the reverse direction. While it would sometimes be correct
in new code, and therefore maybe a benefit, it would also sometimes be
wrong, even in new code.  The resulting non-identification of a bug at
its point of introduction would be a detriment.  To me, turning the
deletion into replacement by adding buggy intent inference makes it
even worse.  So I discount this alternative.

Since Guido appeared to accept the content of my essay and then
proposed something that to me strongly violates a seeming obvious
guideline contained therein, I was and am puzzled.  I first conjured
the idea that the proposal was a troll designed distract attention
from the division proposal while he finished 2.2a1 and rewrote the
PEP.  Since that seems false, I think maybe he and others might
actually have a less stringent guideline for deletions.  Or maybe I
have altogether missed some subtle, non-obvious-to-me point to the
proposal.

If the second idea is true, I invite presentation of such alternative
deletion criteria for discussion.  For the purpose of such a
discussion, I suggest setting aside the controversial case proposal
(which is *not* the prime focus of this posting) and using a
hypothetical such as the following:
'''
PEP: Deprecating Underscore

In natural language, underscores (underlines) are usually seen as text
decorations or space markers rather than as characters in themselves.
Thus, their inclusion with letters and digits in names is confusing to
beginners and jarring to some experienced programmers.  In private and
class magic names, the jar serves a purpose.  Not so in normal public
names.

A. The intermittant appearance of _ in commonly used built-in function
names (has_key, raw_imput, but {get/set/has}attr)  is especially
problematical.  Because _ has no pronunciation, it is easy to omit
when thinking, speaking, and writing.  How many Pythoneers actually
think or say 'has underscore key' instead of the buggy-when-written
'haskey'?  So lets remove _ at least from built-in function names.

B. (Radical alternative) Lets go all the way and delete _ from all
public names.  This will, in effect, remove 'underscore sensitivity'
from Python by ceasing to distiguish between '' and '_'.

Objection: Even moderate proposal A would break lots of code.
'''

What deletion criterion should any such proposal meet to overcome the
objection and be accepted?  What burden-of-proof should it meet?

Terry J. Reedy

[1] For this article, at least, this definition views a program as
including all modules that it depends on, including those normally
bundled with the interpreter as built-ins.  'Back-compatibility'
assumes that a program is carried back intact.  In practice, this may
mean wrapping an old version of a built-in to make it look like the
new version the program expects.  When identifiers change, it will
mean so.