Speaking Python

[David Mertz]

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.

My feeling is that a good vocal Python programming editor would need to
know a bit about the structure of the language. 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). Perhaps this same hypothetical editor would speak code and
recognize spoken code using the same format.

So quick test, how do you say:

def range_sum(N):
if N < 0:
return None
elif N == 1:
return 1
else:
tot = 0
for n in range(1,N+1):
tot += n
return tot

It's a stupid function, of course; I just wanted something with a couple
of levels of indents for an example. There's no need to tell me it's
pronouned 'sum-of-range-of-N-plus-one'.

Yours, David...

 

[Sean Ross]

So quick test, how do you say:

def range_sum(N):
if N < 0:
return None
elif N == 1:
return 1
else:
tot = 0
for n in range(1,N+1):
tot += n
return tot

def range underscore sum open bracket n close bracket colon new line indent
if n less than zero colon newline indent
return none newline dedent
elif n equals equals 1 colon newline indent
return 1 newline dedent
else colon newline indent
tot equal zero newline
for n in range open bracket 1 comma n plus 1 close bracket colon newline
indent
tot plus equal n newline dedent
return tot newline dedent
dedent

(this assumes that the user is aware that if no indent or dedent message is
given, the current level of indentation should be maintained).

 

[Emile van Sebille]

So quick test, how do you say:

def range_sum(N):

[snip]

def range underscore sum open bracket n close bracket colon new line

indent

+1, except:
open/close paren= ()
open/close brace = {}
open/close bracket = []

Emile van Sebille
(e-mail address removed)

 

[Sean Ross]

+1, except:
open/close paren= ()
open/close brace = {}
open/close bracket = []

heh. you're right.

I usually say
open/close bracket = ()
open/close curly bracket = {}
open/close square bracket = []
but yeah, parentheses, braces and brackets are just as clear.

 

[Andrew Dalke]

David Mertz:

So quick test, how do you say:

def range_sum(N):
if N < 0:
return None
elif N == 1:
return 1
else:
tot = 0
for n in range(1,N+1):
tot += n
return tot

Here's how I would say it to someone who is typing
for me, given that the person knows some Python syntax
and given an editor which does auto indentation -- the
proverbial man-behind-the-curtains approach to speech
recognition:

Define a new function named range underscore sum which takes
a single parameter, capital N.

If n is less than 0, return none.
If n is 1, return 1
otherwise
start with tot equal to 0 (that's tee-oh-tee; short for the total)
for n, which is lowercase n this time, in range starting at 1 and
going to capital n plus 1 ... close-parens colon newline
tot plus equals lower-case n
backspace once
return tot

This depends on seeing the text as it's typed. I think if I
did this over the phone I would say "if n equals equals 1" and
be a bit more specific about the colons and pressing enter.

Andrew
(e-mail address removed)

 

[Dave Benjamin]

for me, given that the person knows some Python syntax
and given an editor which does auto indentation -- the
proverbial man-behind-the-curtains approach to speech
recognition:

Define a new function named range underscore sum which takes
a single parameter, capital N.

If n is less than 0, return none.
If n is 1, return 1
otherwise

I tried writing this blindly, and almost got the same code except for that
second If, where I got:

if N is 1:
return 1

Two mistakes: 1. due to the lack of "otherwise", I assumed an "if" instead of
an "elif"; 2. the difference between "=", "==", and "is" is important to
nail down.

backspace once

I think "dedent" would be a better choice than "backspace".

 

[rzed]

def range underscore sum open bracket n close bracket colon new
line indent if n less than zero colon newline indent
return none newline dedent
elif n equals equals 1 colon newline indent
return 1 newline dedent
else colon newline indent
tot equal zero newline
for n in range open bracket 1 comma n plus 1 close bracket colon
newline indent
tot plus equal n newline dedent
return tot newline dedent
dedent

(this assumes that the user is aware that if no indent or dedent
message is given, the current level of indentation should be
maintained).

This seems pretty good to me, although I'd let 'colon' imply a
subsequent indent. Line breaks would be indicated by pauses and pitch
changes, which I think would be true in the above as well.

def range underscore sum open paren n close paren colon
if n less than zero colon
return none dedent
elif n equal-equal 1 colon
return 1 dedent
else colon
tot equal zero
for n in range open paren 1 comma n plus 1 close paren colon
tot plus equals n dedent
return tot
dedent
dedent

I would probably use "paren" to mean "open paren" as well, although
explicit might be better there. I once worked as a proofreader, where
one task was to record written material in a fairly stylized manner
similar to this. Punctuation was explicitly pronounced, as was space
where it was unusual. The listeners could generally make the best
sense of the minimum information; too much would slow reading down to
the point that comprehension suffered. Conventions (in reading) that
were usually honored tended to work better than explicit statement of
what was expected.

In code like:
if n < 3: break # don't worry about this stuff
The colon convention above would have to be overridden explicitly, so
it would come out more like Sean's reading.
if n less than three colon no-newline break [ and perhaps, "comment
don't worry about this stuff" ]

 

[James Kew]

def range underscore sum open bracket n close bracket colon new line indent
if n less than zero colon newline indent
[etc]

(this assumes that the user is aware that if no indent or dedent message is
given, the current level of indentation should be maintained).

I'm not sure this is a valid assumption, for two reasons:

a) I'm not sure that sighted readers keep track of the previous indentation
level when reading code: isn't it more the case that the amount of
whitespace at the start of each line gives you an idea of the scope of the
line's statements?

b) It's optimised for the straight read-through, from beginning to end. This
is proably the common case when reading other people's code, but when
editing or debugging your own code you're much more likely to be jumping
around from line to line.

Maybe reading the level of indentation at the start of each line ("indent 2:
if N less-than zero colon / indent 3: return None") would be more useful?

James