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

Paul Boddie paulb at infercor.no
Wed Jun 14 07:12:58 EDT 2000


Phylo Kramer wrote:
> 
> On Fri, 09 Jun 2000, Phil Fraering wrote:
> >Guido van Rossum <guido at python.org> writes:
> >
> >> Yet, here are some of the reasons why I am considering making Python
> >> case-insensitive:
> >>
> >> (1) Randy Pausch, a professor at CMU, found, when teaching Python to
> >> non-CS students in the context of Alice (www.alice.org), that the
> >> number one problem his students were having was to remember that case
> >> matters in Python.  (The number two problem was 1/2 == 0; there was no
> >> significalt number three problem.)

When you have a calculator as the first example of interactive Python (it's the
first thing people are encouraged to do in the tutorial), I would think that the
first problem one is likely to encounter is the 1/2 problem. I still find that
counter-intuitive.

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

I'm not a linguist or cognitive scientist but I think that unless people
remember such names letter-for-letter, they will obviously try and reconstruct
such names using the expectations they already have. Most people refer to the
File Transfer Protocol as "FTP" not "ftp", for example, because it is an
acronym.

In addition to that, many people use "case-forgiving" systems (those which are
either case-insensitive or case-preserving) which might distinguish between
case, but allow references to objects by disregarding the case "patterns" in an
identifier. Example: DOS/Windows filesystems.

> But when I reached into the library for certain modules I had to constantly
> refer to the docs because I could not remember if it was "selectColor" or
> "SelectColor","BaseHTTPServer" or baseHTTPserver".

Yes, some people use Java-style naming: NamesLikeThis for classes, and
namesLikeThis for methods and attributes. Others use what I might call C++-style
naming: names_like_this for everything. This won't cause nasty silent errors if
you just refer to such names incorrectly, though.

> Because Python has such a low learning curve, it seems that many developers
> see it as a macro language for their particular favorite. Java programmers use
> Java conventions, Perl programmers use Perl, TCL for TCL, C++ for C++, etc. In
> the long arduous path to learning any of these languages, a new programmer
> inherits the traditions of the teacher. But with a language that can be
> learned in a day, there is no time to study convention.

Very profound! But it is indeed hard to see a single convention even in the
standard modules.

> Consistency is all that I ask for.

What are the problems with case sensitivity? Remembering the right "pattern" of
upper and lower case letters in order to, amongst other things, avoid
introducing "rogue" variables into code.

What are the problems with case insensitivity? Being aware that some names which
might look very different actually refer to the same thing, because it is the
"pattern" of case in these names which is the only thing distinguishing them.

I would ask people to consider the wider issues. An interesting example is the
English spelling problem for certain names:

  initialize = 0
  ...
  if some_condition:
    initialise = 1
  ...
  if initialize == 1:
    do_something()

How can we solve this problem? Make "z" synonymous with "s"? ;-)

Paul



More information about the Python-list mailing list