Language change and code breaks
s713221 at student.gu.edu.au
Sat Jul 21 04:20:18 CEST 2001
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:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'a' is not defined
>>> A = aclass(...)
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: _____ _____
/\ _ __ __ _ | | _ ___ |
/__\|\ || ||__ |\ || |___|/_\|___] |
/ \ \_||__ ||___| \_|! | | \ \ !
More information about the Python-list