Language change and code breaks

[Joal Heagney]

Guido van Rossum wrote:
> 
> > TRuE, tHe ExPRESsiVity oF ThE lANGuaGE is ProBAbLY nOt cRipPled,
> > hOWEvEr, tHere ARe SigNIficantLy FeweR ideNtIFIeRs AVaILABlE whICh mEAns
> > iT is LESs eXPRessIvE. IN pArTicULar, cOMmON Idioms liKE naMiNg CLASseS
> > stArTiNg WiTh UppER cASE lETtERS, AND instaNCeS OF THose cLAsSes
> > begINNiNG with A lOwER caSE LettER CaN NO LongeR Be usED.
> 
> Very funny (not).  You misunderstood the intention.  The programming
> environment should be case-preserving, and automatically correct
> identifiers to use the same case as used when they were defined.

Okay *interested* Does this mean if I do this:

>>> a
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'a' is not defined
>>> A = aclass(...)
>>> a
(returns A)

I'd have to try it out to see what it would be like, but I'd still
prefer if I got an error message when I did the following:
>>> a = anotherclass(...)
Hmmm. I don't know if it would be sensible to be draconian, but if this
did raise an *Error, it would enforce users to avoid the c=C()
convention. Question is, is learning this feature (
"NO. *whack* You can't do c=C()"), bad coding practice that it is,
easier than learning to deal with case-sensitivity?

Hmmmm. My vote is still on more helpful NameError messages that attempt
to track down different-cased variables. It'd be using similar code as a
case-preserving system, but not going as far as returning an instance
which may or may not be the instance that the programmer wants.

Anycase *placing his trust in Guido's expertise*
-- 
      Joal Heagney is: _____           _____
   /\ _     __   __ _    |     | _  ___  |
  /__\|\  ||   ||__ |\  || |___|/_\|___] |
 /    \ \_||__ ||___| \_|! |   |   \   \ !