Language change and code breaks

[Peter Mayne]

Up-front declaration: it's not my language, and I haven't been using it for
that long, so my opinions are probably worth slightly less than you think
they are, in which case feel free to laugh out loud, because I won't be able
to hear you. On the other hand, I may not be the Pope, but I know what I
like. 8-)

If Python is made case-insensitive, then the following should work:

>>> class A:
...  def F1():
...   print 'F1 in A'
...
>>> A.__dict__['f1']()
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
KeyError: f1

The error is what currently happens, of course, but in case-insensitive
Python, then you should get 'F1 in A'.

How should this work? If the language is case-insensitive, then surely it's
reasonable to expect that in this case, 'f1'=='F1', i.e. case-insensitive
string comparison. Or should dictionaries be changed so that key lookups
become case-insensitive? That would mean a program that looks for different
cases of variables and produces example output of {'STRING': 3, 'String': 2,
'string': 3} (posted elsewhere in this thread) couldn't be written. 8-)
Maybe we should change only some dictionaries. I know I'm not going to
figure out the "right" way of fixing this.

We could (for instance) assume that all variable names are stored in lower
case, but then A.__dict__['F1']() wouldn't work. How do you explain that
defining a name in upper case, then doing introspection using the same case,
doesn't work, just after you've explained that the language is
case-insensitive? For that matter, how do you explain to beginners that
Python might be case-insensitive, but 'Python'!='python'?

Furthermore, if Python is extended to allow Unicode variables (in the same
way as Java: why shouldn't NumPy programmers be able to use variable names
like [imagine actual Greek characters here] pi or delta, or words from a
Hungarian phrasebook in their own code?), how will case-insensitivity be
managed then? We probably don't even need to invoke Unicode: I believe Dutch
has some interesting upper <-> lower case mappings. Anyone from Holland
here? 8-)

Since the title of this thread indicates that is isn't about
case-insensitivity exclusively, I'll drag in the integer divide problem as
well.

I have a VMS background. One of the rules in VMS is that user code (source
and binary) that doesn't break any rules is guaranteed to work on all
successive versions of VMS. This includes VAX/VMS 1.0, right up to the most
recent VAX-based version, and even onto Alpha-based versions (including
translated binaries). I think this is a Good Thing.

Some people seem to be arguing that 1/2==0 is "wrong", and should be fixed.
Given the philosophy espoused in the previous paragraph, it doesn't matter
whether 1/2 *should be* 0, or 0.5, or RationalNumber(1,2), or the number of
Bruces in the Philosophy Department of the University of Woolamaloo [sic]:
the point is that 1/2 *is* 0, and therefore 1/2 must *stay* 0. Whether the
answer 0 is "right" or "wrong" is irrelevant. By all means introduce a //
operator or fdiv() function which produces 0.5, or extend the language in
some other way, but don't make changes that break existing code.

Likewise for case-sensitivity, and any other feature of Python that someone
may want to change one day: it isn't "right" or "wrong", it *is*, and
therefore should never become *is not*. There is no excuse for breaking
existing code: certainly, "it was a mistake to do it that way" and "it
should be different" aren't nearly sufficient reasons for breaking that air
traffic control application. 8-)

When changes are proposed, can anyone guarantee that they can figure out all
of the ramifications? (See the introspection example above.) If so, can
anyone guarantee that all of the broken code out there will somehow be
correctly upgraded when a new version of Python is installed, even if the
.py files have disappeared and only the .pyc files remain?

Of course, all this is rather idealistic, and makes it difficult to
introduce new keywords like 'yield'. Maybe Python should have taken a tip
from Algol68 and used a different font for keywords. 8-)

PJDM (expecting the Spanish Inquisition 8-)
--
Peter Mayne
IBM GSA (but the opinions are mine)
Canberra, ACT, Australia
This post is covered by Sturgeon's Law.