Case sensitivity

[Alex Martelli]

Tim Hochberg wrote:
   ...
>> is apparently way more pronounced than the norm.  But a simple smart
>> editor can fix your complaint most easily, while the displeasure _I_ feel
>> in having x and X be different names isn't so easily fixed;-).
> 
> Are you sure? Many of the python editors (PythonWin comes to mind) do

Yes, I'm sure.  If an idiotic module exposes BOTH x and X as
externally visible names, as the current "case sensitivity" rules
entirely allow said module to do, no smart editor is gonna be
smart enough to tell which one of the two you actually want
each and every time you mention either.

> name completion on items in modules and objects. From this it seems like
> a very short step to an editor that will fix the case of names that you
> type in (querying you if there were multiple options). It certainly

I.e., it would have to query each and every time in this case -- each
and every time I mention idiotmod.x OR idiotmod.X, even if I HAVE
carefully memorized exactly what two features of idiotmod are thus
named.  Puh-LEAZE -- that's no fix, that's a "feature" anybody in
the world would HAVE to turn off after (at most) the 17th time the
silly choice box pops up, to avoid smashing in their monitor.

It's MUCH easier, if blubbomod is allowed to expose only ONE specific
capitalization of X (e.g. because a language is case-insensitive, or
rather case-preserving in a sense), to normalize to that specific
capitalization every mention I make of blubbomod.x OR blubbomod.X in
my code -- no choice box needed (though I might still like an option
to turn the normalization off -- if e.g. I want to impose the
convention that constants are uppercased, and blubbomod.X is meant
to be used as a constant -- but that's a 2nd-order issue).

> could be done in less time than has been collectively spent of this
> discussion.

Try tweaking, e.g., idlefork to do what you propose -- I suspect
we'll at least get a collective laugh out of this.


> P.S. I'm with Terry; mismatched case gives me hives. I could deal with a
> case preserving language where variables that differed only in case were
> outlawed (which I believe is what was under consideration when Guido
> thought about this), but case preserving and ignoring just gives me the
> creeps.

I would have no problem with a rule that *WITHIN ONE SOURCE FILE*
(i.e. within a module) names differing only in case are not allowed.

I would still PREFER to allow one source file to refer to names
in OTHER source files (modules) by the referrer's choice of caps,
because that WOULD allow the referring module's author to "fake"
sound conventions.  E.g., say my module A.py needs to use two
modules from different authors, B.by which names a function
mysweetfunction, and C.py which names another function
MyBitterFunction.  It seems to me that forcing me to keep
reflecting those inconsistent conventions in my own source has
no pluses -- I should be allowed, within A.py, to refer to, say,
B.mySweetFunction and C.myBitterFunction, as I do that in a
fully consistent way *within A.py* I see only pluses.

But, yes, somehow forbidding e.g. B.py from exposing several
names such as mysweetfunction, mySweetFunction AND MysweeTfunction
all at once would already be one first step whose usefulness,
if minor, would still seemlingly be positive (e.g. it might
help smart editors be more useful than annoying, see above).
Now is anybody going to argue that allowing such an example
triplet is GOOD human factors, as opposed to just some fallout
of implementation decisions?-)


Alex