Yet Another Case Question

rzed Dick.Zantow at
Mon Feb 24 15:05:46 CET 2003

David Mertz, Ph.D. wrote:
> I am aware that this topic is fairly idle--Python most certainly
> will not become case-insensitive, and not even those of us who are
> fond of case-insensitivity in the abstract want such to happen.
> But I think there might still be something to learn here.
> From several posts (including mine), it seems clear that there are
> at least two extremes among people who write programs.  Some of us
> are strongly verbally/phonetically oriented.  I tend to imagine
> keywords, variables, etc. as "word images", i.e. as if a voice in
> my head were speaking them.  Other folks are much more
> visually/eidetically oriented. A keyword of variable is a mark with
> a particular shape, and it is imagined in a geometric style.
> Obviously, most people fall between these extremes; and lacking
> some kind of peculiar brain injuries, probably no one entirely
> lacks in either capability.
> For people like me--near the verbal extreme--case-sensitivity makes
> programming noticably more difficult.  I have explained elsewhere
> the general process by which I reconstruct, and sometimes stumble,
> over the correct case-sensitive spelling of names.  I don't want to
> overstate this matter, of course.  Even if I need to spend some
> extra seconds because of case issues, I am perfectly well able to
> write code despite it.  And in the range of all the little
> obstacles I, or anyone, faces in writing a program, this is only
> one small matter.  Nonetheless, working around case-sensitivity has
> a negative effect that I have described, even if it is a manageable
> one.
> Many of the folks who argue for case-sensitivity perceive the
> negative effect as being small or non-existent.  Quite likely, most
> of them are towards the visual end of things, and the relative
> stumbling block of finding the correct case for a term is less for
> them than for me.
> But in all this latest discussion (and in the prior ones about the
> same matter), I do not think I've really seen any explanation of a
> POSITIVE benefit to case-sensitivity (as a language feature).  I am
> quite willing to believe there are some... but I just don't know
> what they are.

Thank you for the interesting comments and a not unfair challenge. As
others reply, you (and we all) evaluate the responses in light of our
own preferences (the sort that you pointed out above), and I'm sure
we'll find reasons for disagreement in our evaluations as well.

How are case differences used now? Answering that will perhaps shed
some light on why at least the appearance of different cases may seem
important to some of us. Three conventions come to mind: the use of
ALLCAPS for constants; the use of InitialCaps for class names; and the
use of initialLowerCase for instance and method names.

It could be argued that the conventions are unimportant, and that the
distinctions I've listed don't really matter; if that were so, I don't
believe the conventions would have grown up in the first place, and I
don't believe the case-insensitive camp would either offer that
argument or claim it as a benefit. In fact, I believe we can all agree
that the convention I've described is at least plausibly described as
a benefit. The case-insensitive group would say that if it *is*
beneficial, it can *still* exist in a case-insensitive environment.
True enough, but it's not enforced, and there is nothing to prevent
anyone, for whatever reason, from defying the convention. To the
computer, it doesn't matter; to the code's reader, it does. So one
benefit is that it enforces a common coding convention.

Another use of case change is in the camel-case names (such as
InitialCaps), as opposed to initial_caps and initialcaps. I don't
think anyone would argue that alongvariablename is especially easy to
read or to remember (or to type accurately), and either
aLongVariableName or a_long_variable_name is easier to read. Again,
there is nothing about case-sensitivity that compels or forbids any of
these forms, except that differences in representation would not be
ignored by a case-sensitive language. I'm not going to make the
argument that one would choose to type aLoNgVaRiAbLeNaMe, but I *will*
argue that a camel-case version could be typed in all lower-case in a
language-insensitive environment, and it would not necessarily be
noticed until a maintenance programmer took over the code later on.
Does it matter, in that case? Not really. Would the maintenance
programmer correct the spelling? Very possibly. Does *that* matter?
Not if it's a flawless correction. But even if there is no error
introduced by misspelling the correction, you have to wonder whether
you want to encourage a nonproductive change by the maintainer. So one
benefit is that enforcement of the name's spelling at least marginally
reduces maintenance time.

You yourself mentioned the convention of thing = Thing(), and
suggested that another convention could be used instead. This is true.
These are not the only possible conventions, but they are widespread,
and they are low-cost, so to speak. They don't require any additional
characters to establish a connection between class and instance. It
would be possible to use, say, the prefix 'const_' for constants,
'class_' for classes, and so on, but that seems unlikely to catch on
among those of us who type the characters in one at a time. So saying
that another convention could be used raises the further question:
what convention? If it involves encoded prefixes, then I would
question whether it's any easier to remember that convention than it
is to remember the capitalization convention. The benefit (in my view)
goes to Case-sensitivity here.

And I wonder this, by the way: lacking case-sensitivity, the number of
names we use can only increase. This may be a good thing (whew! we
don't have to remember which are capitalized which way!) or a bad
thing (yeegods! we have to remember which convention we're using for
this type of variable!). It seems to me that the case-insensitive
argument is that it is easier to pronounce the names aloud if they
differ by more than just capitalization. A counter to that is that it
is easier to remember the names if they differ only by capitalization.
I personally spend a lot more time using the names than pronouncing
them, and so I will claim this as a benefit for case-insensitivity.


More information about the Python-list mailing list