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

[Martijn Faassen]

benji_york at cal-na.com wrote:
[snip]
> I'm not saying this is enough of a reason to change the language, but I
> definitely see an advantage to not mixing naming conventions in my
> modules just because I want to use someone else’s module that doesn't
> name the same way I do.

> In a production environment this can be quite
> annoying (or it has been for me).

The advantage however when maintaining the code is that I can instantly
recognise word-glyphs (which include the case-spelling in my brain at
least).

> Example of what I would like to be able to do:

[snip]
> Along the same lines; identifiers could also ignore imbedded (not
> leading or trailing) underscores, so I could use dict.HasKey() instead
> of dict.has_key().

Besides my word-glyph problem, that would be terrible for search (and
replace). While searching is often case-insensitivite in editors, it's
definitely not often underscore insensitive, so this could get
very nasty. (even case-insensitivity already ruins the default
'grep', though of course you can use -i to ignore it).

> I think both of these suggestions have /some/ merit. After all,
> identifiers carry meaning, so why not ignore those parts of the
> identifier that carry little or no meaning to the reader.

For some readers however, they do carry meaning. The first letter of a
class being a capital, for instance. The conventions concerning underscores
are more subtle, but there must be several of those floating around as well.

[snip]
> Some have said that this would make it harder for people just learning
> Python, but in training the people where I work (long-time COBOL and
> Fortran guys) I've found that the differences between dict.has_key()
> and HTMLgen.TD() and pickle.dumps() causes some confusion.

But do you want them to introduce their long-time COBOL and Fortran
case spellings in their Python code? Or do you want them to learn
the Python idioms? While case-insensitivity indeed brings a disciplined
programmer more internal consistency in his own code even when using
external modules (question is whether Python's namespaces don't make
this point partially moot), case-insensivity will decrease cross-module
case-consistency significantly. If two people maintain the same
module, you'll also get case-consistency problems.

Trade-offs, trade-offs-ly yours,

Martijn 
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?