Language change and code breaks

[chris liechti]

I find this is a good idea: do the case insensitivity in the environment 
(e.g. IDLE). It's about the same as autocorrecting diffrent cases during 
edit - as proposed in an other message. you will end up having all the 
names in the same case and you don't need python to be case insensitive.


recently i read about two things that could break older code:
-case insensitivity and
-the integer division (/)

i guess such changes threaten the popularity of python. there is much code 
around - up and running or laying around as example - which could fail and 
nobody is interested in going trough that code while he's involved in other 
projects. whats the result? examples:

-what do i say to sombody who's willing to learn a new language but many of 
the example programms fail?

-i think that you realy have to be a huge fan of python to stay with it 
even if you have to change all the old code if you are one of these "a = 
A()" programmers. well most reader of this group would probably stay but it 
givess python an "incopatibility" touch.

-people from scientific and math fields often use "n" and "N" together. or 
"alpha" and "Alpha" because our keyboard has no greek letters. their code 
will need a lot of fixes.

do so many programming errors come from names with the wrong case? is the 
risk of misspelled _worsd_ not as likely? case insenitivity doesn't solve 
that.

don't missunderstand me - i like python. it's the best/most convenient 
language i know... i just think that there are enough other much more 
usefull things to enhance than / and CaSe-(in)SenSitiVitY that do not break 
old code but make the language even more attractive, wider usable and 
faster in the develop/debug cycle.

i say: do case insensitivity and integer-divison (/) warnings in the source 
editor (like M$-Word's online spell checker) and keep python as backwards 
compatible as possible!

chris


ps: couln't a case-insensitive fan not just overrite __getattr__ and 
__setattr__ to be case insensitive at least for class members?


cwebster at nevada.edu (Corran Webster) wrote in news:cwebster-
2007011136180001 at 192.168.0.4:
> 
> I think a far better solution would be a case sensitive language with
> tools that allow the user to enforce uniform case usage.  Having taught
> novice programmers, I can appreciate that case sensitivity can lead to
> problems in that community (although I do not remember it being a major
> obstacle for the students I taught, I can never-the-less see that it may
> have caused some students confusion).
> 
> However, I think that the best way to deal with this is in the tools that
> are provided with the language, such as IDLE, or by providing a case
> insensitive version of the language for a teaching environment.
> 
>> > Nobody wants to see fOo and FOO and foo with the same meaning, but
>> > nobody wants to see foo and FOO and foo at all in the same program
>> > with distinct meanings.  I also don't think the cutesy c=C() makes
>> > for readable code -- at least for this sometime programmer.
>> 
>> Exactly.
> 
> And I have to disagree.  While I don't want to see "oMegA" and "omega"
> *at all* in the same program, I do want "omega" and "Omega" to be able
> to refer to distinct (albeit probably related) objects.
> 



-- 
chris <cliechti at mails.ch>