Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Speaking Python

Reply
Thread Tools

Re: Speaking Python

 
 
Mike C. Fletcher
Guest
Posts: n/a
 
      10-13-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
>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/




 
Reply With Quote
 
 
 
 
Yvonne Thomson
Guest
Posts: n/a
 
      10-14-2003
At Mon, 13 Oct 2003 17:35:47 -0400,
Mike C Fletcher wrote:
>
> 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.
> >

Hi, guys. As someone who is totally blind, uses speech, and programs in
python, I think I'm probably qualified to talk about this. First, I
might as well say that what I'm using, most people can easily experiment
with if they've got a unixish OS and know how to muck around with
emacs. I'm using the speech interface for that, known as emacspeak.

Strangely enough, python is actually the *easiest* of the languages I've
played with. Admittedly, they're only php and perl, but still, I find
python a far nicer language to program in. I know people call perl
executable line noise, but in my case that's almost literally true. All
those damned punctuation characters are enough to give anyone a
headache, <grin>. In my case, I've got the indent system set up so that,
it sounds something like
indent 4, indent 8, indent 16, etc. It does say this every time you
press your arrow key, but in my experience, that's mostly how I read
code, one line at a time.

I use things like speedbar in emacs, an tags, to jump between functions
and have a look at the overall shape of the code. I can't ever remember
just hitting the command that starts reading a buffer and just listening
to it.

Emacspeak also does do what someone suggested, changing pitch for things
like documentation and keywords which is also quite helpful. I'm afraid
you'll have to ask specific questions for me to actually know what else
to tell you, but I figured I might as well chime in on this.


 
Reply With Quote
 
 
 
 
Alex Martelli
Guest
Posts: n/a
 
      10-14-2003
Yvonne Thomson wrote:
...
> Hi, guys. As someone who is totally blind, uses speech, and programs in
> python, I think I'm probably qualified to talk about this. First, I


Nobody could be more qualified -- welcome, and thanks for speaking up!


> you'll have to ask specific questions for me to actually know what else
> to tell you, but I figured I might as well chime in on this.


It seems all the languages you've used are case-sensitive, so maybe
you don't have relevant experience with the following issue, but I just
thought I'd ask -- isn't case-sensitivity a problem? How does your
setup pronounce things, in order to distinguish, say:
muscat = 23
(assigning 23 to the all-lower-case name muscat) from
musCat = 23
(same but with the name being assigned to having an uppercase instead
of lowercase C in the middle)?


Alex

 
Reply With Quote
 
eichin@metacarta.com
Guest
Posts: n/a
 
      10-14-2003
In <(E-Mail Removed)>, I was pointed at "pindent.py"
as a useful convention for dealing with "silent whitespace" (when I
asked about the same problem - helping a blind coworker [who is a
hardcore C, C++, and perl developer] deal with python code. We
haven't actually had a chance to work together using it, so I don't
know if it actually helps, but since I haven't noticed it mentioned on
this thread...

> Yes. See the script pindent.py in Tools/scripts in your Python
> distribution. It basically closes every intented block with an "end"
> comment. The script can be used both to add this sort of marking, and
> to remove it -- and restore indentation if it has been destroyed.
>
> This, according to the pindent convention,
>
> def foobar(a, b):
> if a == b:
> a = a+1
> elif a < b:
> b = b-1
> if b > a: a = a-1
> # end if
> else:
> print 'oops!'
> # end if
> # end def foobar
>
> is equivalent to
>
> def foobar(a, b):
> if a == b:
> a = a+1
> elif a < b:
> b = b-1
> if b > a: a = a-1
> # end if
> else:
> print 'oops!'
> # end if
> # end def foobar
>
> or even
>
> def foobar(a, b):
> if a == b:
> a = a+1
> elif a < b:
> b = b-1
> if b > a: a = a-1
> else:
> print 'oops!'
>
> Since this script has been in the Python distro for years, it seems
> like the most "standard" convention to adopt, IMO.
>
> --
> Magnus Lie Hetland "Nothing shocks me. I'm a scientist."
> http://hetland.org -- Indiana Jones

 
Reply With Quote
 
Yvonne Thomson
Guest
Posts: n/a
 
      10-15-2003
At Tue, 14 Oct 2003 12:22:41 GMT,
Alex Martelli wrote:
>
> Yvonne Thomson wrote:
> ...
> > you'll have to ask specific questions for me to actually know what else
> > to tell you, but I figured I might as well chime in on this.

>
> It seems all the languages you've used are case-sensitive, so maybe
> you don't have relevant experience with the following issue, but I just
> thought I'd ask -- isn't case-sensitivity a problem? How does your
> setup pronounce things, in order to distinguish, say:
> muscat = 23
> (assigning 23 to the all-lower-case name muscat) from
> musCat = 23
> (same but with the name being assigned to having an uppercase instead
> of lowercase C in the middle)?
>

There are actually a couple of answers to that one. Firstly, if it's my
own code, I've usually got a system for that kind of thing. E.g. I
either use capitials for variables, or I use underscores or dashes, but
I usually have a system. I either capitalise functions, or I don't, and
so on.

If it's someone elses code, they usually also have a system, so you
often don't actually *have* to always look at that kind of thing. If you
*do* need to know, it actually depends on the screen reader you're
using, and the hardware you're using. In my case, muscat is spoken as
one word, whereas, to me, musCat sounds like two words. It's called
split caps in emacspeak, and it means that the system tries to break the
words up so they're separate. Sometimes I have to look, character by
character, to check what's going on, but not as often as you'd think.

You could also set it up so that whenever there's a capital, it beeps to
indicate that, or says cap. E.g. mus-cap-cat. It mostly depends on the
situation, and what you're used to.

Wow, what a longwinded message to explain something farely basic. sorry
about that, <grin>.

 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      10-15-2003
Yvonne Thomson wrote:
...
> You could also set it up so that whenever there's a capital, it beeps to
> indicate that, or says cap. E.g. mus-cap-cat. It mostly depends on the
> situation, and what you're used to.
>
> Wow, what a longwinded message to explain something farely basic. sorry
> about that, <grin>.


Not at all! I find this extremely helpful, and the length of the
message about the workarounds etc does confirm to me that, while you
can and do find good coping strategies, case sensitivity _is_ a
substantial bother here. Just as your previous message about screen
readers and indentation showed, instead, that Python's significant
whitespace is _not_ a substantial bother as I had thought it might be.

Thanks again for your very welcome input!


Alex

 
Reply With Quote
 
John J. Lee
Guest
Posts: n/a
 
      10-16-2003
Yvonne Thomson <(E-Mail Removed)> writes:
[...]
> Wow, what a longwinded message to explain something farely basic. sorry
> about that, <grin>.


Don't worry, you're not in the same *league* as Alex there.


John
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
I want to make English-speaking friend to practic my poor English IchBin Java 1 03-26-2006 05:36 AM
OT: Speaking in Tongues Leo Wong Java 14 06-01-2004 09:27 PM
Choosing Item(s) from JList for speaking danielliuhh@hotmail.com Java 2 01-09-2004 07:57 PM
Speaking Python David Mertz Python 7 10-19-2003 11:46 AM
Re: Speaking Python Tim Churches Python 4 10-17-2003 05:44 AM



Advertisments