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. -- http://mail.python.org/mailman/listinfo/python-list
