Case-sensitivity: why -- or why not? (was Re: Damnation!)

[Juergen A. Erhard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Guido" == Guido van Rossum <guido at python.org> writes:

    Guido> "Thomas Malik" <340083143317-0001 at t-online.de> writes:

    >> I've just convinced our whole department (at a german bank) to
    >> use Python instead of Perl. A case - insensitive language won't
    >> be acceptable by any of us. So, Guido, should i start looking
    >> for another job ...?

    Guido> This is an example of what I meant when I said "voting
    Guido> doesn't help".

    Guido> You're saying it's unacceptable -- a vote.

No, Thomas just saying it's unacceptable... he also impliest that
he'll take whatever you give him (or he would ask about the
job-searching ;-)

[...]

    Guido> Here's a way to make your vote count: explain what it is
    Guido> about case sensitive languages that you hate.  Then we can
    Guido> have a discussion about it.

You mean case insensitive, right? ;-)

Anyway, I couldn't say why I hated about them... I've never had to
deal with them.  (Emacs-Lisp, Python, C, C++, Modula-2...)

Actually, I couldn't even name a case-insensitive language
offhand... and I doubt they are really easier than case sensitive
ones.

    Guido> I am a very case-sensitive person myself: it bothers me when people
    Guido> don't start their sentences with capital letters or when they refer to
    Guido> themselves as "i" in lowercase -- or when people refer to Python as
    Guido> "python" or "PYTHON".  (Come to think of it, it bothered me when you
    Guido> wrote "german" instead of "German" :-).

    Guido> Yet, here are some of the reasons why I am considering making Python
    Guido> case-insensitive:

    Guido> (1) Randy Pausch, a professor at CMU, found, when teaching
    Guido> Python to non-CS students in the context of Alice
    Guido> (www.alice.org), that the number one problem his students
    Guido> were having was to remember that case matters in Python.
    Guido> (The number two problem was 1/2 == 0; there was no
    Guido> significalt number three problem.)

Did he try a Python that was case-insensitive?  Maybe I'll be proven
wrong, but I highly doubt the problems would have gone away with
case-insensitivity.  (And as someone else in this thread mentioned
(Gordon?), I also think this is cultural... Windows is
case-insensitive, while Linux (and most if not all major programming
languages)).

I just try to imagine Joe Random Python-User using case-insensitive
Python3K, when he tries to read his code again after half a
year... and finds `MyHTTPClass', `Myhttpclass', `myHTTPClass'... I
wouldn't call such code readable.

And if you enforce the same casing... well, you're back at square one.

Here's an idea: why not give Python 3K a switch
`--no-mixed-case-in-identifiers' (on by default for Clue L. Newbie
;-).  Different casings would simply be detected and rejected (in the
compilation phase, of course).

All distributed modules would simply be forced to have to be
case-insensitive (thus only one `SimpleHTTPServer' in
SimpleHTTPServer... when accessing this from a case-sensitive program,
I'd use SimpleHTTPServer anyway, even now.  And in a case-insensitive
program, I'd have to use SimpleHTTPServer).

Of course programs would need to tell the interpreter what case they'd
like to be in (so I can run case-sensitive programs in a
case-insensitive installation).

But that is all pretty pointless... I'm rather for keeping the
case-sensitivity as it is and let people learn a bit (it can't be
*that* hard... we Germans have to learn the difference between `Sie'
and `sie' as little kids, so why can't teenager/young adult Americans?
;-)

    Guido> (2) I've met many people who are experienced and
    Guido> accomplished Python programmers but who still, when
    Guido> referring to Python modules or functions in an informal
    Guido> context (e.g. email), make up their own case conventions.
    Guido> E.g. people will write me about the String module or about
    Guido> FTPLib.

That is also a result of the confusion in actual module names.  I
mentioned {Base,Simple,CGI}HTTPServer above.  But most modules are all
lowercase.

String might come from when someone mentions the string module at the
start of a sentence... or he/she just feels it should be capitalized
when talking about it.

I do *not* think that this is a valid point... because I doubt that
these people would make many of these mistakes in actual code (and
anyway, those (module names) are quickly found).

    Guido> I also know some of the things I plan to do to make the
    Guido> transition painless and to make the usual problems with
    Guido> case insensitivity more palatable.  E.g. I may add a case
    Guido> insensitivity feature to IDLE which makes sure that all
    Guido> identifiers are written in a consistent case, I may add
    Guido> flags to pre-Py3k Python interpreters to turn on case
    Guido> insensitivity or case sensitivity or a special warning
    Guido> mode.

This sounds as if the debate is over and your mind's already made
up... I hope it is not.

Personally, I'd have to give up on Py3K if this happens, and stay with
1.7+ (and I'd bet there'd be a 2.0 then).  It's difficult enough to
switch between languages (Objective-C, Python, Emacs-Lisp, C++
currently for me).  But at least all of them are case-sensitive.

And as hinted at above, I'm all for not dumbing Python down (someone
else mentioned the LCD) but instead teaching the people up.  And
case-sensitivity is really not hardcore computer science.

HTH (me ;-),

Bye, J

- -- 
Jürgen A. Erhard      eMail: jae at ilk.de      phone: (GERMANY) 0721 27326
     MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html
               GTK - Free X Toolkit (http://www.gtk.org)
          Codito, ergo sum - I code, therefore I am -- Raster
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Use Mailcrypt and GnuPG <http://www.gnupg.org/>

iEYEARECAAYFAjknYHgACgkQN0B+CS56qs3uagCfbDiKqk+Dn3INkMQw1AOLcIvV
beEAnR7znvLJpnaZloSs/PsPbxH4h0hD
=Aluv
-----END PGP SIGNATURE-----