Case sensitivity

[John Roth]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:zPt6a.227142$0v.6395578 at news1.tin.it...
> 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?-)

There's one rather obvious exception: a rather large number of
coding convention sets seem to use the same name in mixed
and upper case for two variations on the same thing. Other than
that, I would be very, very happy if the compiler refused to compile
anything with the same name capitalized in more than one way.

I'd even be willing to extend the prohibition to names that only
differed by the presence or absence of internal underscores.

John Roth
>
>
> Alex
>