pep 8 constants
Brendan Miller
Is all caps meaning "don't reassign this var" a strong enough
convention to not be considered violating good python style? I see a
lot of people using it, but I also see a lot of people writing
non-pythonic code... so I thought I'd see what the consensus is.
Brendan
James Mills
It may in fact be deliberate. As there really are no
such thing as constants in Python - clearly :)
However, on the rare occasion I need to define
a global variable in a module that gets used in
several places and is more or less used as a
standard configured value - I tend to use ALL CAPS.
Still I would avoid using this idiom altogether
and jsut stick with default values. For Example:
FOO = 1
def f(x=FOO):
...
Use this instead:
def f(x=1):
...
cheers
James
Brendan Miller
>
> def f(x=FOO):
> ...
>
>
> Use this instead:
>
> def f(x=1):
> ...
I tend to use constants as a means of avoiding the proliferation of
magic literals for maintenance reasons... Like say if your example of
FOO would have been used in 10 places. Maybe it is more pythonic to
simply denote such a thing as simply a normal variable? That doesn't
seem to give a hint that it shouldn't be assigned a second time.
Steven D'Aprano
> I tend to use constants as a means of avoiding the proliferation of
> magic literals for maintenance reasons... Like say if your example of
> FOO would have been used in 10 places. Maybe it is more pythonic to
> simply denote such a thing as simply a normal variable?
But it isn't a "normal variable", it's a named constant, or at least it
would be if Python enforced constanticity. Or constantness. Or whatever.
> That doesn't
> seem to give a hint that it shouldn't be assigned a second time.
Absolutely. It's rather sad that I can do this:
import math
math.pi = 3.0
I like the ability to shoot myself in the foot, thank you very much, but
I should at least get a warning when I'm about to do so:
math.PI = 3.0 # use God-like powers to change a constant
Changing the laws of physics, one fundamental constant at a time-ly y'rs,
--
Steven
Albert Hopkins
[...]
> Still I would avoid using this idiom altogether
> and jsut stick with default values. For Example:
>
>
> def f(x=FOO):
> ...
>
>
> Use this instead:
>
> def f(x=1):
> ...
That only works well when "1" is only used once, and as an argument to a
function. Once you find yourself outside of that special case then
anytime you want to change "1" to "2" then you're going to regret having
made that decision.
Francesco Bochicchio
>
> Absolutely. It's rather sad that I can do this:
>
> import math
> math.pi = 3.0
>
> I like the ability to shoot myself in the foot, thank you very much, but
> I should at least get a warning when I'm about to do so:
>
> math.PI = 3.0 # use God-like powers to change a constant
>
>
Constants would be a nice addition in python, sure enough.
But I'm not sure that this can be done without a run-time check every time
the constant is used, and python is already slow enough. Maybe a check
that is disabled when running with optimizing flags ?
But I'm sure this discussion has been already made and the FINAL WORD has
been already spoken.
Ciao
----
FB
MRAB
def __setattr__(self, key, value):
if key in self.__dict__:
raise ValueError("Can't change constant")
self.__dict__[key] = value
>>> c = Constants()
>>> c.PI = 3.0
>>> c.PI
3.0
>>> c.PI = 4.0
Traceback (most recent call last):
File "<pyshell#22>", line 1, in <module>
c.PI = 4.0
File "<pyshell#19>", line 4, in __setattr__
raise ValueError("Can't change constant")
ValueError: Can't change constant
Brendan Miller
My original question was about PEP-8 and whether it is pythonic to use
all caps to denote a variable that shouldn't be changed. More of a
style question than a language question.
I actually think *enforcing* constantness seems to go against the
grain of the language so to speek
Steven D'Aprano
Why? Python has an infinite number of constants. The only difference is
that they are immutable objects, not names.
But regardless... yes, it is in my opinion Pythonic to use ALLCAPS to
designate constants (by convention). It isn't in PEP 8, but I don't think
that matters unless PEP 8 suggests a different convention.
--
Steven
Ben Finney
> But regardless... yes, it is in my opinion Pythonic to use ALLCAPS
> to designate constants (by convention).
I agree, in general. Though I think I can count the number of times
I've wanted to use an ‘UPPER_CASE’-named constant in my code, on the
fingers of one foot.
> It isn't in PEP 8, but I don't think that matters unless PEP 8
> suggests a different convention.
It does recommend a contradictory convention:
Global Variable Names
(Let's hope that these variables are meant for use inside one module
only.) The conventions are about the same as those for functions.
The conventions for functions are the familiar ‘lower_case’
conventions. This directly contradicts using ‘UPPER_CASE’ names.
Unless someone's going to argue that “Variable Names” doesn't apply to
constant names, even though Python doesn't make the distinction.
That said, I think upper-case name is a useful convention to
distinguish “this name binding is never expected to change” from the
common case, and wouldn't argue against its use. Perhaps I'd even
argue for an update to PEP 8 that endorses this as conventional.
--
\ “I was born by Caesarian section. But not so you'd notice. It's |
`\ just that when I leave a house, I go out through the window.” |
_o__) —Steven Wright |
Ben Finney
Rhodri James
<bignose+h...@benfinney.id.au> wrote:
> Unless someone's going to argue that “Variable Names” doesn't apply to
> constant names, even though Python doesn't make the distinction.
Python doesn't make the distinction, which is precisely why making the
distinction through CONVENTIONAL_NAMING_PRACTICE is useful.
--
Rhodri James *-* Wildebeeste Herder to the Masses
Aahz
I've posted to python-dev requesting clarification; you may want to
subscribe to follow the discussion yourself.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Weinberg's Second Law: If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would destroy civilization.
Aahz
Now it does! See
http://www.python.org/dev/peps/pep-0008/
Thanks for bringing this up!
Terry Reedy
>
>
> On Thu, Jan 22, 2009 at 1:16 AM, Aahz <aa...@pythoncraft.com
> <mailto:aa...@pythoncraft.com>> wrote:
>
> In article <mailman.7174.1231915...@python.org
> <mailto:mailman.7174.1231915...@python.org>>,
> Brendan Miller <catp...@catphive.net
> <mailto:catp...@catphive.net>> wrote:
> >
> >PEP 8 doesn't mention anything about using all caps to indicate a
> constant.
>
> Now it does! See
> http://www.python.org/dev/peps/pep-0008/
>
> Thanks for bringing this up!
>
>
> follow PEP 8, should we expect them to change at some point in the future?
They are natural rather than arbitrary constants that I usually see in
caps, so I could see them as being in a different subcategory.
Brian Allen Vanderburg II
> Constants would be a nice addition in python, sure enough.
> But I'm not sure that this can be done without a run-time check every time
> the constant is used, and python is already slow enough. Maybe a check
> that is disabled when running with optimizing flags ?
>
> But I'm sure this discussion has been already made and the FINAL WORD has
> been already spoken.
>
> Ciao
> ----
> FB
> http://mail.python.org/mailman/listinfo/python-list
>
One idea to make constants possible would be to extend properties to be
able to exist at the module level as well as the class level:
@property
def pi():
return 3.14159.....
print(pi) # prints 3.14159....
pi=32 # Raise an error Cannot set attribute ...
Brian Vanderburg II
Steve Holden
> boc...@virgilio.it wrote:
>> Constants would be a nice addition in python, sure enough.
>> But I'm not sure that this can be done without a run-time check every
>> time
>> the constant is used, and python is already slow enough. Maybe a check
>> that is disabled when running with optimizing flags ?
>>
>> But I'm sure this discussion has been already made and the FINAL WORD has
>> been already spoken.
>>
>> Ciao
>> ----
>> FB
>> http://mail.python.org/mailman/listinfo/python-list
>>
> One idea to make constants possible would be to extend properties to be
> able to exist at the module level as well as the class level:
>
> @property
> def pi():
> return 3.14159.....
>
> print(pi) # prints 3.14159....
> pi=32 # Raise an error Cannot set attribute ...
>
__math__.pi>, or whatever.
property would clearly have to do something very different in module
scope in order to make this work.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Benjamin Peterson
>
>
> On Thu, Jan 22, 2009 at 1:16 AM, Aahz <aahz <at> pythoncraft.com> wrote:In
article <mailman.7174.1231915778.3487.python-list <at> python.org>,
> Brendan Miller <catphive <at> catphive.net> wrote:>>PEP 8 doesn't mention
anything about using all caps to indicate a constant.Now it does!
Seehttp://www.python.org/dev/peps/pep-0008/Thanks for bringing this up!
>
> Since the constants in the std lib (like math.pi and math.e) no longer follow
PEP 8, should we expect them to change at some point in the future?
No, I don't think so. These are already well known as constants. Besides it
would break backward compatibility for little gain.
Steve Holden
>>>> But I'm not sure that this can be done without a run-time check every
>>>> time
>>>> the constant is used, and python is already slow enough. Maybe a check
>>>> that is disabled when running with optimizing flags ?
>>>>
>>>> But I'm sure this discussion has been already made and the FINAL
>>>> WORD has
>>>> been already spoken.
>>>>
>>>> Ciao
>>>> ----
>>>> FB
>>>
>>> able to exist at the module level as well as the class level:
>>>
>>> @property
>>> def pi():
>>> return 3.14159.....
>>>
>>> print(pi) # prints 3.14159....
>>> pi=32 # Raise an error Cannot set attribute ...
>>>
>>
>> I don't understand why this would print 3.14159 ... instead of <function
>> __math__.pi>, or whatever.
>>
>> property would clearly have to do something very different in module
>> scope in order to make this work.
>>
>> regards
>> Steve
>
> ... @property
> ... def pi(self):
> ... return 3.141596
> ...
> --> testee = tester()
> --> testee.pi
> 3.1415959999999998
>
> Looks like that's how property works, so the same behavior on a module
> level would do as Brian suggests.
But that's at the class level, not the module level.
Ethan Furman
>>>But I'm not sure that this can be done without a run-time check every
>>>time
>>>the constant is used, and python is already slow enough. Maybe a check
>>>that is disabled when running with optimizing flags ?
>>>
>>>But I'm sure this discussion has been already made and the FINAL WORD has
>>>been already spoken.
>>>
>>>Ciao
>>>----
>>>FB
>>
>>able to exist at the module level as well as the class level:
>>
>>@property
>>def pi():
>> return 3.14159.....
>>
>>print(pi) # prints 3.14159....
>>pi=32 # Raise an error Cannot set attribute ...
>>
>
> I don't understand why this would print 3.14159 ... instead of <function
> __math__.pi>, or whatever.
>
> property would clearly have to do something very different in module
> scope in order to make this work.
>
> regards
> Steve
--> class tester(object):
... @property
... def pi(self):
... return 3.141596
...
--> testee = tester()
--> testee.pi
3.1415959999999998
Looks like that's how property works, so the same behavior on a module
level would do as Brian suggests.
--
~Ethan~
Gabriel Genellina
escribió:
Note that:
- you defined the property inside the *class* tester
- then, you created an *instance* of such class
- you retrieve pi from the instance
- if you retrieve pi from the class (tester.pi), you get a property
object, not a float.
- if you directly attach the property to the instance, testee.pi returns
a property object, not a float.
Finally, consider that modules are instances of type `module`; all modules
are instances of the same type.
How do you propose to make properties work at the module level?
--
Gabriel Genellina
Steve Holden
obvious I had completely missed.
Bruno Desthuilliers
Most - if not all - of the python code I've seen so far used this
convention, and I always used (and respected) it myself.
Bruno Desthuilliers
(snip - about using ALL_CAPS for pseudo-constants)
> Perhaps I'd even
> argue for an update to PEP 8 that endorses this as conventional.
+1
I've been a bit surprised last time I checked PEP8 to find out this
wasn't already the case - I would have sweared it was.
Bruno Desthuilliers
> boc...@virgilio.it wrote:
>> Constants would be a nice addition in python, sure enough.
>> But I'm not sure that this can be done without a run-time check every
>> time
>> the constant is used, and python is already slow enough. Maybe a check
>> that is disabled when running with optimizing flags ?
>>
>> But I'm sure this discussion has been already made and the FINAL WORD has
>> been already spoken.
>>
>>
> able to exist at the module level as well as the class level:
>
> @property
> def pi():
> return 3.14159.....
>
> print(pi) # prints 3.14159....
> pi=32 # Raise an error Cannot set attribute ...
>
There are a couple problems with this suggestion:
- it would require modifying lookup rules to allow the protocol
descriptor to be invoked on instance attributes[1] - which is not
actually the case, by design.
- it adds the overhead of a method and a function call for what is
mostly a simple "constant" attribute lookup.
FWIW, while it would already work for class-level pseudo-constants
(using a very simple custom descriptor), I'd qualify such usage as a WTF.
Bruno Desthuilliers
> Steve Holden wrote:
>> Brian Allen Vanderburg II wrote:
>>
>>> One idea to make constants possible would be to extend properties to be
>>> able to exist at the module level as well as the class level:
>>>
>>> @property
>>> def pi():
>>> return 3.14159.....
>>>
>>> print(pi) # prints 3.14159....
>>> pi=32 # Raise an error Cannot set attribute ...
>>>
>>
>> I don't understand why this would print 3.14159 ... instead of <function
>> __math__.pi>, or whatever.
>>
>> property would clearly have to do something very different in module
>> scope in order to make this work.
>>
>
> ... @property
> ... def pi(self):
> ... return 3.141596
> ...
> --> testee = tester()
> --> testee.pi
> 3.1415959999999998
>
> Looks like that's how property works, so the same behavior on a module
> level would do as Brian suggests.
s/module/instance/
At runtime, modules are instances of the module type - so 'module-level'
names are really instance attributes of the module instance -, and the
descriptor protocol is only invoked for class attributes.
Robin Becker
existing module
>>> import reportlab
>>> reportlab.__class__
>>> class MyModule(reportlab.__class__):
... @property
... def pi(self):
... return 3
...
>>> z=MyModule('reportlab')
>>> z.__dict__.update(reportlab.__dict__)
>>> z.pi
3
>>> import sys
>>> sys.modules['reportlab']=z
>>> del reportlab
>>> import reportlab
>>> reportlab.pi
3
>>> reportlab.pi=4
Traceback (most recent call last):
File "<interactive input>", line 1, in <module>
AttributeError: can't set attribute
>>>
so I guess if you write your own module class and then use a special importer
you can create module like objects with read only attributes.
--
Robin Becker
Bruno Desthuilliers
> well this sort of awful hackery will allow you to put read only
> constants on an existing module
>
>
> so I guess if you write your own module class and then use a special
> importer you can create module like objects with read only attributes.
>
Fine technical solution. But, err, isn't all this a bit overkill for
something that can easily be handled by a simple convention ?-)
Robin Becker
no dispute about that :)
--
Robin Becker
Rhodri James
It is. Aahz added it a few weeks ago.
Ethan Furman
> Gabriel Genellina wrote:
>
>>En Tue, 24 Feb 2009 22:52:20 -0200, Ethan Furman <et...@stoneleaf.us>
>>escribió:
>>
>>
>>>
>>>>Brian Allen Vanderburg II wrote:
>>>>
>>>>
>>>>>One idea to make constants possible would be to extend properties to be
>>>>>able to exist at the module level as well as the class level:
>>>>>
>>>>>@property
>>>>>def pi():
>>>>> return 3.14159.....
>>>>>
>>>>>print(pi) # prints 3.14159....
>>>>>pi=32 # Raise an error Cannot set attribute ...
>>>>>
>>>>
>>>> I don't understand why this would print 3.14159 ... instead of
>>>><function
>>>>__math__.pi>, or whatever.
>>>> property would clearly have to do something very different in module
>>>>scope in order to make this work.
>>>> Steve
>>>
>>>--> class tester(object):
>>>... def pi(self):
>>>...
>>>--> testee = tester()
>>>--> testee.pi
>>>3.1415959999999998
>>>
>>>Looks like that's how property works, so the same behavior on a module
>>>level would do as Brian suggests.
>>
>> - you defined the property inside the *class* tester
>> - then, you created an *instance* of such class
>> - you retrieve pi from the instance
>> - if you retrieve pi from the class (tester.pi), you get a property
>>object, not a float.
>> - if you directly attach the property to the instance, testee.pi
>>returns a property object, not a float.
>>Finally, consider that modules are instances of type `module`; all
>>modules are instances of the same type.
>>
>>How do you propose to make properties work at the module level?
>>
>
> Thanks, Gabriel. I was beginning to think there was something terribly
> obvious I had completely missed.
>
> regards
> Steve
Yes, Thanks, Gabriel!
You're extra comments made clarified the issue for me. Much appreciated.
~Ethan~
Eric S. Johansson
> Brendan Miller a �crit :
I reject this convention because any form of caps significantly increases vocal
load for disabled programmers using speech recognition through extra utterances,
and degraded recognition.
In my experience, language conventions like this come about because most geeks
generally don't think about disabled programmers and the effect that language
changes will have on them. I deal by trying to build my accessibility tools as
best I can but handling stuff like pep 8 is hard because it requires a smart
environment that know the meanings of every class, method. or variable so it can
lead the grammar in the right direction. ThenWenUHve names like this. Cr** in a
stick. you might as well take a gun to my wrists because that is how much pain
I will be in typing them. again need *good* editor support for English to name
translation.
so I reject pep 8 because I have no voice safe alternative
Rhodri James
wrote:
> I reject this convention because any form of caps significantly
> increases vocal
> load for disabled programmers using speech recognition through extra
> utterances,
> and degraded recognition.
Reject away, but I'm afraid you've still got some work to do to
convince me that PEP 8 is more work for an SR system than any other
convention. If, on the other hand you're trying to convince me that
*no* convention is preferable, I'm going to laugh hollowly.
--
Rhodri James *-* Wildebeest Herder to the Masses
Steven D'Aprano
> Bruno Desthuilliers wrote:
>> Brendan Miller a écrit :
>>> PEP 8 doesn't mention anything about using all caps to indicate a
>>> constant.
>>>
>>> Is all caps meaning "don't reassign this var" a strong enough
>>> convention to not be considered violating good python style? I see a
>>> lot of people using it, but I also see a lot of people writing
>>> non-pythonic code... so I thought I'd see what the consensus is.
>>
>> Most - if not all - of the python code I've seen so far used this
>> convention, and I always used (and respected) it myself.
>
> I reject this convention because any form of caps significantly
> increases vocal load for disabled programmers using speech recognition
> through extra utterances, and degraded recognition.
[...]
> so I reject pep 8 because I have no voice safe alternative
And you are perfectly entitled to.
That puts you at a disadvantage if you wish to submit code for the
standard library, where PEP 8 compliance is required, but for your own
code you are entitled to use whatever conventions you prefer.
--
Steven
Eric S. Johansson
> Reject away, but I'm afraid you've still got some work to do to
> convince me that PEP 8 is more work for an SR system than any other
> convention.
Name <cap>name
higher than normal recognition error rate. can require multiple tries or hand
correction
MultiWordName <cap>mulit<no-space><cap>word<nospace<cap>name
very high error rate. many retries or hand hurting typing.
multi_word_name multi<underscore>word<underscore>name
normal error rate (low), can need multiple tries or hand correction
StdlYCps <cap>sierra tango delta lima <cap>yankee <cap>charley papa sierra
*** very high error rate *** search and replace for all instances with a x_y_z
form name is recommended
If, on the other hand you're trying to convince me that
> *no* convention is preferable, I'm going to laugh hollowly.
no, I know the value if convention when editors can't tell you anything about
the name in question. I would like to see more support for disabled programmers
like myself and the thousands of programmers injured every year and forced to
leave the field. seriously, there is no money in disability access especially
for programmers. and forgive me if this comes off sounding like a jerk but if
the collective you don't give a sh** about your fellow programmers, who will?
should all disabled programmers be dumped on the shelf even their brains are
still good and they have guts to try to work in a field that gave them a life
rearranging injury?
please help. the disability access you help build may save your own job
someday. Or, what I need to edit code may make your world better as well.
alex23
> the name in question. I would like to see more support for disabled programmers
> like myself and the thousands of programmers injured every year and forced to
> leave the field. seriously, there is no money in disability access especially
> for programmers.
Well, if we can't use conventions like uppercasing, camelcasing and
underscoring, what are you recommending we do instead?
You seem to be asking us to change our behaviour to benefit only
others, but without offering any guidance on to how that is possible.
More importantly, shouldn't these modifications to common conventions
be coming _from_ the community of disabled programmers? I have a hard
time ensuring that I've gotten accurate requirements from co-workers
with whom I can actually see and speak, trying to determine how I
could write my code with accessibility in mind without any established
means of gauging success just seems impossible.
> and forgive me if this comes off sounding like a jerk but if
> the collective you don't give a sh** about your fellow programmers, who will?
This isn't intended to be callous, as I feel that the collective
doesn't care as a whole about _any_ programmers, but isn't the answer
the very same disabled programmers for whom accessibility is an issue?
Programming tends to be needs driven (which, admittedly, can be simply
"to pay the bills"), and those who have a need tend to be better at
working out how to address it.
One possibility may be to approach a group for whom accessibility is
already a consideration, such as the Gnome Accessibility Project:
http://live.gnome.org/GAP
As they are already developing Python-based accessibility tools for
Gnome - http://live.gnome.org/Accessibility/PythonPoweredAccessibility
- it wouldn't be a big stretch to start addressing coding
accessibility within that scope, either as part of the project or as
an independent adjunct to it, especially if someone with domain
knowledge volunteered ;)
Peter Otten
> MultiWordName <cap>mulit<no-space><cap>word<nospace<cap>name
> very high error rate. many retries or hand hurting typing.
Can you define macros in your speech recognition software?
<cap>multi<camel>word<camel>name
might slightly lower the error rate.
Peter
Rhodri James
wrote:
> Rhodri James wrote:
>
>> Reject away, but I'm afraid you've still got some work to do to
>> convince me that PEP 8 is more work for an SR system than any other
>> convention.
>
[snip sundry examples]
Yes, yes, recognition systems need both training and a careful selection
of words to recognise to be effective. This I learned twenty years ago:
if "cap" has a high failure rate, use something else.
As far as I can tell, the only thing that you are even vaguely suggesting
for convention use is underscores_with_everything. As promised, I laugh
Tim Chase
>> convince me that PEP 8 is more work for an SR system than any other
>> convention.
>
> higher than normal recognition error rate. can require multiple tries or hand
> correction
>
> very high error rate. many retries or hand hurting typing.
>
> normal error rate (low), can need multiple tries or hand correction
It sounds like the issue should be one of making your
screen-reader smarter, not dumbing down Python conventions. I
don't know what SR you're using (Jaws? Window Eyes? yasr?
screeder? speakup? VoiceOver?) but it sounds like at least for
the above cases, along with the PEP-8 MULTI_WORD_NAME constant
convention, a simple regexp+transformation should be able to
reprocess the input into something easier to
handle/hear/understand. I'm not sure any/all of the
previously-listed screen-readers give such regexp transformation
control, but I would expect that at least the OSS ones (yasr,
screeder, & speakup) it would be possible to add the feature if
it doesn't already exist. For these three, you might ping the
blinux mailing list to see if anybody there knows how to
implement such transforms.
> StdlYCps <cap>sierra tango delta lima <cap>yankee <cap>charley papa sierra
>
> *** very high error rate *** search and replace for all instances with a x_y_z
> form name is recommended
As for StuDlyCaps, it's hard on the seeing too, so I advocate a
firm smack on the back of the head for those that prefer this
abomination. :-)
-tkc
Eric S. Johansson
Yes it would. I think it would be possible to specify a better grammar however.
In the context of speech engine, if you know how the word is going to be used,
(i.e. it's a method, it's a class, etc.) you can automatically do the
transformation as part of the editors function. You need to know where you are
in the syntax tree and that gives you enough knowledge to do the name
transformation.
When you stop thinking of speech recognition interactions as discrete macros or
magic tricks, you can do a lot to accelerate coding.
Fruit equals pear tree sub branch plus 5
The translator should know that the name on the lval is a variable (type
signature determined later) and is terminated by the word equals (or =). The
system would then apply the appropriate the name transformation. Continue on,
equals would be transformed =, pear tree would be considered a complete name and
based on whether it is a class definition or instance, would be transformed as a
single name. Sub means there's an index here and would put the appropriate
brackets between the expression branch (symbol terminated by plus) and 5 (symbol
terminated by the end of line,
fruit = pear_tree[branch+5]
The next challenge comes in editing. It's fairly simple I would like to say
"edit line [1*<digits>]" and put that line in an isolated buffer where I can
edit the English form using all of the Select-and-Say controls.
That should close the cycle from creation through editing. a small port of the
development cycle.
fyiw, the symbol trandformation code exists and has existed for almost 10 years.
we need smart editing environments to make use of it.
Eric S. Johansson
> "Eric S. Johansson" <e...@harvee.org> wrote:
>> no, I know the value if convention when editors can't tell you anything about
>> the name in question. I would like to see more support for disabled programmers
>> like myself and the thousands of programmers injured every year and forced to
>> leave the field. seriously, there is no money in disability access especially
>> for programmers.
>
> Well, if we can't use conventions like uppercasing, camelcasing and
> underscoring, what are you recommending we do instead?
help build a smart editing environment please.
>
> You seem to be asking us to change our behaviour to benefit only
> others, but without offering any guidance on to how that is possible.
> More importantly, shouldn't these modifications to common conventions
> be coming _from_ the community of disabled programmers? I have a hard
> time ensuring that I've gotten accurate requirements from co-workers
> with whom I can actually see and speak, trying to determine how I
> could write my code with accessibility in mind without any established
> means of gauging success just seems impossible.
Extremely valid point. The behavior I'm asking you to change is to consider the
impact choices you make have on people with disabilities. I can only advocate
for disabled programmer since I am one. Have been so for over 15 years. Have
tried to maintain my position as architectural expert only to receive from
venture capitalists and the likes "what good are you, you can't know enough to
design our systems because you can't code" (yes, real quote). This is not always
the case but enough that it really hurts my economics as well as the economics
of other disabled programmers.
Back in early 2000, I ran a series of workshops on the very issue of programming
by voice. Back then we recognized the necessity for very smart editing
environments which can tell us enough about what each symbol means so that we
can direct the appropriate transformations from a higher-level grammar. I've
introduce concepts such as command disambiguation through reduction of scope.
Other people have added very good ideas with regards to usability and user
interfaces for speech driven environment. Unfortunately, they all are gluons to
an editor and they don't really integrate well because the editor isn't smart
enough.
Heck, have you ever noticed how most Python smart editors can't even indent
properly according to local contexts. Emacs is the only one and even that one
sometimes fails
I can give you guidance as to what needs to be done. Other people can give
guidance but I'm shooting for what may seem unachievable. Work with me a while
and I will guide you as to how it's achievable. Maybe not by you but by someone
we can find. I have lived way too many years with circus tricks. I don't want to
end my life realizing I wasted my time in IT and regretting that I didn't take
up the offer by mass rehab to go in restaurant or hotel management.
one thing you can do to get a feel for out life is to get a copy of Naturally
Speaking standard (100$ staples) and remove/cover keyboard. write email etc at
first (10h) then try to write pep8 code. note to anyone who tries this, I'll
support you in getting DNS running and help figure out any problems. only cost
is if I tell you to do something like get a new mic, *do it*.
I've lived this works and probably have put more deep thought and 8kloc into it
because I do not accept circures tricks as a way of life. I want it to work
right and I know how to do it. I just don't have the hands and hte money to pay
me to do it.
>
>> and forgive me if this comes off sounding like a jerk but if
>> the collective you don't give a sh** about your fellow programmers, who will?
>
> This isn't intended to be callous, as I feel that the collective
> doesn't care as a whole about _any_ programmers, but isn't the answer
> the very same disabled programmers for whom accessibility is an issue?
> Programming tends to be needs driven (which, admittedly, can be simply
> "to pay the bills"), and those who have a need tend to be better at
> working out how to address it.
yup how long will i be before you become disablesd? maybe not as badly as I am
but you should start feeling some hand problems in your later 40's to early 50's
and it goes down hill from there. self preservation/interest comes to mind as a
possible motive for action. I thought 15 years would be enough for somebody
else to push the isssue but no. if it is going to be, it has to be me.
>
> One possibility may be to approach a group for whom accessibility is
> already a consideration, such as the Gnome Accessibility Project:
> http://live.gnome.org/GAP
not right focus for this project. tis one needs **deep** python knowledge (gvr
level) and embedding it into an editor. heck, maybe we need a python
interpreter in the editor to resolve some of the symbol stuff if we can get
useful data from incomplete code.
and I'll leave you an editor feature that may be usefull for all
symbol not defined: choose from list or create new.
I'll explain later.
thanks for you thoughtful reply.
Eric S. Johansson
It sounds like the issue should be one of making your screen-reader
> smarter, not dumbing down Python conventions. I don't know what SR
> you're using (Jaws? Window Eyes? yasr? screeder? speakup?
Naturally speaking is speech recognition (speech in text out) it is not text to
speech although it does have a pluging for that
Ethan Furman
>
> yup how long will i[t] be before you become disablesd? maybe not as badly as I am
> but you should start feeling some hand problems in your later 40's to early 50's
> and it goes down hill from there. self preservation/interest comes to mind as a
> possible motive for action. I thought 15 years would be enough for somebody
> else to push the isssue but no. if it is going to be, it has to be me.
For anyone who is still able to use their hands for typing, especially
if you're beginning to encounter the painful wrists, consider switching
to a Dvorak layout. It was a system I was curious about even before I
needed it, and when I did need it I was able to create the layout in
assembler (now, of course, it's widely available as a standard keyboard
layout). I started noticing the pain in my late twenties (aggravated,
I'm sure, by arthritis), but with switching to Dvorak the pain left and
has only very rarely been noticable again. It will mostly likely be a
challenge to switch, but well worth it.
http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard
~Ethan~
Eric S. Johansson
a good suggestion but not really addressing the point I'm trying to make of
building a system that would help people more profoundly injured. for example,
I've tried Dvorak and the act of typing was so painful that I couldn't learn it
Eric S. Johansson
> On Mon, 29 Jun 2009 06:07:19 +0100, Eric S. Johansson <e...@harvee.org>
> wrote:
>
>> Rhodri James wrote:
>>
>>> Reject away, but I'm afraid you've still got some work to do to
>>> convince me that PEP 8 is more work for an SR system than any other
>>> convention.
>>
>
>
> Yes, yes, recognition systems need both training and a careful selection
> of words to recognise to be effective. This I learned twenty years ago:
> if "cap" has a high failure rate, use something else.
A more profitable way would be to build a framework doing the right job and not
trying to make it happen by side effect and "speaking the keyboard". Speaking
the keyboard is whenever you force someone to go through gyrations to adjust
spacing, case or special single character assertions (i.e.;).
>
> As far as I can tell, the only thing that you are even vaguely suggesting
> for convention use is underscores_with_everything. As promised, I laugh
> hollowly.
I'm sorry. It may have been too subtle. I'm suggesting a smart editor that can
tell me anything about any name in the body of code I'm working or anything I've
included. with that kind of tool, I can have a command grammar that is much
friendlier to the voice and gets work done faster than typing.things such as:
what is this name?
it's a class.
What are its methods?
tree
branch
root
root template plea
se
.root(howmany=1, branches=3, nodes={})
and the query can go from there.
Using tools like these, one can keep pep-8 conventions and not create a
discriminatory environment.
Rhodri James
wrote:
Could you elucidate a bit? I'm not seeing how you're intending to keep
PEP-8 conventions in this, and I'm not entirely convinced that without
them the smart editor approach doesn't in fact reduce your productivity.
Steven D'Aprano
> alex23 wrote:
>> "Eric S. Johansson" <e...@harvee.org> wrote:
>>> no, I know the value if convention when editors can't tell you
>>> anything about the name in question. I would like to see more support
>>> for disabled programmers like myself and the thousands of programmers
>>> injured every year and forced to leave the field. seriously, there is
>>> no money in disability access especially for programmers.
>>
>> Well, if we can't use conventions like uppercasing, camelcasing and
>> underscoring, what are you recommending we do instead?
>
> help build a smart editing environment please.
Why do you think a smart editing environment is in opposition to coding
conventions? Surely an editor smart enough to know a variable name spoken
as "pear tree" is an instance and therefore spelled as pear_tree (to use
your own example) would be smart enough to know a variable name spoken as
"red" is a constant and therefore spelled "RED"?
Sounds to me that your speech environment needs a command to turn
capslock on and off, and your problem with PEP 8 is solved:
x equals caps on red caps off plus three
> Heck, have you ever noticed how most Python smart editors can't even
> indent properly according to local contexts. Emacs is the only one and
> even that one sometimes fails
I use kwrite for editing, and I can't say I've ever noticed a failure.
> I've lived this works and probably have put more deep thought and 8kloc
> into it because I do not accept circures tricks as a way of life. I
> want it to work right and I know how to do it. I just don't have the
> hands and hte money to pay me to do it.
You're using a speech interface, right? You've written about "putting a
gun to your wrists", said you can't follow PEP 8 because it's not voice
safe, and generally given the impression that you can't use a keyboard.
So... just how do you get "hte" from saying "the"?
If you are using a keyboard to type this post, then surely it's not such
a huge imposition to type a couple of words in all caps here and there
while you speak the rest of the code?
<speak> x equals </speak> <type> <caplock> R E D </type> <speak> plus
three </speak>
I know that doesn't resolve the issue for those people who truly can't
use a keyboard at all, even for a single character, but it's unfair to
insist that the only permitted coding conventions are the ones suitable
for the tiny minority who, frankly, are going to have problems no matter
what coding conventions we have.
Especially when these coding conventions are entirely optional.
--
Steven
Eric S. Johansson
>
> Could you elucidate a bit? I'm not seeing how you're intending to keep
> PEP-8 conventions in this, and I'm not entirely convinced that without
> them the smart editor approach doesn't in fact reduce your productivity.
>
thank you for asking for an elaboration.
Programming by voice has one goal. enable a disabled person such as myself to
create code by voice with a minimum of vocal or hand damage.
let's use an example. Admittedly, this is a very simple example but hopefully it
illustrates my point
What I dictate is:
from pots is class telephone
What should generate is:
class Telephone (pots):
as you can see, taken from the simplistic expression, we generate the right
pep-8 convention. (I think). This is not the only grammar one can use but, it's
one that comes to mind that doesn't have a lot of dead ends.
So if I was dictating code, it would look something like:
>From pots is new class telephone
new constructor
first argument last mile = between quotes copper
Second argument fiber delivery date = between quotes when hell freezes over"
jump to body
first argument to self
second argument to self
new method construction crew
.
.
.
Telephone fieldwork = telephone second argument fiber delivery date = between
quotes hell froze over
recycled coffee = telephone fieldwork construction crew
-----------------
This is the rough example of what I think should be spoken and what can be
translated to code. What isn't shown is disambiguation techniques. For example,
when a name is said, if it is not unique to the context, then a small pop-up
shows the ambiguities and lets the user choose. Yes your focus shifts rapidly
but you're in the groove of writing code and it's just making your choices
explicit. For example, if telephone wasn't unique because we had telephone pole
and telephone truck as classes elsewhere in the namespace, you would see a
pop-up with each name with a number next to it. You could either click on the
item or say a digit to reinforce the choice. If the class had more methods, when
I say "telephone fieldwork" that gets translated into knowledge of what class
it's an instance of and all the choices are displayed but at the same time, the
natural language form are shoved into the grammar so you can continue speaking.
If you speak quickly enough, you will see no choice but the grammar will still
be loaded up so that you will get the right thing.
at each stage of the way, names get transformed into the pep-8 form without me
having to say anything special. The environment knows what form it wants and
does the transformation automatically. I'm surprised people aren't doing this
already for their handcrafted code. It's one less bit of detail you need to pay
attention to.
Eric S. Johansson
> Why do you think a smart editing environment is in opposition to coding
> conventions? Surely an editor smart enough to know a variable name spoken
> as "pear tree" is an instance and therefore spelled as pear_tree (to use
> your own example) would be smart enough to know a variable name spoken as
> "red" is a constant and therefore spelled "RED"?
no. I think a smart editing environment should support a coding convention. If
an editor is smart enough to track type and instance information, yes. It should
be able to generate the right strings for symbols. The question is, how do we
get such a smart editor. as far as I know, none exist and the smart ones so far
seem to be oriented towards hand use and are almost inaccessible to speech.
>
> Sounds to me that your speech environment needs a command to turn
> capslock on and off, and your problem with PEP 8 is solved:
you haven't used recognition, have you?
>
> x equals caps on red caps off plus three
it also means "red" is a single utterance. "RED" is three utterances. You've
just tripled vocal load for single word which means vat you just cut my ability
to work by two thirds. My voice is not as robust as my hands used to be. It's a
coarse tools not designed for engraving fine detail but instead painting
broadbrush strokes. for more you expect a person to say, the less time they can
spend on work effort. This is why I'm advocating a very smart at her with very
high level grammar structure using visual disambiguation techniques.
>> Heck, have you ever noticed how most Python smart editors can't even
>> indent properly according to local contexts. Emacs is the only one and
>> even that one sometimes fails
>
> I use kwrite for editing, and I can't say I've ever noticed a failure.
okay, it fails from a speech recognition user perspective. Put the cursor on the
line and hit the tab key. Insert spaces/tabs in the line of text. Not good for
speech recognition. If mess of indentation and hit the tab key, it doesn't
automatically indent to the right location. I'll be damned if I'm in the sit
there speaking "tabkeytabkeytabkeytabkeytabkey" because the error should take
care of it for me and save my voice. Like I said, Emacs does it correctly and
nobody else does as far as I can tell.
>> I've lived this works and probably have put more deep thought and 8kloc
>> into it because I do not accept circures tricks as a way of life. I
>> want it to work right and I know how to do it. I just don't have the
>> hands and hte money to pay me to do it.
>
> You're using a speech interface, right? You've written about "putting a
> gun to your wrists", said you can't follow PEP 8 because it's not voice
> safe, and generally given the impression that you can't use a keyboard.
>
> So... just how do you get "hte" from saying "the"?
joys of speech recognition. it was probably either due to a persistent
misrecognition that didn't have the right word and the correction dialog or, I
found the speech recognition error and could not corrected by voice.
and note, there are two errors above that lie would have had to correct by hand.
> If you are using a keyboard to type this post, then surely it's not such
> a huge imposition to type a couple of words in all caps here and there
> while you speak the rest of the code?
if I had typed this post, there would be two orders of magnitude more errors
because of intentional tremors and reduction of targeting accuracy. to give you
Monday an example. Sometimes my hands shake so badly, I cannot eat soup or even
Chile. I'm unable to use an iPhone except with a great deal of effort. am the
iPhone with a user with tremors, you activate more than one key about a third of
the time.
> <speak> x equals </speak> <type> <caplock> R E D </type> <speak> plus
> three </speak>
I only have about 1000 keystrokes equivalents today in my hands. Where am I
going to use them? Try adding (driving), preparing food, personal hygiene, or
typing PEP-8 compliant code? What I usually do is I do something like
constant_read = RED at the beginning of my code and well I think you know I'm
getting at. I generate something only I can read which does nobody any good.
> I know that doesn't resolve the issue for those people who truly can't
> use a keyboard at all, even for a single character, but it's unfair to
> insist that the only permitted coding conventions are the ones suitable
> for the tiny minority who, frankly, are going to have problems no matter
> what coding conventions we have.
You're looking at it from the classical anti-accommodation perspective. Don't
change the convention, give us the tools so we can comply with what the rest of
you do. It's like instead of putting a cut out every street corner, every
powered scooter/wheelchair comes with a antigravity boost that will lift them
over the curbstone. Accessibility belongs with the individual through tools that
take the standard and change it to their needs. While we don't have
anti-gravitational devices, we can make smart matters and that would solve a lot
more problems than just the simple compliance with PEP-8
>
> Especially when these coding conventions are entirely optional.
these conventions are religion for some special if you want to contribute code.
But look at the bigger issue. If your brother, or best friend was disabled and
couldn't make a living programming anymore, which you or which are not feel
enough compassion/responsibility to try and help them get back on their feet?
Assuming your answer was a compassionate one, try and extend that out word to
tens of thousands of developers losing their livelihood every year. Do you feel
enough compassion and can you get together enough people feel similar levels of
compassion to try and build a smart editing environment (all dicksizing about
gui kits aside) and make it possible for these people to continue in their
desired profession?
I know I hit on this point a lot but not are you helping your peers, some people
you may even know but you are saving yourself from being forced away from
programming at some point in the future whether it be from RSI, arthritis,
broken wrist, drop the fee or whatever. As we age, we all lose ability. I wish I
had known enough about the future to try and secure a future for myself but I
didn't. And so now I play an absolute pain in the ass on the net trying to get
people to think about themselves and their fellow programmers. I know I'm
obnoxious, I'm sorry but I want something to work for more than just me. I want
something that can be reproduce by individuals, rehabilitation facilities,
handicap advocacy groups. I don't want anyone to go through what I did trying to
rebuild my worklife. It was hell and if I can save somebody from it by being an
advocate, I'm going to keep doing it
So yeah, it would be swell to have a smart editor. I do believe that with the
right groundwork, a smart editor could not only serve the needs of people with
speech recognition but also present enough information so that text-to-speech
users can hear what they're working with. He may not be able to imagine this
but, you don't want to read the display, you want to read the meta-information
behind the symbols on the display and that's what a blind programmer would need
to hear in order to understand the code. Or at least that's what a few have
told me.
Steven D'Aprano
> Steven D'Aprano wrote:
...
>> Sounds to me that your speech environment needs a command to turn
>> capslock on and off, and your problem with PEP 8 is solved:
>
> you haven't used recognition, have you?
No.
>> x equals caps on red caps off plus three
>
> it also means "red" is a single utterance. "RED" is three utterances.
> You've just tripled vocal load for single word which means vat you just
> cut my ability to work by two thirds.
That assumes that every word is all caps. In practice, for real-life
Python code, I've tripled the vocal load of perhaps one percent of your
utterances, which cuts your productivity by 2%.
If you have 10000 words in you per day, and one percent get wrapped with
a leading and trailing "capslock", you have:
9900 regular words plus 100 constants
versus
9700 regular words plus 100 constants plus 200 by capslock.
Your productivity goes down by 200 words out of 10,000, or two percent.
>>> Heck, have you ever noticed how most Python smart editors can't even
>>> indent properly according to local contexts. Emacs is the only one and
>>> even that one sometimes fails
>>
>> I use kwrite for editing, and I can't say I've ever noticed a failure.
>
> okay, it fails from a speech recognition user perspective. Put the
> cursor on the line and hit the tab key. Insert spaces/tabs in the line
> of text. Not good for speech recognition. If mess of indentation and
> hit the tab key, it doesn't automatically indent to the right location.
> I'll be damned if I'm in the sit there speaking
> "tabkeytabkeytabkeytabkeytabkey" because the error should take care of
> it for me and save my voice. Like I said, Emacs does it correctly and
> nobody else does as far as I can tell.
I don't understand what you're describing.
If you set kwrite to use "Python style" indent mode, then starting a new
line will automatically indent to either the current indent level, or one
extra indent level if the line ends with a colon. You shouldn't need to
indent forward more than one level at a time when writing Python code,
although you will need to dedent multiple levels on occasion.
> I only have about 1000 keystrokes equivalents today in my hands. Where
> am I going to use them? Try adding (driving), preparing food, personal
> hygiene, or typing PEP-8 compliant code?
Your choice naturally.
> You're looking at it from the classical anti-accommodation perspective.
> Don't change the convention, give us the tools so we can comply with
> what the rest of you do.
Just a minute. You're the one who started this discussion rejecting the
convention. Your first post started off:
"I reject this convention..."
and then finished with
"so I reject pep 8 because I have no voice safe alternative"
Do you blame us for reading this as a protest against uppercase
identifiers?
Now you're saying you're happy for us to keep the all-uppercase
convention and just want better tools. Okay, you want better tools.
Great. If you're attempting to raise the profile of disabled programmers,
you've done so, but what exactly are you expecting?
I've already said it's your right to reject the convention for your own
code. Go right ahead. This is only a problem if you're editing other
people's code which is using uppercase constants.
You've rejected capslock red capslock because it takes three utterances,
but said you use constant_red instead. That's two utterances, saving you
only one. If you actually have to say the underscore, your convention
takes six syllables versus five for my idea.
>> Especially when these coding conventions are entirely optional.
>
> these conventions are religion for some special if you want to
> contribute code.
Does your editor have search and replace? Before you contribute code, do
a global replacement of constant_red for RED.
> But look at the bigger issue.
Yes, we get it. It sucks to have a physical disability. The universe
isn't arranged to make it easy for those who do, and even systems built
by people are only indifferently suitable.
So, let's get down to practical matters:
Do you wish to register a protest against all-caps constants in PEP 8?
Do you wish to ask the Python Dev team to rethink their decision?
Do you wish to raise the profile of disabled programmers?
Do you wish to start a project developing a better, smarter editor, and
are looking for volunteers?
--
Steven
Rhodri James
wrote:
> Steven D'Aprano wrote:
>
>> Why do you think a smart editing environment is in opposition to coding
>> conventions? Surely an editor smart enough to know a variable name
>> spoken
>> as "pear tree" is an instance and therefore spelled as pear_tree (to use
>> your own example) would be smart enough to know a variable name spoken
>> as
>> "red" is a constant and therefore spelled "RED"?
>
> no. I think a smart editing environment should support a coding
> convention. If
> an editor is smart enough to track type and instance information, yes.
> It should
> be able to generate the right strings for symbols. The question is, how
> do we
> get such a smart editor. as far as I know, none exist and the smart
> ones so far
> seem to be oriented towards hand use and are almost inaccessible to
> speech.
But is it really possible for an editor to be smart enough
Rhodri James
<rho...@wildebst.demon.co.uk> wrote:
> On Tue, 30 Jun 2009 03:37:15 +0100, Eric S. Johansson <e...@harvee.org>
> wrote:
>
>> Steven D'Aprano wrote:
>>
>>> Why do you think a smart editing environment is in opposition to coding
>>> conventions? Surely an editor smart enough to know a variable name
>>> spoken
>>> as "pear tree" is an instance and therefore spelled as pear_tree (to
>>> use
>>> your own example) would be smart enough to know a variable name spoken
>>> as
>>> "red" is a constant and therefore spelled "RED"?
>>
>> no. I think a smart editing environment should support a coding
>> convention. If
>> an editor is smart enough to track type and instance information, yes.
>> It should
>> be able to generate the right strings for symbols. The question is, how
>> do we
>> get such a smart editor. as far as I know, none exist and the smart
>> ones so far
>> seem to be oriented towards hand use and are almost inaccessible to
>> speech.
>
> But is it really possible for an editor to be smart enough
Gah. Ignore me. I hit 'send' instead of 'cancel', after my musings
concluded that yes, an editor could be smart enough, but it would have
to embed a hell of a lot of semantic knowledge of Python and it still
wouldn't eliminate the need to speak the keyboard at times.
Tim Chase
Sorry...I didn't catch that you were using speech-recognition
(SR) instead of text-to-speech (TTS). I didn't see it mentioned
in another thread-branch after I had posted.
While I have used SR in some testing, I've found that while it's
passable for prose (and even that, proclamations of "95%
accuracy" sound good until you realize how many words comprise 5%
of your daily typing :), it's not so good for code unless you
have a very specific programming-language+SR designed editing
environment...as you've been griping. However, the problem seems
not to be PEP-8, but rather the inabilities of your SR combined
with the failings of your editor.
For coding, you might want to investigate a tool like Dasher[1]
which offers an alternate form of input. It allows for custom
vocabularies/keymaps if you need, as well as more precise
specification of a full keyboard (caps vs. mixed-case, specific
punctuation characters, etc). The predictive entry should be
smart enough to pick up previously entered constants/terms saving
you entry speed. It can also be driven by a wide variety of
pointing devices (mouse, trackball, touchpad, head-tracker,
gyro-input, etc).
You might also experiment with other editors that allow for more
efficient editing.
Hope these give you another option to consider, if SR plus your
current editor aren't cutting it for you,
-tkc
[1]
http://www.inference.phy.cam.ac.uk/dasher/
http://en.wikipedia.org/wiki/Dasher
http://www.youtube.com/results?search_query=dasher
http://video.google.com/videosearch?q=dasher
Rhodri James
On Tue, 30 Jun 2009 02:52:37 +0100, Eric S. Johansson <e...@harvee.org>
wrote:
> let's use an example. Admittedly, this is a very simple example but
> hopefully it
> illustrates my point
>
> What I dictate is:
>
> from pots is class telephone
>
> What should generate is:
>
> class Telephone (pots):
>
> as you can see, taken from the simplistic expression, we generate the
> right
> pep-8 convention. (I think). This is not the only grammar one can use
> but, it's
> one that comes to mind that doesn't have a lot of dead ends.
[snip fuller example]
> at each stage of the way, names get transformed into the pep-8 form
> without me
> having to say anything special. The environment knows what form it wants
> and
> does the transformation automatically. I'm surprised people aren't
> doing this
> already for their handcrafted code. It's one less bit of detail you need
> to pay
> attention to.
This goes a long way, but it doesn't eliminate the need for some forms
of escape coming up on a moderately frequent basis. Consider "Coffee
strength equals five" for example: this could mean either
coffee_strength = 5
or
COFFEE_STRENGTH = 5
depending on whether we will later be using it as a constant or not.
Python doesn't have syntactic constants, which is precisely why PEP-8
is useful. You might have enough smarts in your system for it to
remember after the first time you use "coffee strength", and it might
be unambiguous, but at the very least you need to be able to say
"Constant coffee strength equals five" first time round.
This isn't the only occasion when you simply don't have the context
to avoid verbal disambiguation. Are you accessing attributes of the
class MyClass or its instance my_class, for instance? In your initial
post you seemed to be claiming that having to do this disambiguation
textually was bad, and PEP-8 should therefore be rejected. Given
that I'm not prepared to lose the productivity increase that comes
with being able to disambiguate visually at a glance, I don't see
that it's avoidable.
Incidentally, since what you're proposing is essentially templating,
wouldn't it be better to do it as post-processing on the speech
recognition rather than building it directly into an editor?
to resolve
Jean-Michel Pichavant
Which disabled abilities are you talking about ? What about people that
have difficulties to speak because of partial jaw paralysis. They would
need systems that recognize eye blinks to write down code. What about
blind people, color blind ... ? Would a new disabled friendly PEP 8
version fits all their needs ?
To come back to a more python related subject, I don't think it falls
into PEP responsibility to take into account all the disabled abilities
you can find in the dev community. This falls into the tools they used
to workaround their issues and there's surely much work to be done here.
In the end, as someone mentioned before, PEPs are only guidelines, and
you are entitled to break them if the rule hurts you. This is one of the
many beauties of python, it's flexible.
Jean-Michel
Eric S. Johansson
> [Trimming for length, sorry if that impacts too much on intelligibility]
no problem, one of the hazards of speech recognition uses you become very verbose.
> This goes a long way, but it doesn't eliminate the need for some forms
> of escape coming up on a moderately frequent basis. Consider "Coffee
> strength equals five" for example: this could mean either
>
> coffee_strength = 5
>
> or
>
> COFFEE_STRENGTH = 5
>
> depending on whether we will later be using it as a constant or not.
> Python doesn't have syntactic constants, which is precisely why PEP-8
> is useful. You might have enough smarts in your system for it to
> remember after the first time you use "coffee strength", and it might
> be unambiguous, but at the very least you need to be able to say
> "Constant coffee strength equals five" first time round.
right. The initial state of a symbol is always a chatty moment. It sets the
context and background information for subsequent use. My initial reaction is
that when you do coffee strength equals five, it would pop up a simple dialog
asking variable or constant? You would say "variable" and it would format
everything the right way. This is a form of interactive dialogue that would be
used consistently throughout the rest of the environment.
>
> This isn't the only occasion when you simply don't have the context
> to avoid verbal disambiguation. Are you accessing attributes of the
> class MyClass or its instance my_class, for instance? In your initial
> post you seemed to be claiming that having to do this disambiguation
> textually was bad, and PEP-8 should therefore be rejected. Given
> that I'm not prepared to lose the productivity increase that comes
> with being able to disambiguate visually at a glance, I don't see
> that it's avoidable.
I don't mind verbal disambiguation if it's infrequent. What I object to is
being forced to disambiguate every time I use a symbol. The reason being is one
is a minor increase in vocal load and can be made a dumb template (maybe) where
is the other is just doing a bunch of makework over and over again.
As for your my class example, you never ever use my_class unless it's prefaced
by an instance of the class MyClass. And if you say something like
My class yields fall class
or
fall class is my class
or
fall class = my class
You have sufficient information to know that my class is a class name.and that
you have some number of arguments and the system can run you through a dialogue
to fill in the arguments.
I wish I had the tools to create a simulation of what the editing sequence with
the dialog box pop-ups in nice little animated movie. Heck, if I could just
capture time lapse I could do it with paper and pencil and a voiceover. It would
remind you of Gumby meets South Park but... I digress
>
> Incidentally, since what you're proposing is essentially templating,
> wouldn't it be better to do it as post-processing on the speech
> recognition rather than building it directly into an editor?
> to resolve
if my template in, you mean a system that can receive type information from
somewhere about every single symbol in the system and then load up a grammar,
handle the dialogs for disambiguation at the same time as providing an editing
environment that lets you refer to symbols by their verbose name instead of
their codename and still operate on. For example, replace an argument should pop
up a dialog box with the second argument of the first method on the line. You
then can change things by their names like second string or array index.
Then sure, maybe a templating system would work. But I don't think it will
thank you for continuing in this dialogue.
Eric S. Johansson
> Eric S. Johansson wrote:
>
np. I get this confusion often.
>
> While I have used SR in some testing, I've found that while it's
> passable for prose (and even that, proclamations of "95% accuracy" sound
> good until you realize how many words comprise 5% of your daily typing
> :), it's not so good for code unless you have a very specific
> programming-language+SR designed editing environment...as you've been
> griping. However, the problem seems not to be PEP-8, but rather the
> inabilities of your SR combined with the failings of your editor.
I've been working with speech recognition for 15 years. I've written something
on the order of 10,000 lines of Python code both as open source and private
projects. I've tried it least two dozen editors and they all fail miserably
because they're focused on keyboard use (but understandable) I get good
recognition accuracy because I train the system and then I let it train me.
>
> For coding, you might want to investigate a tool like Dasher[1] which
> offers an alternate form of input. It allows for custom
> vocabularies/keymaps if you need, as well as more precise specification
> of a full keyboard (caps vs. mixed-case, specific punctuation
> characters, etc). The predictive entry should be smart enough to pick
> up previously entered constants/terms saving you entry speed. It can
> also be driven by a wide variety of pointing devices (mouse, trackball,
> touchpad, head-tracker, gyro-input, etc).
I've tried it, it's quite promising but my hands term are sufficiently that I
can't target accurately. This is a problem for me with mice as well. Maybe these
tiny little spit dot icons and webpages drive me insane because it takes me two
or three tries to put the right spot.
but still, you would have the basic problem of getting the information about
the code into language model of dasher so it could predict what might be chosen
based on the previous context. It' 80% the same work and, doesn't help those of
us with really bad hands.
>
> You might also experiment with other editors that allow for more
> efficient editing.
I've tried a whole bunch, like I said at least a dozen. They all fail for first
reasons such as inability to access all functionality through keystrokes
(easiest interface method from speech recognition) to virtually no
autoformatting or worse yet, inconsistent autoformatting. The classic example is
auto indentation based on previous lines. Emacs does a relatively right.
I know this is also counter to the Python way but having something marking and
outdent would be really useful so that a vocal driven command to indent or
outdent a block would be practical. Oh, another failure point. Have you ever
tried to selected beach and by voice. I mean I should say have you ever tried to
select a region by voice. Doesn't work very well. Nuance has something called
selective and say but it only works in very special Windows edit controls. Or,
if you're doing toolkit supports the right signals/events. Nobody does in the
the linux world and it doesn't look like they support them in the Windows world
either.
>
> Hope these give you another option to consider, if SR plus your current
> editor aren't cutting it for you,
maybe we should have a conversation off list about different editors if you
don't mind. I'm certainly open to alternatives but, I do have fairly high
standards and one of them is that ^X^S doesn't crash the editor. :-) I have been
using Emacs for too many years and it is such a reflex.
Another alternative would be to help fix the NaturallySpeaking Emacs gateway
vr-mode. While it doesn't truly improve the problem, it makes it a little more
manageable.
thank you for your time
Tim Chase
> miserably because they're focused on keyboard use (but
> understandable)
> I've tried a whole bunch, like I said at least a dozen. They
> all fail for first reasons such as inability to access all
> functionality through keystrokes (easiest interface method
> from speech recognition)
I'm not sure I follow which you want...you kvetch that
they're too focused on keyboard use, but then that you can't
access all functionality through the keyboard.
[warning, blatant vim fanaticism follows]
I use vim and can't remember the last time I used the mouse
with it (save for occasionally lazily scrolling with the
mouse-wheel, but you can scroll with the keyboard too), so
it meets your "must be fully accessible through the
keyboard" constraint. It also has single keystroke commands
for indenting/exdenting the current line as you mention:
> I know this is also counter to the Python way but having
> something marking and outdent would be really useful so
> that a vocal driven command to indent or outdent a block
> would be practical.
which can be done in insert-mode with control+D, control+T,
and if you want to clear all indentation (all the way back
to the first column), you can use "0" followed by control+D.
Vim also allows for fairly detailed control over
auto-indentation settings so you can match them to your
preferences. I suspect Emacs may be configurable to offer
similar functionality but I'd have to defer to the emacsen
on the list.
That said, I'll be the first to admit that the vi/vim
learning curve is more like a brick wall than a curve.
However, I find the efficiency gains abundantly than repaid
the time I invested to learn it well.
>> Dasher[1]
>
> I've tried it, it's quite promising but my hands term are
> sufficiently that I can't target accurately.
Last I tried it, it scaled the target sizes based on
probability. You might also try unconventional pointing
devices for better precision. I've seen web-cam
eye-tracking tools which might make it a bit easier. Or try
a tablet input (where the motion corresponds linearly, as
opposed to accelerated mouse motion). Such input options
are listed on the Dasher website, at least for those they
tested.
> Oh, another failure point. Have you ever tried to selected
> beach and by voice. I mean I should say have you ever tried to
> select a region by voice.
yes, not a pleasant experience. Again, vim's modal
interface allows for using text-objects so you can issue
short-hand commands like
ci"
to "[c]hange the contents [i]nside the double-quotes I'm
currently on/withing". The operator+motion and
operator+textobject command syntax obviates a lot selection.
While vim does offer a "visual" mode (akin to selection in
other editors), I use it much less because of the power
provided by the operator+[motion/textobject].
> maybe we should have a conversation off list about different
> editors if you don't mind. I'm certainly open to alternatives
> but, I do have fairly high standards and one of them is that
> ^X^S doesn't crash the editor. :-) I have been using Emacs for
> too many years and it is such a reflex.
as you're an emacs user, my vim suggestions may sound like
heresy. ;-) But I suspect a skilled emacs user (or perhaps
asking on an emacs-users list) could mimic much of the vim
functionality. I just can't be of much assistance there.
You're welcome to move it off-list...it's kinda drifted from
python to general accessibility issues. CC'ing c.p.l for this
one in case any emacsen care to chime in on their suggested tweaks.
-tkc
MRAB
>
> I've been working with speech recognition for 15 years. I've written something
> on the order of 10,000 lines of Python code both as open source and private
> projects. I've tried it least two dozen editors and they all fail miserably
> because they're focused on keyboard use (but understandable) I get good
> recognition accuracy because I train the system and then I let it train me.
>
Microsoft Vista Speech Recognition Tested - Perl Scripting
http://www.youtube.com/watch?v=KyLqUf4cdwc
Eric S. Johansson
>> I've tried it least two dozen editors and they all fail miserably
>> because they're focused on keyboard use (but understandable)
>> I've tried a whole bunch, like I said at least a dozen. They
>> all fail for first reasons such as inability to access all
>> functionality through keystrokes (easiest interface method
>> from speech recognition)
>
> I'm not sure I follow which you want...you kvetch that
> they're too focused on keyboard use, but then that you can't
> access all functionality through the keyboard.
sorry. I've been living in this world for so long that I sometimes forget to
explain what's obvious inside my head. I apologize for the confusion.
The apparent conflict arises because the same term (keyboard access) is used to
describe two different problems. In the first case, the user interface model
(how you access taxes, manipulate light which (language) constructs are designed
to be efficient for your hands. speech recognition users need an editor that
supports constructs that are efficient for the voice. One such construct is the
ability to navigate or operate on language elements by name. I've used some of
them before such as predicate, index, first method etc.
The second problem is that editors are designed to be driven by keystroke. If I
had a cross process boundary APIPaula I can simply call the editor function to
perform to give operation. Unfortunately, today my speech recognition
environment needs to generate keystrokes to access functionality. for example,
in Emacs, when I say "delete word", the macro and marmot emits M-d
>
> [warning, blatant vim fanaticism follows]
>
> I use vim and can't remember the last time I used the mouse
> with it (save for occasionally lazily scrolling with the
> mouse-wheel, but you can scroll with the keyboard too), so
> it meets your "must be fully accessible through the
> keyboard" constraint. It also has single keystroke commands
> for indenting/exdenting the current line as you mention:
you are forgiven. :-) try this experiment. Bring up the buffer full Python code
code you value them, starting in command mode, close your eyes and type a random
word. While your eyes are closed, undo that word. Every time I've tried it the
results have been mildly disastrous. If you been paying attention, I've tried to
leave speech recognition errors in place whatever didn't impede understanding
(too much) but, remember I'm getting one error in 20 errors is on average. That
means, I'll be correcting the IE errors, potentially much more dangerous errors
are regular basis. Any energy use by speech recognition must be able to cope
with a random dictation errors and let the user recover gracefully. Again, until
I started using speech recognition, I would never would've thought of this as a
failure case.
>
> > I know this is also counter to the Python way but having
> > something marking and outdent would be really useful so
> > that a vocal driven command to indent or outdent a block
> > would be practical.
>
> which can be done in insert-mode with control+D, control+T,
> and if you want to clear all indentation (all the way back
> to the first column), you can use "0" followed by control+D.
> Vim also allows for fairly detailed control over
> auto-indentation settings so you can match them to your
> preferences. I suspect Emacs may be configurable to offer
> similar functionality but I'd have to defer to the emacsen
> on the list.
Yes, Emacs will, a single tab key, tab view to the indentation level specified
by the previous line unless it's already there and then it will start inventing
further. This really sucks. Sometimes, you just weary and then to (you just
want to) go to the right place and stay there
>
> That said, I'll be the first to admit that the vi/vim
> learning curve is more like a brick wall than a curve.
> However, I find the efficiency gains abundantly than repaid
> the time I invested to learn it well.
Yeah, I first encountered the eye in 1985. Or maybe I should say VI (Roman
numeral six).
>
>>> Dasher[1]
>>
>> I've tried it, it's quite promising but my hands term are sufficiently
>> that I can't target accurately.
>
> Last I tried it, it scaled the target sizes based on
> probability. You might also try unconventional pointing
> devices for better precision. I've seen web-cam
> eye-tracking tools which might make it a bit easier. Or try
> a tablet input (where the motion corresponds linearly, as
> opposed to accelerated mouse motion). Such input options
> are listed on the Dasher website, at least for those they
> tested.
>
I like tablets. I need to buy a new one. We only problem is that most pens for
tablets are a little bit too small and hard for my hands (although they are much
better than mice). The major downfall is the buttons on the pen shaft. Damn
that's awkward to reach. I think it would need a separate tab of three buttons
that I can click and double-click independent of the pen controls.
>> Oh, another failure point. Have you ever tried to selected beach and
>> by voice. I mean I should say have you ever tried to
>> select a region by voice.
>
> yes, not a pleasant experience. Again, vim's modal
> interface allows for using text-objects so you can issue
> short-hand commands like
>
> ci"
>
> to "[c]hange the contents [i]nside the double-quotes I'm
> currently on/withing". The operator+motion and
> operator+textobject command syntax obviates a lot selection.
> While vim does offer a "visual" mode (akin to selection in
> other editors), I use it much less because of the power
> provided by the operator+[motion/textobject].
that's getting close to what I want to do with voice command except instead of
cryptic sequence of characters, I would say something like
string_edit = edit [<which>] string
which = first | second | third | fourth | fifth | sixth
> as you're an emacs user, my vim suggestions may sound like
> heresy. ;-) But I suspect a skilled emacs user (or perhaps
> asking on an emacs-users list) could mimic much of the vim
> functionality. I just can't be of much assistance there.
I really don't care what editor I use as long as it gets the job done. I have
strong preferences for always insert mode but, if I had an editor I had no
keystroke commands and everything I type went into the buffer but I committed a
complete of my speech, that would be kind of cool.
>
> You're welcome to move it off-list...it's kinda drifted from python to
> general accessibility issues. CC'ing c.p.l for this one in case any
> emacsen care to chime in on their suggested tweaks.
well, that you are really joined. For example, if we look at the string edit
command above, that implies he had or has the ability to properly distinguish a
string in a line of code. Think of how many ways you can express a string
triple or single quotes into different forms sometimes with quotes nested
inside. then take the whole object instance and know method is possible with
its type signature. This is editor work.
Eric S. Johansson
>
> Gah. Ignore me. I hit 'send' instead of 'cancel', after my musings
> concluded that yes, an editor could be smart enough, but it would have to
> embed a hell of a lot of semantic knowledge of Python and it still wouldn't
> eliminate the need to speak the keyboard at times.
imagine having the same problem except that happens at random while you're
speaking and watching something else other than a screen. :-)
Yeah, it would take a lot of semantic knowledge about Python. Is it possible to
leverage compiler internals? Is it possible to gather as much information as you
can and when the system says "I don't know" you tell what you know it remembers
that for future reference?
And you're right, they're always corner cases where you'll need to speak the
keyboard or type. I've mostly resigned to accept on days when I have an absolute
hissy hissy fit because my hands hurt so bad I can't get enough painkillers
drop the pain and let me function.
In the real short term what I really want. More than anything right now is to
get back to the point where I can pick away at writing Python again. I'm in
this really weird confluence of virtual machine hell, the evolution of
naturally speaking under wine and the problems of telling an editor how to do
the right thing.
There's a gap between the fragile crappy way I and others operate today and the
really ideal completely voice driven environment that exists between my ears. I
would like to move into that gap but it's sufficiently far away from what my
hands can do that I'm dependent on others and that makes me really crazy sometimes.
>From my perspective, what I consider a reasonable intermediate step would be an
editor that has the following features:
The ability to select regions either by NaturallySpeaking Select-and-Say and
Emacs mark and point semantics.
Very deterministic indentation control. (I.e. indent x tabs or indent to "right"
level.)
ability to navigate/operate on generic language features
it would be nice if one could edit language features in a separate window again,
using Select-and-Say type interface.
another it would be nice would be the ability to look up type signatures
(classes, methods etc. and inject the appropriate template when using a
particular method. (Doesn't have to be by voice)
this level of functionality, would also make it possible to comply with PEP-8
:-) given proper easy and automatic name generation and dumpling.
Eric S. Johansson
> That assumes that every word is all caps. In practice, for real-life
> Python code, I've tripled the vocal load of perhaps one percent of your
> utterances, which cuts your productivity by 2%.
>
> If you have 10000 words in you per day, and one percent get wrapped with
> a leading and trailing "capslock", you have:
>
> 9900 regular words plus 100 constants
>
> versus
>
> 9700 regular words plus 100 constants plus 200 by capslock.
>
> Your productivity goes down by 200 words out of 10,000, or two percent.
oh I wish it was so simple. I would absolutely you if it was that simple the
real world. Somehow, I fear that you wouldn't understand unless you sat next to
me and watch me try to write code to a variety of standards.
In practice, my experience says that with a really good speech driven
environment for programming, IT, vocal load probably by a quarter to a half and
be more compliant with current fashion for naming.
>
>
>>>> Heck, have you ever noticed how most Python smart editors can't even
>>>> indent properly according to local contexts. Emacs is the only one and
>>>> even that one sometimes fails
>>> I use kwrite for editing, and I can't say I've ever noticed a failure.
>> okay, it fails from a speech recognition user perspective. Put the
>> cursor on the line and hit the tab key. Insert spaces/tabs in the line
>> of text. Not good for speech recognition. If mess of indentation and
>> hit the tab key, it doesn't automatically indent to the right location.
>> I'll be damned if I'm in the sit there speaking
>> "tabkeytabkeytabkeytabkeytabkey" because the error should take care of
>> it for me and save my voice. Like I said, Emacs does it correctly and
>> nobody else does as far as I can tell.
>
> I don't understand what you're describing.
>
> If you set kwrite to use "Python style" indent mode, then starting a new
> line will automatically indent to either the current indent level, or one
> extra indent level if the line ends with a colon. You shouldn't need to
> indent forward more than one level at a time when writing Python code,
> although you will need to dedent multiple levels on occasion.
I recognize your confusion. It's very common when describing this problem. If I
had some way of making a movie of what and describing, obviously be more clear.
I'll see if I can make a movie with my camera that demonstrates the problem. It
probably won't happen fast but, what I tried your editor, it failed with a
trivial effort. I think I just hit the tab key multiple times in different
places on the line. In all cases it did the wrong thing. For me, the right thing
is to force the line to the right indentation based on the previous line to
matter how may times you get the tab key or where you are on that line when you
hit the tab key. I could be in the middle of the line, the end of line, start a
line, the start of the string and if I hit a tab key, that line should go to
exactly the right place stayed there no matter how me more times I typed a tab key.
But this might be what you're getting confused. What I'm really asking for is
the ability to say "force indent" and have the line indent exactly correctly
based on context. It doesn't have to be the tab key. The tab key is the method
of convenience.
>
>> You're looking at it from the classical anti-accommodation perspective.
>> Don't change the convention, give us the tools so we can comply with
>> what the rest of you do.
>
> Just a minute. You're the one who started this discussion rejecting the
> convention. Your first post started off:
>
> "I reject this convention..."
>
> and then finished with
>
> "so I reject pep 8 because I have no voice safe alternative"
>
> Do you blame us for reading this as a protest against uppercase
> identifiers?
it's a protest against identifiers that increase vocal or hand load. It's also
protest against decisions people make without awareness of the implications, in
this case, increasing the barriers against disabled programmers.
>
> Now you're saying you're happy for us to keep the all-uppercase
> convention and just want better tools. Okay, you want better tools.
> Great. If you're attempting to raise the profile of disabled programmers,
> you've done so, but what exactly are you expecting?
I waffle back and forth on that. I recognize my opinion matters as much as a
piss hole in the snow. But the unintentional discrimination really gets to me.
In case you're wondering, I feel this way about many forms of bad
design/exclusionary practices. Some I can even do something about.
my expectations are evolving. I wanted to raise awareness, like you said, I've
done that. But now, I'd like to turn it into action. As I said in another post,
the editor that would let me get back to writing Python relatively easily again
doesn't exist. It's not the flashy wonderful no keystrokes whatsoever condition
but it's significantly better than the current Emacs/VI/Python editor du jour.
it would be able to operate open loop with relation to speech recognition but I
also have an idea of how to add closed loop capability to make it more efficient
as that capability becomes available.
> I've already said it's your right to reject the convention for your own
> code. Go right ahead. This is only a problem if you're editing other
> people's code which is using uppercase constants.
exactly. If I'm unable to comply with local conventions, I cannot work within an
organization and be an active member of the team. This is one example of what I
mean by unintentional discriminatory effects of a given decision. rhetorical
devices aside, I think the right way to deal with accessibility issues and
decisions leading to discrimination is to make the appropriate tools if possible
for the individual. But I'm sure that would be a very long discussion we would
have over a couple of beers.
>
> You've rejected capslock red capslock because it takes three utterances,
> but said you use constant_red instead. That's two utterances, saving you
> only one. If you actually have to say the underscore, your convention
> takes six syllables versus five for my idea.
my opinion comes out of experience. Strictly numerically speaking, you are
correct. But if you look at recognition accuracy, pacing of speech, and flow of
words through the vocal track, my solution is gentler on the vocal tract, body
stress (tension anticipating this recognition errors), and cognition (don't need
a spare any mental cycles on anticipation of failure and how to correct). I can
just say focused on what I'm dictating. Additionally, making corrections of my
style is easier (i.e. you can make the correction) but the form you propose with
Locks (see, this is one of those "I'm going to bust a In your ass" type errors)
cannot be corrected. He can only be deleted and restated.
I apologize for being a "I'm the expert know it all" on this but, I really do
have 15 years experience with these kind of failures and I like to think I know
something about the topic.
>>> Especially when these coding conventions are entirely optional.
>> these conventions are religion for some special if you want to
>> contribute code.
>
> Does your editor have search and replace? Before you contribute code, do
> a global replacement of constant_red for RED.
Yes it does and, it you know as well as I do that global search replace blindly
leads to disastrous errors and, increased testing, and the problem doesn't go
away because you always modify your code later.
>
>
>> But look at the bigger issue.
>
> Yes, we get it. It sucks to have a physical disability. The universe
> isn't arranged to make it easy for those who do, and even systems built
> by people are only indifferently suitable.
fine. I'll put down that particular baseball bat stop hitting you over the head
with it. I still think you should try living with naturally speaking for a week
or two.
>
> So, let's get down to practical matters:
>
> Do you wish to register a protest against all-caps constants in PEP 8?
only if I had a rational, reasonable alternative. Let me chew on that.
>
> Do you wish to ask the Python Dev team to rethink their decision?
only when I have rational, reasonable alternatives.
>
> Do you wish to raise the profile of disabled programmers?
yes. Not exactly sure of the best way but I would like to do that through
providing tools enabling them to participate on equal footing with not yet
disabled programmers. I really don't like saying "take pity on the poor
programmers with broken hands." I'd rather say "you need talent? Here's a pool
you have previously thrown away but they can now generate code faster than the
keyboard users.
> Do you wish to start a project developing a better, smarter editor, and
> are looking for volunteers?
yes. This also opens up a great big giant hairball. Specifically, how do you
edit on one machine but do all of your testing and debugging on the second (i.e.
edit on Windows, do everything else on Linux. Unfortunately, I have quite a bit
of scar tissue with this as well and can tell you all about how the different
network file systems fail in special and wonderful ways.
but let's deal with the editor first.
yes, I would like to start a smarter editor project and the only way I could do
it is with volunteers. I would not be able to write code for it until it had
progressed significantly. What I can do is provide the knowledge of a
first-generation system should look like, evolutionary corrections thereafter. I
can also help with interfacing Python two to speech recognition and creation of
grammars and their code.
I'm a strong believer in recycling existing systems. We might get lucky and make
it better for them to.
if you're willing to help me find volunteers, get this started (I only need some
nudges in the right direction), I gladly accept your help and your knowledge.
Lie Ryan
> Steven D'Aprano wrote:
>> That assumes that every word is all caps. In practice, for real-life
>> Python code, I've tripled the vocal load of perhaps one percent of your
>> utterances, which cuts your productivity by 2%.
>>
>> If you have 10000 words in you per day, and one percent get wrapped with
>> a leading and trailing "capslock", you have:
>>
>> 9900 regular words plus 100 constants
>>
>> versus
>>
>> 9700 regular words plus 100 constants plus 200 by capslock.
>>
>> Your productivity goes down by 200 words out of 10,000, or two percent.
>
> oh I wish it was so simple. I would absolutely you if it was that simple the
> real world. Somehow, I fear that you wouldn't understand unless you sat next to
> me and watch me try to write code to a variety of standards.
>
> In practice, my experience says that with a really good speech driven
> environment for programming, IT, vocal load probably by a quarter to a half and
> be more compliant with current fashion for naming.
I've tried (Windows') speech recognition some time before, and I know
it's one heck of a mess trying to type anything with it. I have a fully
working hand, so I don't actually need a voice recognition, but I
remember trying to write a single (not code) paragraph solely by
recognition. It took me over an hour correcting all those mistakes and
it really starts to gets into the nerves after the first sentence. I did
a little victory dance, after doing the first paragraph.
I know they gets better with time as they learn our speech pattern and
we learn how to pronounce the way the voice recognition expects. But one
thing I can't imagine is using voice recognition for writing code
(heck... that'll be a nightmare inside a nightmare)
Maybe we need an editor that could sort of understand something like:
"constant red"
and apply the appropriate code-sensitive convention transformation (in
python it'll be RED)
"class foo inheriting object"
and typed "class Foo(object):\n\t"
"indent", "dedent"
put a tab or delete a tab (or softtab)
but for all those, we're going to need a specialized text editor or
perhaps a context-sensitive voice recognition software. The simplest
solution would be a vim plugin or emacs mode that is specially tailored
to recognize these commands and apply the appropriate transformations
depending on the contexts.
>> I've already said it's your right to reject the convention for your own
>> code. Go right ahead. This is only a problem if you're editing other
>> people's code which is using uppercase constants.
>
> exactly. If I'm unable to comply with local conventions, I cannot work within an
> organization and be an active member of the team. This is one example of what I
> mean by unintentional discriminatory effects of a given decision. rhetorical
> devices aside, I think the right way to deal with accessibility issues and
> decisions leading to discrimination is to make the appropriate tools if possible
> for the individual. But I'm sure that would be a very long discussion we would
> have over a couple of beers.
Personally, I think it'd be very difficult to try to change conventions
that were made for a job that requires so much typing. In programming,
typing is almost a requirement. I'm aware people will still try to
insist on doing things they love the most no matter what happens, but I
still think if the disabled want to program, they're the one that need
to adjust their work flow and definitely with the current voice
recognition technology, they really need better tools.
>> Do you wish to raise the profile of disabled programmers?
>
> yes. Not exactly sure of the best way but I would like to do that through
> providing tools enabling them to participate on equal footing with not yet
> disabled programmers. I really don't like saying "take pity on the poor
> programmers with broken hands." I'd rather say "you need talent? Here's a pool
> you have previously thrown away but they can now generate code faster than the
> keyboard users.
Stephen Hawking didn't stop with his experiments when his whole body
can't move. I agree that disabilities shouldn't stop people from
programming, which is mostly the head's job. I think if we can make
voice recognition faster and easier than typing (like in those sci-fi
movies), disabled or not we will all benefit from it. Maybe some day, we
all, disabled or not, might code with voice recognition and keyboard
will be considered obsolete.
Lie Ryan
> I've been working with speech recognition for 15 years. I've written something
> on the order of 10,000 lines of Python code both as open source and private
> projects. I've tried it least two dozen editors and they all fail miserably
> because they're focused on keyboard use (but understandable) I get good
> recognition accuracy because I train the system and then I let it train me.
>> For coding, you might want to investigate a tool like Dasher[1] which
>> offers an alternate form of input. It allows for custom
>> vocabularies/keymaps if you need, as well as more precise specification
>> of a full keyboard (caps vs. mixed-case, specific punctuation
>> characters, etc). The predictive entry should be smart enough to pick
>> up previously entered constants/terms saving you entry speed. It can
>> also be driven by a wide variety of pointing devices (mouse, trackball,
>> touchpad, head-tracker, gyro-input, etc).
>
> I've tried it, it's quite promising but my hands term are sufficiently that I
> can't target accurately. This is a problem for me with mice as well. Maybe these
> tiny little spit dot icons and webpages drive me insane because it takes me two
> or three tries to put the right spot.
You might want to try eye-ball tracking device. Dashers are designed for
that as well. You won't need to use your hand to type with it.
Eric S. Johansson
> I've been kinda following this. I have a cousin who is permanently wheel
> chair bound and doesn't have perfect control of her hands, but still
> manages to use a computer and interact with society. However, the
> idea/thought of disabled programmers was new to me/hadn't ever occurred
> to me.
>
> You say that using your hands is painful, but what about your feet?
> Wouldn't it be possible to rig up some kind of foot peddle for
> shift/caps lock? Kinda like the power peddle used with sowing machines,
> so the hands are free to hold fabric.
>
> I don't mean this in a condescending manor, and I apologize if you take
> it as such. I'm genuinely curious if you think something like this could
> work.
>
> The way I was envisioning it working last night (and I haven't the
> faintest clue how SR works, nor have I ever used SR) was that you would
> hit the foot peddle, which would tell the SR program to capitalize the
> first letter of the next word (a smart shift, basically, so you don't
> end up doing something like ... WONderland -or- "stocks are up 1,0))%
> TOday".)
>
> Possible? Stupid?
>
it's not stupid.
People have used foot pedals for decades for a variety of controls. I don't
think foot pedals would work for me because when I am dictating, I pace.
Standing, sitting, I pace. With a cord headset, I'm forced to stay within about
4 feet of the computer. But what I'm using a Bluetooth headset, I will sometimes
ramble as far as 10 or 15 feet from the computer. It helps if I make the font
larger so I can glance over and see what kind of errors I've gotten.
I really love a Bluetooth headset with speech recognition. It's so liberating.
Your question about foot pedals makes me think of alternative. would it make
sense to have a handheld keyboard which would be used for command-and-control
functionality or as an adjunct to speech recognition use? It would have to be
designed in such a way that it doesn't aggravate a hand injury which may not be
possible. Anyway, just thinking out loud.
MRAB
computer keyboard? "I wrote 5 miles of code before lunch!" :-)
Terry Reedy
As long as we are thinking wildly, how about a pair of
bluetooth-connected switches on a belt or chest band that you could
press with your arms or elbows -- no hands involved. Sort of become a
walking mouse ;-).
Terry
Rhodri James
wrote:
> You can get giant piano keyboards that you step on, so how about a giant
> computer keyboard? "I wrote 5 miles of code before lunch!" :-)
You can get/make MIDI organ pedal-boards (a friend of mine has two). From
there it's just one small step...
:-)
Tim Chase
>> computer keyboard? "I wrote 5 miles of code before lunch!" :-)
>
> You can get/make MIDI organ pedal-boards (a friend of mine has two). From
> there it's just one small step...
Is that a two-step? a box-step? Count it off...slow, slow,
quick, quick. I think I just coded up Conway's Game of Life...
-tkc