Is PEP-8 a Code or More of a Guideline?

[Eric S. Johansson]

Paul McGuire wrote:
> At first, Guido seemed ambivalent, and commented on the
> contentiousness of the issue, but it seems that the "non-English
> speakers can more easily find word breaks marked with underscores"
> justification tipped the scale in favor of
> lower_case_with_underscores.


> 
> The PEP itself on www.python.org seems to have been updated as
> recently as May 17 of this year, but I don't seen any way to identify
> what the change history is.
> 
> So, those who are the stewards of the core source code have nailed
> down thier coding standard to be l_c_w_u, so if sometime in the future
> I find myself working on any code in the Python std libs, l_c_w_u is
> the style to be followed.  It just looks so old-fashioned...
> 


link.setParseAction(emitLinkHTML)

is spoken

no caps link dot set no space cap parser no space cap action between parens emit 
no space cap link HTML jump out

on the other hand,

link.set_parse_action (emit_link_HTML)

is much more friendly to aural interfaces.  I've been using speech recognition 
since about 1995 when I was injured thanks to programming in high stress, 
ergonomically poor environments.  as a result, I have become extremely sensitive 
to what makes a good interface for hands and for voice.  Bumpy case words are 
extremely difficult to pronounce for both text-to-speech dependent blind users 
and speech recognition (speech to text) dependent users like myself.  One 
important factor in a speech user interfaces is the difference between what you 
say/here and the target text.  I can't say for the blind user but I know in the 
speech recognition context, the more time you spend thinking about what it is 
you say in order to get your desired text, the less brainpower you have for 
thinking about the problem.

There are solutions to this problem but unfortunately handicapped users are in a 
Catch-22 situation.  We know what we need to make our world better.  But we 
don't have the hands to make our world better.  Therefore we have to rely on 
those who don't know what we need to make our lives better which doesn't happen.

There are two projects (voice coder and vr-mode) which have started making 
things better.  Unfortunately, they are are fragile and difficult to install 
which defeats the purpose of a good accessibility tool.

I suggest that the first option is encouraging enhanced use of full words joined 
by underscores for all public interfaces so that unenhanced speech recognition 
or text-to-speech systems can be used in a way we have become accustomed to 
living with.  This is not to say it's good.  Only that we have acquired enough 
scar tissue to cope.

the second option would be for some of you to dig in and help some of your 
technical kinfolk by improving some tools so that we can start writing Python 
code with greater ease.

A huge reason why this is important because the vast majority of software 
developers who are injured fall off the economic ladder.  They leave the 
profession and had very few options for work that doesn't involve significant 
handy is.  The last time I looked at the numbers, in the US somewhere north of 
60,000 developers per year are injured.  Some recover (kind of). Others, like I 
said, dropout.  Tools to make programming by voice easier and not as damaging to 
the throat as unenhanced speech recognition with bumpy caps symbols, would 
significantly improve the lives of people you probably know and possibly your 
own life in the future.

Feel free to contact me off list if you want.

---eric
(founding member of Open Source Speech Recognition Initiative nonprofit)

warning: NaturallySpeaking in use. It makes mistakes. I correct some.