Re: case-sensitivity

From: Ron Adam (radam2_at_tampabay.rr.com)
Date: 11/14/03 

Date: Thu, 13 Nov 2003 23:47:48 GMT

On Thu, 13 Nov 2003 14:26:42 GMT, Alex Martelli <aleax@aleax.it>
wrote:

>Ron Adam wrote:
> ...
>> If an option for case insensitivity were implemented it would just be
>> a matter of doing a lower() function on all source code as a first
>> step in the compile process. Then case in the source code need not
>> matter, or you could choose to have it matter if that's what you want.
>> It probably isn't that simple. I haven't looked into the source code
>> far enough yet. Doing so would probably cause errors in existing
>> programs where names do use same spelling/different case for different
>
>And all uses of standard Python modules such as random and fileinput,
>which do exactly that sort of thing systematically.

Also it would need to avoid lowering strings and literals too.

>> Using a case correcting editor is one way of doing it that doesn't
>> change pythons core and lets the programmer choose the behavior they
>> want.
>
>Nope, can't do. Consider:
>
>>>> import random
>>>> x=random.Random()
>>>> y=random.random()
>
>now x and y are two VERY different things:
>
>>>> x
><random.Random object at 0x81aa9d4>

Is this very common, I tried to find other examples of this. Is
there another way to get a base class of an object? Is this different
for different modules, or is it a standard?

>>>> y
>0.93572104869999828
>
>...but how would a poor "case correcting editor" distinguish them...?
>

Something like this where 'word' is a possible name:

if word matches any name in both spelling and case:
        pass # leave it alone
elif word matches a single name, but case is incorrect:
        correct case
elif word matches several names spelled the same, but neither in
correct case:
        give a hint
        get choice from hint
 

>Such a smart editor might HELP a little by SUGGESTING a case-correction
>when it appears unambiguous, even just for standard modules and the
>functions therein. Maybe a menu-command for "suggest case corrections
>if any" WOULD be helpful in IDLE, and offer good cost/benefit ratio as
>a fun, not-too-terribly-hard project reducing human misery a bit...:-).
>
>
>Alex

I think so, especially for people first starting out or switching
from another language.

I think there could different levels of correction/suggestion modes.

None == turn it off

Polite == suggest choices if the case doesn't match, but don't
actually correct anything.

Assertive == Correct when it's obvious to do so, and suggest when
there is more than one choice.

What one would choose would be dependant on how well they know python
and how accurate they type.

_Ron Adam

Relevant Pages

  • Re: Q: Java source and directory structure - standard way ?
    ... > As a matter of fact, ... They visit each source code directory and run "javac *.java" ... compiler to dispense with the directories altogether and build their ... > code based on the package hierarchy; ...
    (comp.lang.java)
  • Re: Writing a Fortran parser...
    ... useful functionality to distribute alongside the compiler. ... In fixed form source code they don't matter, in free form they matter, except ...
    (comp.lang.fortran)
  • Re: anyone interested in decompilation
    ... For blindly recompiling the program, it does not matter. ... The important thing is to get source code ... think of a situation where you absolutely need the original source ...
    (comp.lang.c)
  • Re: case-sensitivity
    ... Then case in the source code need not ... > matter, or you could choose to have it matter if that's what you want. ... And all uses of standard Python modules such as random and fileinput, ... ...but how would a poor "case correcting editor" distinguish them...? ...
    (comp.lang.python)
Loading