Mike C. Fletcher
mcfletch at rogers.com
Mon Oct 13 23:35:47 CEST 2003
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
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
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
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"
"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
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.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Python-list