Speaking Python

[Mike C. Fletcher]

David Mertz wrote:

>In the endless Lisp/macro threads, Alex Martelli mentioned something a
>bit interesting about screen-reading applications.  Specifically, he
>expressed reservations about whether Python would be a good language for
>visually impaired or blind programmers.
>
>The concern, I think, is that pronouncing
>'space-space-space-space-space-space-space-space' isn't all that easy to
>follow if spoken with every line.  Even a reduced form like
>"eight-spaces' isn't perfect either.  Actually, a symmetric concern is
>with voice recognition applications--perhaps for people with motor
>disabilities.
>  
>
True, which is why we use <tab> for indents religiously, right ;) .  
There's at least a few of us who use voice dictation for writing Python, 
and on those rare instances where the editor doesn't automatically 
indent for me, saying "tab" is quite doable.

>My feeling is that a good vocal Python programming editor would need to
>know a bit about the structure of the language.  
>
This is definitely true.  A "good" vocal editor is a ways off still, likely.

>Maybe to a greater
>degree than would one with explicit delimiters (although I have trouble
>imagining blind programmers being all that happy with hearing
>'close-paren-close-paren-close-paren-close-paren-close-paren-close-paren'
>either).
>
I'd have a similar imagining...

>  Perhaps this same hypothetical editor would speak code and
>recognize spoken code using the same format.
>  
>
That's a good first level, for very precise debugging. If you want to 
make the thing comfortable for reading blocks of text, however, you'll 
want to include a mode (really, dozens of graduated modes) where 
landmarks are included in the spoken text, preferably without breaking 
up the textual stream, more below on this...

>So quick test, how do you say:
>
>    def range_sum(N):
>  
>
    "py-def range underscore sum open-paren number close-paren colon 
new-line"

I don't use single-character variable names because they're more pain to 
dictate than regular English words.  The editor (Pythonwin) indents 
automatically, so I never actually say the tab-keys below, instead what 
I say is "backspace" to dedent from where Pythonwin sets the indentation 
(which only needs to occur once in the entire function here, as 
Pythonwin auto-dedents for returns) but since we're worried about the 
dictation.  What I'd prefer to say is:

    "function range sum, parameter number, new-line"

but that's not happening today :) .

>        if N < 0:
>  
>
    "tab-key if number less-than zero colon new-line"
 

>            return None
>  
>
    "tab-key tab-key return cap None new-line"

>        elif N == 1:
>  
>
    "tab-key elif number py-equal one colon new-line"

>            return 1
>  
>
    "tab-key tab-key return one new-line"

>        else:
>  
>
    "tab-key else colon new-line"

>            tot = 0
>  
>
    "tab-key tab-key total equal-sign zero new-line"

>            for n in range(1,N+1):
>  
>
    "tab-key tab-key for counter in range open-paren one comma number 
plus-sign one close-parent colon new-line"

>                tot += n
>  
>
    "tab-key tab-key tab-key total plus-sign equal-sign counter new-line"

>            return tot
>  
>
    "tab-key tab-key return total new-line"

The thing is, you wouldn't want that being spat back at you if you 
couldn't *see* the code and wanted to know what a function does, that's 
how you dictate it, but it's only useful for very low-level debugging to 
*hear* it that way.  What you'd want is something like:

c> function range <und> sum
u> read that
c> deaf range <und> sum <open-paren> number <close-paren> colon <indent> 
<newline> if number less-than zero colon <indent> <newline> return None 
<newline> <dedent> ...

where each < > item is a configurable sound-effect, likely with 
different levels of abbreviation, so that at the slowest (most careful) 
reading you'd hear "open paren", while at the most cursory reading level 
you'd hear a very short sound-effect that bracketed the words in the 
parenthesis.  Of course, it would be nice if you could change the 
tonality of the voice as well (as humans do when reading parenthesised 
text), but you'd need to be able to handle something like this:

    [ (a.this.them.there(), c.those()) for (a,c) in somewhat.items() ]

without the voice turning into a squeak :) .

Thing is, that even that level still leaves you unable to enjoy most of 
the benefits of Python code (which, really, is a visual thing, letting 
you pick out features so easily from the representation of the text).  
You'd want even more subtle audio clues to do that, whispers in the 
background of the voice giving context e.g. for ifs and elifs, and for 
current indentation levels (really you'd want it naming a suite and 
using that), you'd want the system to properly describe the open and 
close of a parameter list (versus tuple start/end), to point out where 
there are unmatched braces, to generally act as your eyes in 
interpreting the text.  You'd need summary "views" for finding/skimming 
the text, auditory bookmarks and conversational interfaces for defining 
focus...

More abstractly, you want to increase the bandwidth of the audio channel 
so that, as an HCI mechanism, it more closely approximates the richness 
of the WIMP video channel.  That's going to require fairly sophisticated 
control mechanisms for interacting with the system and altering it's 
attempts to present the information.

Of course, I'd guess most blind programmers are *very* good at keeping 
large blocks of text in their head (given current levels of support in 
editors), so they may not want all that at all, a simple "indent" and 
"dedent" might be fine... at least as good as with any of the 
curly-braced languages... seems to me that delimiter/no-delimiter is a 
comparatively minor question once you start wanting to provide a useful 
system.  It's a wonderfully complex HCI design challenge, and 
comparatively, hooking up a Python parser is probably a no-brainer.

$0.02 CDN,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/