Re: Seeking feedback from speech users of Python
- From: james.homme@xxxxxxxxxxxx
- To: programmingblind@xxxxxxxxxxxxx
- Date: Mon, 17 Dec 2007 07:42:11 -0500
Hi Jamal,
There already is an Alt+Home keystroke.
Jim
James D Homme, , Usability Engineering, Highmark Inc.,
james.homme@xxxxxxxxxxxx, 412-544-1810
"Never doubt that a thoughtful group of committed citizens can change the
world. Indeed, it is the only thing that ever has." -- Margaret Mead
"Jamal Mazrui"
<empower@xxxxxxxx
t> To
Sent by: programmingblind@xxxxxxxxxxxxx
programmingblind- cc
bounce@freelists.
org Subject
Re: Seeking feedback from speech
users of Python
12/15/2007 06:56
AM
Please respond to
programmingblind@
freelists.org
That's helpful feedback -- thanks.
I knew there were different styles of curly brace indentation and that
information helps me understand the differences. I definately would
want to handle doc strings. I'm open to fine tuning to different brace
styles if this approach is found useful. The initial focus is on speech
rather than braille or magnification users. As such, indenting code
with braces is of little value as far as I can tell. I do not
appreciate code lining up from one line to another -- that is what I'm
trying to avoid the need for. I prefer an opening curly brace at the
end of a line because that means less lines of code to arrow through
than if an opening brace is put on a line by itself. Since Python
simply uses a colon at the end of the opening statement, the current
PyBrace convention seems more consistent with that.
PyBrace is currently left justified and has no more than one consecutive
blank lines. This is intended to maximize efficiency for a speech user.
Pressing Home reliably goes to the beginning of code on a line, rather
than to the beginning of either code or indentation, after which one may
need to move rightward to get to code. One blank line sufficiently
conveys a seperation, especially if comments are also used as appropriate,
so why make a speech user arrow through more than that?
Feel free to continue the discussion -- I'm trying to better explain the
rationale based on personal and reported experience of speech users.
Jamal
On Sat, 15 Dec 2007, Veli-Pekka Tätilä wrote:
> Date: Sat, 15 Dec 2007 13:22:32 +0200
> From: Veli-Pekka Tätilä <vtatila@xxxxxxxxxxxxxxxxxxxx>
> Reply-To: programmingblind@xxxxxxxxxxxxx
> To: programmingblind@xxxxxxxxxxxxx
> Subject: Re: Seeking feedback from speech users of Python
>
> Hello Jamal,
> I haven't used the scripts myself and don't program in Python very much,
> however I do use braces in many langs. I definitely recommend you to
> support at least the Allman style, which makes the braces line up and
> indents the code within them. I use it with magnification, since it
> makes it easy to scan the left and right braces because my magnified
> view port is very very small. I recall several Braille users stating the
> same thing, too, when this came up the last time. I also comment ending
> braces to give more context with speech and sometimes beginning braces
> for short in-line docs, so I would advice you to pay attention to where
> such comments end up in the Python code. Auto including them as doc
> strings for methods might be cool, if no doc string is given. Here's an
> example block of both beginning and ending comments:
>
> sub rgb2hsl
> { # Given an RGB triplet each in 0 .. 255 convert to SL in 0 .. 255 and
> H in 0 .. 360.
> # code
> } # sub
>
> As for other variants, there's something called the Whitesmiths style,
> which is like Allman except that it indents the braces themselves so
> that the code lines up with the braces. This is used in SymbianOS
> programming to my knowledge.
>
> As to compact variants some people make the elsif in an if, elsif,
> elsif, else also line up with the previous right brace, which is called
> cuddling the braces if I heard my speech synth right the other day,
> <smile>. Not sure how common this is, here's again a generic brace
> example:
>
> if(something) {
> some code
> } elsif(other thing)
> some other code
> } else {
> default behavior
> }
>
> Yet another variant I use myself for short if, elsif, elsif structures
> is putting the whole block in a single line immediately following the
> if, elsif or else. This is mainly for switch-like constructs and I would
> urge your code to be tolerant of this. Here's an example from an actual
> program, warning regular expressions ahead:
>
> if(/^\.(.+)$/) { $group = $1; } # Groups of sections, non-standard INI
> extension.
> elsif(/^\[([^[]+)\]$/) { $section = $1 } # Sections in groups.
> elsif(/^(.+?)=(.+?)$/) { $tree->{$group}{$section}{$1} = $2; } #
> Key-val pair, add to struct now.
> else { die "Invalid instrument file.\nLine: $_\n" }
>
> PS: A funny confession: I don't find the PYthon style that bad magnified
> and sometimes actually use a Perl module, which goes from Perl bbraces
> to Python indentation via source filtering. ALl you have to do is to
> say:
> use Acme::Pythonic;
> at the beginning of your code, and the rest of the magic happens behind
> the scenes automatically.
>
> --
> With kind regards Veli-Pekka Tätilä (vtatila@xxxxxxxxxxxxxxxxxxxx)
> Accessibility, game music, synthesizers and programming:
> http://www.student.oulu.fi/~vtatila
>
> Jamal Mazrui wrote:
> >
> > I have included an experimental feature in EdSharp
> > http://www.EmpowermentZone.com/edsetup.exe
> >
> > In seeking a more efficient way of managing the indentation
requirement, I
> > am trying a coding style called PyBrace, where the colon and indented
> > block are replaced by a set of curly braces surrounding the block.
> > Alt+Shift+LeftBracket (think of the brace character) turns either all
or
> > selected text into this style of code, which makes it easy to
understand
> > the structure with speech.
> >
> > The inverse command is called PyDent, Alt+LeftBracket, which converts
from
> > PyBrace format to the equivalent indentation required by the Python
> > interpreter.
> >
> > PyBrace assumes that the opening brace will be at the end of the line
of
> > text that starts the block, and the closing brace will be on a line by
> > itself. Also, PyDent assumes that a single tab character is used for
each
> > level of indentation -- though I intend to support other indentation
> > conventions as well if this approach seems productive.
> >
> > I have been able to convert to and from PyBrace and run a Python script
> > successfully (the Python fruit basket program). If anyone else can try
> > this approach, and let me know your results as well as any other ideas
for
> > improvement, that would be helpful.
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts: