Is PEP-8 a Code or More of a Guideline?

[Sergei Organov]

On the other hand, I'm convinced that words_with_underscores, is easier to
read. This is especially true when abbreviations creep into variable
names. It's certainly easier to parse ip_address as compared to IPAddress.
Same with snmp_manager vs SNMPManager.

Well, you don't capitalize abbreviations like that in a classic
CamelCase, I believe. Those names ought to be SnmpManager and
IpAddress. Though there is still problem with digits, e.g., Crc24Accum.

-- Sergei.

 

[Alex Martelli]

Historically, it's only Java and the Windows world (including non-
standard Windows-style C++) that use forcedCase significantly (C#
draws from both).

I remember meeting that style first in the X Window System (now commonly
known as X11, but it was around for a few years before the 11 arrived),
which is a little bit older than Windows and WAY older than Java. I
don't know if X was the first project to use that style consistently.


Alex

 

[Steven D'Aprano]

I remember meeting that style first in the X Window System (now commonly
known as X11, but it was around for a few years before the 11 arrived),
which is a little bit older than Windows and WAY older than Java. I
don't know if X was the first project to use that style consistently.

There was also Hypercard from Apple in (by memory) 1988. Although case was
not significant, handlers were usually written mouseDown, mouseUp,
openStack, openCard, etc.

 

[Paul Rubin]

There was also Hypercard from Apple in (by memory) 1988. Although case was
not significant, handlers were usually written mouseDown, mouseUp,
openStack, openCard, etc.

Apple (*cough*) Xerox PARC (*cough*). I think that style got into the
Macintosh by way of Smalltalk, and got into X11 the same way
indirectly, via the CMU Andrew system and its relatives that also were
influenced by Smalltalk.

 

[Eric S. Johansson]

At first, Guido seemed ambivalent, and commented on the
contentiousness of the issue, but it seems that the "non-English
speakers can more easily find word breaks marked with underscores"
justification tipped the scale in favor of
lower_case_with_underscores.


The PEP itself on www.python.org seems to have been updated as
recently as May 17 of this year, but I don't seen any way to identify
what the change history is.

So, those who are the stewards of the core source code have nailed
down thier coding standard to be l_c_w_u, so if sometime in the future
I find myself working on any code in the Python std libs, l_c_w_u is
the style to be followed. It just looks so old-fashioned...

link.setParseAction(emitLinkHTML)

is spoken

no caps link dot set no space cap parser no space cap action between parens emit
no space cap link HTML jump out

on the other hand,

link.set_parse_action (emit_link_HTML)

is much more friendly to aural interfaces. I've been using speech recognition
since about 1995 when I was injured thanks to programming in high stress,
ergonomically poor environments. as a result, I have become extremely sensitive
to what makes a good interface for hands and for voice. Bumpy case words are
extremely difficult to pronounce for both text-to-speech dependent blind users
and speech recognition (speech to text) dependent users like myself. One
important factor in a speech user interfaces is the difference between what you
say/here and the target text. I can't say for the blind user but I know in the
speech recognition context, the more time you spend thinking about what it is
you say in order to get your desired text, the less brainpower you have for
thinking about the problem.

There are solutions to this problem but unfortunately handicapped users are in a
Catch-22 situation. We know what we need to make our world better. But we
don't have the hands to make our world better. Therefore we have to rely on
those who don't know what we need to make our lives better which doesn't happen.

There are two projects (voice coder and vr-mode) which have started making
things better. Unfortunately, they are are fragile and difficult to install
which defeats the purpose of a good accessibility tool.

I suggest that the first option is encouraging enhanced use of full words joined
by underscores for all public interfaces so that unenhanced speech recognition
or text-to-speech systems can be used in a way we have become accustomed to
living with. This is not to say it's good. Only that we have acquired enough
scar tissue to cope.

the second option would be for some of you to dig in and help some of your
technical kinfolk by improving some tools so that we can start writing Python
code with greater ease.

A huge reason why this is important because the vast majority of software
developers who are injured fall off the economic ladder. They leave the
profession and had very few options for work that doesn't involve significant
handy is. The last time I looked at the numbers, in the US somewhere north of
60,000 developers per year are injured. Some recover (kind of). Others, like I
said, dropout. Tools to make programming by voice easier and not as damaging to
the throat as unenhanced speech recognition with bumpy caps symbols, would
significantly improve the lives of people you probably know and possibly your
own life in the future.

Feel free to contact me off list if you want.

---eric
(founding member of Open Source Speech Recognition Initiative nonprofit)

warning: NaturallySpeaking in use. It makes mistakes. I correct some.

 

[Frank Swarbrick]

I really like lisp's convention of using dashes instead of underscores,
i.e. ip-address and snmp-manager. I think the only reason most languages
don't use that is the parsing ambiguity, but if you required white space
around all operators, then "ip-address" would unambiguously be a variable
name and "ip - address" would be a subtraction expression.

Then you'd really love COBOL!



Frank
COBOL programmer for 10+ years

 

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

A huge reason why this is important because the vast majority of software
developers who are injured fall off the economic ladder. They leave the
profession and had very few options for work that doesn't involve significant
handy is. The last time I looked at the numbers, in the US somewhere north of
60,000 developers per year are injured. Some recover (kind of). Others, like I

I'm curious, where did you get that statistic? Assuming the US hosts
no more than 6M developers, then 60,000 is >=1% which is an alarming
amount.

 

[Warren Stringer]

Hi Eric,

You make a compelling argument for underscores. I sometimes help a visually
impaired friend with setting up his computers.

I'm wondering about the aural output to you second example:

link.set_parse_action(emit_link_HTML)

Does it sound like this:

link dot set under parse under action space between parens emit under link
under HTML jump out

Also, does how HTML read? Is it "H T M L" or "cap H cap T cap M cap L" ?

How many python programmers can reconfigure their speech-to-text and
text-to-speech converter? Isn't there a Python based accessibility project?
Perhaps a few lines of script to add CamelBack support, using an amplitude
increase for initial caps and maybe lingering on the initial phoneme for an
extra 100 milliseconds. So then, the above example would read:

"camel link dot set Parse Action between parens emit Link H T M L jump out"

Warren

Eric S. Johansson wrote or said:

link.setParseAction(emitLinkHTML)

is spoken

no caps link dot set no space cap parser no space cap action between
parens emit no space cap link HTML jump out

on the other hand,

link.set_parse_action (emit_link_HTML)

<snip>

 

[Eric S. Johansson]

Hi Eric,

You make a compelling argument for underscores. I sometimes help a visually
impaired friend with setting up his computers.

I'm wondering about the aural output to you second example:

link.set_parse_action(emit_link_HTML)

Does it sound like this:

unfortunately, I do not have text to speech set up on this machine as I'm saving
the storage for more MP3s.

link dot set under parse under action space between parens emit under link
under HTML jump out

it would probably say underscore instead of under and left ( and right ) (too
much work is make it spell out the symbol).

Also, does how HTML read? Is it "H T M L" or "cap H cap T cap M cap L" ?

probably HTML. Remember case is not apparent in an aural interface.

How many python programmers can reconfigure their speech-to-text and
text-to-speech converter?

It's really difficult. I'm getting by right now with some minimal macros to
start classes and methods as well as things like putting a: on the end of the
line. But it is really primitive. When I had voice coder working, it was
pretty good and the only problem was command surface area.

Isn't there a Python based accessibility project?

You might be thinking of voice coder and VR-mode for Emacs. Both projects need
help, via-mode probably the most useful to the beginning user but combining the
two would make a very nice voice driven Python IDE. Of course if somebody
wanted to adapt it to another IDE that was nice and not too expensive, I think
people would not say no to that either.

Perhaps a few lines of script to add CamelBack support, using an amplitude
increase for initial caps and maybe lingering on the initial phoneme for an
extra 100 milliseconds. So then, the above example would read:

I can tell you've never used speech recognition. if you do that for a few
weeks, you'll find yourself being reluctant to talk and considering using Morse
code sent by big toe as your primary computer interface. QLF OM?

Seriously, amplitude and timing information is gone by the time we get
recognition events. This is a good thing because it eliminates problems caused
by individual habits and physiological traits.

As I've said before, I think the ultimate programming by voice environment is
one in which the environment is aware of what symbols can be spoken and uses
that information to improve accuracy. This will also allow for significant
shortcuts in what you say in order to get the right code. The problem with this
being that it needs to work when the code is broken. And I don't mean a little
broken, I mean the kind of broken it gets when you are ripping out the
implementation of one concept and putting in a new one.

Yes, it's a hard problem.

---eric

 

[sjdevnull]

unfortunately, I do not have text to speech set up on this machine as I'm saving
the storage for more MP3s.


it would probably say underscore instead of under and left ( and right ) (too
much work is make it spell out the symbol).




probably HTML. Remember case is not apparent in an aural interface.

I don't do text-to-speech at all, but I do often have someone ask
"what's the method for blah?" and case is important there.

In such cases, I'd say "lowercase emit underscore link underscore all
caps H T M L".

For emitLinkHTML it'd be "lowercase emit capital-L link all-caps H T M
L".
For emitLinkHtml it'd be "lowercase emit capital-L link capital-H H T
M L".

FWIW, even though I think proper-case-with-seperators is greatly
preferrable to camelCase, I certainly don't think that speaking the
names is a really major point.

 

[Tim Roberts]

Then you'd really love COBOL!



Frank
COBOL programmer for 10+ years

Hey, did you hear about the object-oriented version of COBOL? They call it
"ADD ONE TO COBOL".

 

[John DeRosa]

+1 QOTW

Hey, did you hear about the object-oriented version of COBOL? They call it
"ADD ONE TO COBOL".

 

[Szabolcs Nagy]

+1 QOTW

actually it is "ADD 1 TO COBOL GIVING COBOL"

http://en.wikipedia.org/wiki/COBOL#Aphorisms_and_humor_about_COBOL

 

[Joe Riopel]

Using camel case instead of the under_score means less typing. I am lazy.

fooBar
foo_bar

 

[Szabolcs Nagy]

Using camel case instead of the under_score means less typing. I am lazy.

fooBar
foo_bar

camel case makes source code extremely ugly in weird disturbing way

YMMV

 

[kc]

Using camel case instead of the under_score means less typing. I am lazy.

fooBar
foo_bar

Each requires exactly the same number of key strokes when I do the
math. (Too lazy to explain further...)

 

[John J. Lee]

John J. Lee wrote: [...]

Even as a native English speaker, some of these are tricky --
e.g. urllib has a private class named "addinfourl". "What's this
'fourl' we're adding in?"
(In fact, the method adds attributes named "info" and "url". Even
though I've read that name hundreds of times, my brain always insists
on reading it "add in fourl".)
This is the worst of both worlds: inconsistent and hard to
understand.

Sounds like a good candidate for a rename in Python 3000.

The point was the general issue, not the particular case. The
problems associated with this naming style do not go away when bad
cases like "addinfourl" go away:

1. Other runtogether names are less tricky than "addinfourl", but the
issue is still there. These names (e.g. "getitem") are considered
good Python standard library style. This particular point involves
a trade-off and is debatable, I accept.

More important, and less debatable:

2. The runtogether style makes *many* names hard to remember because
of the runtogether / kept_apart choice.

3. The style introduces tiresome inconsistency in naming decisions.


John

 

[Dave Hansen]

Apologies for jumping into the thread late.

Which dates back to the days of ASR-33's which only had one case (upper

The date is about right (actually, a little early: ASR-33, 1965; C,
about 1970), but you can't program C on an ASR-33. Keywords are all
lower case, and always have been. "IF" is a syntax error...

case, as a matter of fact). Does nobody else remember C compilers which
accepted \( and \) for { and }?

I don't, but modern conforming compilers are supposed to accept ??< or
<% for { and ??> or %> for }. Makes it awful hard to read, though,
IMHO.

Regards,

-=Dave

P.S. CamelCase sucks. ;-)

 

[Carl Banks]

Steve, sorry for taking your thread down a rathole. I hope we can
move any further PEP-8-related discussion (if the point merits any) to
this thread.

Identifiers should just allow spaces.

first element.get item(selected value)


This is not a joke. I don't mean Python should necessarily do this
(though it could be done without any ambiguity or backward
incompatibility: there is currently nowhere in Python where two
identifiers can be separated by only a space), but new languages
should be designed to allow it.


Carl Banks

 

[Frank Swarbrick]

Hey, did you hear about the object-oriented version of COBOL? They call it
"ADD ONE TO COBOL".

I know you were joking, but the COBOL 2002 standard implements OO.
It's OK, but quite obviously "bolted on".

Frank
Python programmer for 3+ days