pep 8 constants

[Eric S. Johansson]

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