Re: Speaking Python

Discussion in 'Python' started by Mike C. Fletcher, Oct 13, 2003.

  1. 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/
     
    Mike C. Fletcher, Oct 13, 2003
    #1
    1. Advertising

  2. 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.
     
    Yvonne Thomson, Oct 14, 2003
    #2
    1. Advertising

  3. 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
     
    Alex Martelli, Oct 14, 2003
    #3
  4. Mike C. Fletcher

    Guest

    In <>, 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
     
    , Oct 14, 2003
    #4
  5. 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>.
     
    Yvonne Thomson, Oct 15, 2003
    #5
  6. 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
     
    Alex Martelli, Oct 15, 2003
    #6
  7. Mike C. Fletcher

    John J. Lee Guest

    Yvonne Thomson <> 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
     
    John J. Lee, Oct 16, 2003
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    408
    Andrew Thompson
    Jan 9, 2004
  2. Leo Wong

    OT: Speaking in Tongues

    Leo Wong, May 30, 2004, in forum: Java
    Replies:
    14
    Views:
    831
    Alan Anderson
    Jun 1, 2004
  3. IchBin
    Replies:
    1
    Views:
    800
  4. David Mertz

    Speaking Python

    David Mertz, Oct 13, 2003, in forum: Python
    Replies:
    7
    Views:
    402
    James Kew
    Oct 19, 2003
  5. Tim Churches

    Re: Speaking Python

    Tim Churches, Oct 13, 2003, in forum: Python
    Replies:
    4
    Views:
    324
    Michael Geary
    Oct 17, 2003
Loading...

Share This Page