Case sensitivity

[Martijn Faassen]

Alex Martelli <aleax at aleax.it> wrote:
> 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.

Hm, sometimes I use the following pattern to do "singletons" (without
actually enforcing them):

class FooBarism:
   ...

fooBarism = FooBarism()

could be easily repaired, but is this *idiotic*? May be misguided, but
there's a clear relationship between the class and the instance.
(but perhaps the class really doesn't need to be exported anyway).

> 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.

That seems like a good COMPROMISE POSITION. :) We would lose the 
ability to instantiate a class with its same name, which I'd miss,
but I think I could live with that. As long as modules themselves are
case-consistent.

Regards,

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