pep 8 constants

Steven D'Aprano steven at
Tue Jun 30 01:45:17 EDT 2009

On Mon, 29 Jun 2009 22:37:15 -0400, Eric S. Johansson wrote:

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


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


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 

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?


More information about the Python-list mailing list