Case-sensitivity: why -- or why not?

[Roy Katz]

On Sun, 21 May 2000, Guido van Rossum wrote:

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


Guido,


What I like in Python now is its case-consistency:

  1. strings sare case-sensitive (of course)
  2. import C symbol names are case sensitive
  3. Python modules are case sensitive 
  4. Python's keyword set is case sensitive. 


(1) is a non-issue for me.  I'm happy that "print 'Python'" and 
"print 'python'" output different strings. 

(2) presents a problem:  

Suppose one implements the following: 

     class Node {...}; 
     Node node;

and then registers the structure and the instance with Python's
run-time system (er, just assume).  Now we have two separate 
symbols which differ only by case.  Now assuming that the
run-time Python environment is case-insensitive, and that I
import my module, what would the run-time think I am
referring to? 
    
Case sensitivity on (3) would break the following:

     class A:
       pass
 
     a = A()

But that's a minor nit, IMHO.  It's just that I see so much of this 
code used in small scripts, examples, etc. 

For (4), 

(first, an analogy)
You've mentioned that one of the reasons for Python's asbence of
curly braces is that it limits the amount programmer conventions; for
example, in Python the following would never be an issue: 

   int func( ) { } 

   int func( ) {
   }

   int func( ) 
   {
   }

(this inconsistency tends to drive me nuts for large C functions). 

Python's elimination of braces does away with this. In other words, Python
restricts the programmer, and in doing so, yields more readable code
(it narrows down the quantity of disparate styles and conventions we use).

If Python were made case-insensitive, wouldn't that lead to more
irregular programming conventions?  I would rather introduce a restricted set 
of conventions so that the student wouldn't go on fragmenting
from the norm and developing their own style.  That's one more 
style that I have to get used to when I read their code.  


Roey Katz
comp-eng soph. 
University of Maryland, College Park
USA. 

p.s.  If (4) sounds confusing, tell me.