Home Original page

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

Wolfgang Grafen Wolfgang.Grafen at marconicomms.com
Wed Jun 7 04:20:23 EDT 2000 
Tim Rowe wrote:
>>In article <393CCEE6.E5C1C267 at marconicomms.com>,
>>Wolfgang.Grafen at marconicomms.com (Wolfgang Grafen) wrote:
>
> > 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.
>
> I consider that bad behaviour. I have said elsewhere that there are
> programming idioms I consider to be good practice that use case to
> distinguish objects. I'd have no objection to an editor that pointed
out
> to me when I was doing it, but I would consider exceptions to be a
serious
> penalty for no real advantage. Are we going to make C/C++
> and Java case-insensitive, too? Or are these learners going to have to

> come to terms with the fact that "a" <> "A" at some point, and the
sooner
> the better?

That's right. I think the discussion about case-insensitivity arose
because
there is the possibility to program mistakes when misspelling the
variables
without getting any error. It is not a very good idea to restrict the
language
because of this. It is a program mistake which you can discover with
program
external and independant tools. Define some programming style guides,
better give idle / PythonWorks a customiseable style guide pane where
problems like this can be discovered by highlighting etc.

>
>
> > a more difficult task is to recognize spelling mistakes:
> > >>> ornge = 2
> > >>> oragne =3
> > >>> orange_colour = "orange"
>
> The trouble with that is, having been forbidden the use of canvas
after a
> from Tkinter import * (clashes with "Canvas"), now the confounded
thing is
> going to assume aCanvas is a typo, amend it to Canvas and throw it
out!

Make your tool as smart that it discovers both Canvas and canvas was
imported

by Tkinter and are not to be highlighted. But when you try to type
canvaS,
highlight it.

>
> We'd end up with /much/ too restricted a set of identifiers. As a Brit
I
> have enough trouble with color/colour, but I emphatically do /not/
want
> the compiler to tell me I can't use my native spelling of "colour".
>
> "Corrected in place" is a disaster in waiting, by the way. Did anyone
here
> ever use Comal? That "corrected" typo's in place, but as it didn't
know
> what the programmer intended it basically changed to random code. The
> result was that it replaced error messages with hard-to-find bugs.

Well, so don't use this option. For small and independant program units
written by beginners or children it might help.

>
> > 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...
>
> A Python-aware editor can help with this. I set my C++ editor to
highlight
> octal in a different colour to decimal, which makes it easy to spot.

This is not a matter of an editor. I think a programmer knows what he
does
when he writes 012 but if the number is read from <stdin> as an input of

somebody who is not aware that there exists other number schemes than
decimal it definitely is a problem which you can not avoid with an
editor :)
More information about the Python-list mailing list