case sensitivity redux (was Re: Language change and code breaks)

[Alex Martelli]

(posted & mailed, just in case Guido is not following
this thread any more, since this is fundamentally a
message of support for his stated position...):

"Guido van Rossum" <guido at python.org> wrote in message
news:cpr8v5a8h5.fsf at cj20424-a.reston1.va.home.com...
    ...
> I have changed my mind.  I think that if I had to start over, I would
> indeed try my hands at a case-insensitive language aimed at teaching
> programming to beginners, with tools to enforce case consistency.
> Given that nobody else who currently uses Python thinks this is a good
> idea,

Just for the record: I *am* "somebody else who currently uses
Python", and I think that "this" (a case-insensitive language,
with tools that enforce case consistency) is a *VERY GOOD* idea.

Pity I was away during the hottest part of this debate, and even
now am far from being caught up -- dislike for case sensitivity
is clearly a minority position in the c.l.p community, but I'd
like it to be just as clear that it's also *NOT* just you... I
feel exactly the same way.

One aspect I haven't seen mentioned in this huge thread is the
issue of visually impaired programmers.  Case sensitivity is an
extra burden for such people (with whom I strongly empathize: my
sight is still OK, sufficient to drive a car &c, but it's going
downhill with time, and I must face the very real possibility
that I'll be _seriously_ visually impaired a few years from now).

Think of a useful tool for such an audience, a special-purpose
'screen reader' that will read out loud a snippet of Python code:
what's the tool going to do about distinguishing upper and lower
case?  With case being significant, the tool will have to point
out *every* case change -- a serious bother.  Was case not thus
significant, the tool could have two modes, a default "smoother"
mode ignoring case, and a special mode pronouncing case to be
used only (e.g.) within literal strings.

For those of you who can't really empathize with other's issues
and misfortunes, imagine being in a situation where you'd often
need to have source code read out loud to you (e.g. over a
phone), and/or you'd often want to dictate code (e.g. to some
kind of voice-recognition, dictation-taking automatic system).
What's case sensitivity giving you, that would compensate for
the serious bother it causes in those situations?


> I then settled on a case-sensitive language with case-preserving
> tools.  But now I think neither is worth fighting for.

I guess that, as usual, you may well be right.  But then,
we're now talking basically about something like some minor
changes to IDLE's source code editor, aren't we?  Or to
Emacs' python-mode, etc.  Surely there would be no fight
necessary to add a "case-preserving switch" to such tools
for optional use.  The only issue I can see is with modules
(particularly in the standard libraries) that may _require_
a programmer to enter the same identifier in more than one
different case-mix.  Are there such cases today in Python's
standard library?  I'm not sure.

Offhand, I can easily think of a few identifiers that
do appear in different cases, e.g. fileinput (the module)
vs FileInput (the class in module fileinput), but it would
seem to me that those identifiers would not normally have
to be entered with case being the *only* distinction (one
would normally write fileinput.FileInput, so a reasonably
smart tool might still be able to get the case right for
each of the two identifiers - or is this requiring too
much smarts from the tools?).  Maybe, if a _small_ fight
is needed to ENABLE (as opposed to FORCE:-) use of a
semi-smart, case-preserving tool, it MIGHT be worth it,
if the fight be small enough...?


Alex