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

[Wolfgang Grafen]

Hi Guido,

I have a suggestion how to get the advantage of case-insensitivity without
it's disadvantages. Hope that I completely understood the problem and that
there is a way to implement my proposal.


> 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.

I am programming VHDL, which is also case-insensitive. We agree that
names should be written with always the same big or small letters but
the compiler doesn't check this as well you cannot rely on it. Just to assure
this elementary condition you would need some kind of lint tool. We use
many second party tools, also our own tools written in Perl and Python or
other Unix shell scripts. Some of the tools are not maintable anymore as
the programmer is not available or as it is on a commercial base.

We have a lot of problems with case-insensitiveness as names of program
units are connected to filenames, which are case-sensitive on a unix file
system. I used to name my files with mixed letter cases for about half a
year when I realised, that one tool couldn't deal with it. Then I had about
one week work to correct the names and sources and do all testing again.

What I don't like with VHDL implementations and case-insensitivity:

- The names are all translated to a norm case, normaly upper-case.
   My name for a port is input_1, but the compiler refers to it as INPUT_1

- When I parse an entity for example I keep the original names in a
   dictionary. This is more complexity especially as there is need for
    rapid programming, one of Python's strengths.

Reasons against case-insensitivity for Python:

- I haven't seen any positive reaction from the Python community.

- Many programs have to be debugged again.

- Case sensitivity is straight-forward and gives better code if you
   agree that names should always be written the same.

- Case sensitivity is even good for education. Mistakes in names
   will produce errors.

- One of my visions is Python will understand (physical )units in
   future, which also addresses an educational issue. Why shouldn't
   it possible to make following calculation:

>>> a= 2 apple + 3 orange + 4 apple + 7 carrot
>>> print a
6 apple + 3 orange + 7 carrot
>>> print number(a)
16
>>> print vegetable(a)
7 carrot
>>> print fruit(a)
6 apple + 3 orange
>>> print number(fruit(a))
9

    as well as use values like:
       10 MHz which is very different from 10 mHz and where
       everybody agrees that you should never write HZ or even hZ for
       the frequency unit!



One problems with mixed case programming:

>>> Orange = 1
>>> orange = 2 + Orange
>>> print Orange
1
which would give the expected result of 3 with case-insensitive programming.

Possible solution:

a) case-insensitivity which has other disadvantages

b) case-sensitivity with the awareness of same names. Just allow

>>> Orange = 1
>>> Orange = 2

but throw an exception when
>>> orange = 3
or
>>> ORANGE = 4 etc.

as well as assume the same (ignore underscores within words)
>>> orange_color
>>> orange__color etc
>>> orangecolor
where only one of this names can be assigned.

a more difficult task is to recognize spelling mistakes:
>>> ornge = 2
>>> oragne =3
>>> orange_colour = "orange"

this behaviour could be invoked by an option or become builtin
and/or can be implemented into the python-aware development
environment (IDE, PythonWorks etc.). The advantage of this in a
Python aware editor is that the mistake can be either corrected on
place or marked.


> (The number two problem was 1/2 == 0; there was no
> significalt number three problem.)
>

That's good.

What's about a significant problem number three?

When programming or reading the input of a non-experienced programmer
who might think  012 is decimal 12 the input will be interpreted as
an octal number. I don't have any solution for this. Maybe there should be
a routine reading from stdin which doesn't interpret 012 as octal number...