Case insensitivity

[- RZ]

Guido van Rossum <guido at python.org> wrote in message news:<cpvgkofyru.fsf at cj20424-a.reston1.va.home.com>...
> 
> Several people whom I respect have strongly suggested that if Python
> wants to appeal to non-programmers, it should be case-insensitive.
> (Leaving apart details of how to implement that; I agree that it
> should be case-preserving.)  Others, whome I respect just as much,
> feel that it should be case-sensitive.
> 
[snippage]
> 
> It's been argued that making string, String, STRING and StRiNg mean
> the same thing makes for less readable programs.  I agree.  A good
> programming environment should silently correct the case of
> identifiers as you type to conform to the definition.  This also means
> that you can still use different case conventions to hint about what
> type of identifier it is, e.g. MACRO, Class, variable.
> 
> It's been argued that it's convenient to be able to write c = C(),
> where C is a class and c is an instance of that class.  Surely there
> are other conventions we can use.
> 
> To me, the only real important question is, how can we introduce
> case-sensitivity for novices without breaking the millions of lines of
> existing Python code.  One option could be: forget it, it's too late.
> Another: put the case-insensitivity in the tools.
> 

It seems to me that Python IS case-sensitive. Maybe Python3K will not
be, but that's another language. Case-sensitivity is too fundamental
to change without making the same sort of break as between C and C++.

Personally, I favor the case-sensitive side. I've worked in an
environment with a case-insensitive language (PL/I on an IBM
mainframe) and an editor that allowed case-preservation in the data
and UPPERCASE DISPLAY on the monitor. What an unholy mess *that* was!
Some coders worked with caps lock on, some not. While uppercase
display was set, you couldn't see the difference, but toggle it off
and all bets were off. It exactly resembled the bad examples people
have brought up:
(aStrinG = AsTRING || " some more text";
 intvaRBl = INTvarbl + 1;
 ... and much more like that. No, people don't code that way
deliberately, but they do correct typos without realizing the original
case.) Please don't let it happen to Python! But, oh yeah, there are
the tools.

If case-preservation were tool-enforced, then all of us would
essentially have to use those tools. Many would, but many already have
favorite coding tools that are not necessarily interested in or
capable of such logic. I'd rather use the tools I like than tools I
don't know, and I believe it would be a reason not to follow into the
brave new Py3k world. (Just as an aside, I occasionally have to use MS
Word, and I get extremely annoyed at having to fight against the
software to keep the case and indention levels where I want them,
rather than where it wants them.)

What this and previous discussions of the topic indicate to me is that
case-sensitivity provides a reason for and an opportunity for a fork
in the language; one path leads to Python3000, the other to TruePython
;-) I'd hate to see that happen at this stage of the game, though. I'd
suppose Guido would move to the Py3K line, leaving TruePython to serve
as the stable, incrementally-improving, corporate-love-winning
contender that would eventually win the mindshare game and itself
become the One Obvious Way to Do Computer Programming 4 Everyone!