case sensitivity redux (was Re: Language change and code breaks)

[Bengt Richter]

On Tue, 31 Jul 2001 11:24:18 +0200, "Alex Martelli" <aleaxit at yahoo.com> wrote:
[...]
>One aspect I haven't seen mentioned in this huge thread is the
>issue of visually impaired programmers.  Case sensitivity is an
>extra burden for such people (with whom I strongly empathize: my
>sight is still OK, sufficient to drive a car &c, but it's going
>downhill with time, and I must face the very real possibility
>that I'll be _seriously_ visually impaired a few years from now).
>
>Think of a useful tool for such an audience, a special-purpose
>'screen reader' that will read out loud a snippet of Python code:
>what's the tool going to do about distinguishing upper and lower
>case?  With case being significant, the tool will have to point
>out *every* case change -- a serious bother.  Was case not thus
>significant, the tool could have two modes, a default "smoother"
>mode ignoring case, and a special mode pronouncing case to be
>used only (e.g.) within literal strings.
>
>For those of you who can't really empathize with other's issues
>and misfortunes, imagine being in a situation where you'd often
>need to have source code read out loud to you (e.g. over a
>phone), and/or you'd often want to dictate code (e.g. to some
>kind of voice-recognition, dictation-taking automatic system).
>What's case sensitivity giving you, that would compensate for
>the serious bother it causes in those situations?
>
Most of us have lots to be thankful for, clearly. Shifting case
is also an extra finger dexterity exercise, which is difficult
for some with good sight but other impairments.

Yet I was in the opposition camp, favoring case sensitivity.
I still do, though I am not happy about adding problems for
those who already have more than their share.

I lived a long time with UPPER CASE PROGRAMMING, and felt
as though freed of swaddling when finally i got to use lower case.

Maybe there are some conventions for case usage that would
help in generating sound representations. Punctuation would
probably have to be something like Victor Borge's rendering
inside strings. Otherwise you could have a female voice for
python operators's names, and other words would be spoken in
a male droid voice. For mixed case words, they would be handled
according to category. Strings of names joined underscores
would get a Victor Borge sound effect for underscore between
otherwise normal words. Initial cap could have a distinctive
associated sound at the beginning. Perhaps it could be imagined
as a sound made by a noisy shift key that made a different noise
for press and release. I'd bet you could get good at visualizing
the letters, if the sounds were well chosen and timed. I think
a lot could be done with some imagination.

The other direction is harder, unless you can be a touch typist, I
suppose. I imagine you could learn that with a training program
that gives auditory feedback. Some foundation should fund work on
this (I imagine they already do). The military too could justfiy
funding it on the basis of being able to communicate in the dark
with a keyboard and an earplug. Also for tagging cockpit voice
messages with simultaneous cue sounds for different attributes.
Background sounds can work like background lights of different
colors and other effects ...

[...]
>Offhand, I can easily think of a few identifiers that
>do appear in different cases, e.g. fileinput (the module)
>vs FileInput (the class in module fileinput), but it would
>seem to me that those identifiers would not normally have
>to be entered with case being the *only* distinction (one
>would normally write fileinput.FileInput, so a reasonably
>smart tool might still be able to get the case right for
>each of the two identifiers - or is this requiring too
>much smarts from the tools?).  Maybe, if a _small_ fight
>is needed to ENABLE (as opposed to FORCE:-) use of a
>semi-smart, case-preserving tool, it MIGHT be worth it,
>if the fight be small enough...?

I won't repost the result, but if you want to scan a
directory of .py files,  put the following
on your path and type casecheck.py /dirpath/*py

[oops, that assumes windows with .py association set up.
Well, you know what to do.]

You should get a list of identifiers appearing with
case variations. Not that many, but it shows how
case has actually been used. I changed it not to print
file headers unless it found something.

It's basically an elaboration of Guido's initial (AFAIK) post
of a 5-line snippet to find division operators:

import sys, tokenize
for filename in sys.argv[1:]:
    def tokeneater(type, token, start, end, line, filename=filename):
        if token == "/": print "%s:%d:%s" % (filename, start[0], line),
    tokenize.tokenize(open(filename).readline, tokeneater)

_______________________________________________________________

#casecheck.py
import sys, tokenize, glob, token

symdir={}

def tokeneater(type, tokstr, start, end, line):
    if (type==token.NAME):
	TOKSTR = tokstr.upper()		#should show up for this file
        if symdir.has_key(TOKSTR):
            d = symdir[TOKSTR]
            if d.has_key(tokstr):
                d[tokstr] += 1
            else:
                d[tokstr] = 1
        else:
            symdir[TOKSTR]={ tokstr:1 }
        
for fileglob in sys.argv[1:]:
    for filename in glob.glob(fileglob):
        symdir={}
#        print '----',filename,'----'
        tokenize.tokenize(open(filename).readline, tokeneater)

	header = '---- '+filename+' ----'	
        for key in symdir.keys():
            if len(symdir[key]) > 1:
                if header:
                    print header
                    header = None
                print symdir[key]
_______________________________________________________________