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

Eric Hagemann ehagemann at home.com
Sun May 21 11:58:03 EDT 2000


-----Original Message-----
From: Guido van Rossum [mailto:guido at python.org]
Sent: Saturday, May 20, 2000 10:02 PM
To: python-list at python.org
Subject: Case-sensitivity: why -- or why not? (was Re: Damnation!)

<snip>

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

<snip>

If the case of variables is the number one problem in teaching a computer
language then the people at CMU must be awesome !  I would think that
concepts like a=a+1 would cause more of a concern than a != A.

I think the real question comes to whether the language needs to be modified
to support education of new programmers or kept the same to support wide use
in industry/acedemia.  How many other mod's or comprmises will be needed to
make the langage palatable to the young and tender.  My humble vote is that
the world is a harsh place -- get over it.  By the time someone makes a case
mistake twice they will have learned their lesson and all will be well

<snip>
<ben at co.and.co> wrote in message
news:fLOV4.54019$jO1.60489 at afrodite.telenet-ops.be...
> [ Lots of things about case-sensitivity and readability already said ]
>
> I don't know about alice, but I think the quest for case-insensivity is
> masking the problem at hand:
>
> class Employee:
>     def __init__(self, salary=0):
>         self.Salary = salary
>     def set_salary(self, salary):
>         self.salary = salary
>
> The problem is: there's no way to check a python program without running
> it, and without variable declarations there's no way to catch errors
> like these. Case-insensitivity is not going to help:
>
>     def set_salary(self, salary):
>         self.Salyry = salary
>

This is actually my concern at the moment.  In typical programming you have
an edit-compile-run cycle that we all know and love/hate.  Scripting lets
you go from edit->run which is fantastic. However problems that were once
detected in the compile stage are now put off into the run stage. While
logic bugs do not typically show up until the code is run anyway, things
like case chages for variables and typo's get caught early in the
development process (usually).  My fat fingers are always getting a variable
mis-typed here or there and often I do not find the typos until I am several
functions deep at run-time.

Not that I am complaining, but perhaps the number one problem is not case
mismatches but actually invention of new variables (due to case
mismatches -- as suggested above)

This is a major point that drew me to Python and away from Perl. In Perl if
you use a variable on the right of an equal sign before it is used on the
left, Perl creates it for you and initializes it to the most logical form of
Null/0/"".  I do not know how many hours I have spent looking for errors
induced by these kinda of 'benifits' of the langauge.  Python on the other
hand puts up a fit if the varable is not first defined by having it on the
left side of the equal sign.  That cuts way down on the errors -- especialy
subtle ones. Score one for Python !

Short of running the code I can not image how one could check it completely,
however I think that the
IDE could go a long way to helping.  Some of the errors are found in the
'compile' stage (which happens at run-time) -- perhaps a 'test compile' can
be done in the IDE to flag such errors.  I think work along these lines
would go a long way to helping _all_ programmers, young and experienced.

As far as typing help in the IDE has anyone notice the VB editor lately.  I
was doing a bit of VB coding  and noticed that as I created variables in the
editor and used the same spelling but different case the editor would 'go
back' to a previously same named variable in the same funtion and modify
it's case as well (spoooooooky!) but perhaps a mode like that (which would
probably cause havoc to some programmers -- so make it optional) could be an
enabler for the young and tender.

As a quick thought, how about the IDE undelining each _new_ variable as
defined in the code.  Perhaps seeing a visual indication of variable
creation might help this problem


Only my 2cents worth

Humbly
Eric





More information about the Python-list mailing list