pep 8 constants

[Lie Ryan]

Eric S. Johansson wrote:
> 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)

>>>>> 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.

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.