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

[Paul McGuire]

I'm starting a new thread for this topic, so as not to hijack the one
started by Steve Howell's excellent post titled "ten small Python
programs".

In that thread, there was a suggestion that these examples should
conform to PEP-8's style recommendations, including use of
lower_case_with_underscores style for function names. I raised some
questions about this suggestion, since I liked the names the way they
were, but as a result, part of the discussion has drifted into a
separate track about PEP-8, and naming styles.

I was under the impression that lower_case_with_underscores was a
dated recommendation, and that recent practice is more inclusive of
mixedCase style identifiers. On the contrary, Steven Bethard
straightened me out, saying that PEP-8 used to accept either style,
but has been amended to accept only lower_case_with_underscores.

My latest thought on the topic relates back to the Martin v. Löwis
thread-that-would-not-die requesting feedback about PEP 3131, on
adding support for non-ASCII identifiers in Py3K. I posted an out-of-
curiosity comment asking about how underscore separators mix with
Unicode identifiers, including the mechanics of actually typing an
underscore on a non-US keyboard. At this point, I realized that I was
taking things too far off-topic, so I decided to start a new thread.

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.

-- Paul

[Stefan Sonnenberg-Carstens]

Paul McGuire schrieb:

I'm starting a new thread for this topic, so as not to hijack the one
started by Steve Howell's excellent post titled "ten small Python
programs".

In that thread, there was a suggestion that these examples should
conform to PEP-8's style recommendations, including use of
lower_case_with_underscores style for function names. I raised some
questions about this suggestion, since I liked the names the way they
were, but as a result, part of the discussion has drifted into a
separate track about PEP-8, and naming styles.

I was under the impression that lower_case_with_underscores was a
dated recommendation, and that recent practice is more inclusive of
mixedCase style identifiers. On the contrary, Steven Bethard
straightened me out, saying that PEP-8 used to accept either style,
but has been amended to accept only lower_case_with_underscores.

My latest thought on the topic relates back to the Martin v. Löwis
thread-that-would-not-die requesting feedback about PEP 3131, on
adding support for non-ASCII identifiers in Py3K. I posted an out-of-
curiosity comment asking about how underscore separators mix with
Unicode identifiers, including the mechanics of actually typing an
underscore on a non-US keyboard. At this point, I realized that I was
taking things too far off-topic, so I decided to start a new thread.

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.

-- Paul

I prefer mixedCaseStyle, and I think that should be "standard", as this
style is commonly
used in all "major" languages , for example Java,C++,C#.
It shortens the identifiers but leaves the meaning intact.

[Steven Bethard]

Stefan Sonnenberg-Carstens wrote:

Paul McGuire schrieb:

>I'm starting a new thread for this topic, so as not to hijack the one
started by Steve Howell's excellent post titled "ten small Python
programs".

In that thread, there was a suggestion that these examples should
conform to PEP-8's style recommendations, including use of
lower_case_with_underscores style for function names. I raised some
questions about this suggestion, since I liked the names the way they
were, but as a result, part of the discussion has drifted into a
separate track about PEP-8, and naming styles.

I prefer mixedCaseStyle, and I think that should be "standard", as this
style is commonly
used in all "major" languages , for example Java,C++,C#.
It shortens the identifiers but leaves the meaning intact.

The argument for under_score_names is usually that non-native speakers
can more easily find the word boundaries. Not being a non-native speaker
;-) I can't verify that one, but it's pretty plausible given the current
amount of money spent on research on automatic word-segmentation for
languages like Chinese. =)

STeVe

[OKB (not okblacke)]

Paul McGuire wrote:

I was under the impression that lower_case_with_underscores was a
dated recommendation, and that recent practice is more inclusive of
mixedCase style identifiers. On the contrary, Steven Bethard
straightened me out, saying that PEP-8 used to accept either style,
but has been amended to accept only lower_case_with_underscores.

Underscores are harder to type than any alphanumeric character.
Thus I support their use in situations where difficulty of typing is
desirable (e.g., magic method names) and I detest them in all other
situations.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

[Paul McGuire]

On May 27, 1:25 am, Steven Bethard <[e-mail]:

Stefan Sonnenberg-Carstens wrote:

Paul McGuire schrieb:

I'm starting a new thread for this topic, so as not to hijack the one
started by Steve Howell's excellent post titled "ten small Python
programs".

In that thread, there was a suggestion that these examples should
conform to PEP-8's style recommendations, including use of
lower_case_with_underscores style for function names. I raised some
questions about this suggestion, since I liked the names the way they
were, but as a result, part of the discussion has drifted into a
separate track about PEP-8, and naming styles.

I prefer mixedCaseStyle, and I think that should be "standard", as this
style is commonly
used in all "major" languages , for example Java,C++,C#.
It shortens the identifiers but leaves the meaning intact.

The argument for under_score_names is usually that non-native speakers
can more easily find the word boundaries. Not being a non-native speaker
;-) I can't verify that one, but it's pretty plausible given the current
amount of money spent on research on automatic word-segmentation for
languages like Chinese. =)

STeVe- Hide quoted text -

- Show quoted text -

Here is the thread from python-dev where this change (from "mixedCase
is no better or worse than lower_case_with_underscores" to "should use
l_c_w_u") was discussed, a year ago last December:

http://mail.python.org/pipermail/pyt...er/058750.html

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

Whatev.

-- Paul

[Ben Finney]

Paul McGuire <pt***@austin.rr.comwrites:

At this point, I realized that I was taking things too far
off-topic, so I decided to start a new thread.

So, uh, what's the purpose of this thread? Did you have a specific
point to start off with, or a question to ask?

--
\ "It seems intuitively obvious to me, which means that it might |
`\ be wrong." -- Chris Torek |
_o__) |
Ben Finney

[Carsten Haese]

On Sun, 2007-05-27 at 07:30 +0000, OKB (not okblacke) wrote:

Underscores are harder to type than any alphanumeric character.

This is a discussion about underscores versus capital letters denoting
the word boundaries in identifiers. How is an underscore harder to type
than a capital letter?

--
Carsten Haese
http://informixdb.sourceforge.net

[Gabriel Genellina]

En Sun, 27 May 2007 10:20:49 -0300, Carsten Haese <ca*****@uniqsys.com>
escribió:

On Sun, 2007-05-27 at 07:30 +0000, OKB (not okblacke) wrote:

> Underscores are harder to type than any alphanumeric character.

This is a discussion about underscores versus capital letters denoting
the word boundaries in identifiers. How is an underscore harder to type
than a capital letter?

Underscores are not always easily available on non us-layout keyboards,
like \ and @ and many other "special" characters. A language that requires
more symbols than the 26 english letters has to make room somewhere -
keyboards usually have "only" 102 keys (or 105 nowadays).
Back to the style, I think that mixedCaseIsEnough to
determine_word_endings and looksBetter. alllowercase is hard to read.

--
Gabriel Genellina

[Paul McGuire]

On May 27, 3:35 am, Ben Finney <[e-mail]>
wrote:

Paul McGuire <[e-mail]:

At this point, I realized that I was taking things too far
off-topic, so I decided to start a new thread.

So, uh, what's the purpose of this thread? Did you have a specific
point to start off with, or a question to ask?

--
\ "It seems intuitively obvious to me, which means that it might |
`\ be wrong." -- Chris Torek |
_o__) |
Ben Finney

(Nice sig quote, by the way.)

Mostly, I started this thread so any discussion of
lower_case_with_underscores (l_c_w_u) vs. mixedCase naming styles
would not (further) clutter up Steve Howell's thread.

To recap:
- I was surprised at the comments to convert Steve's example to
l_c_w_u, as the last time I read PEP-8, it had the more liberal "use
whichever you prefer, just be consistent" wording.
- I posted one comment that I thought l_c_w_u looks old-fashioned, and
was an odd choice in the face of mixedCase, which has been adopted as
de facto practice in recent languages.
- I also mused on the implications for l_c_w_u in the face of Py3K's
recent acceptance of non-ASCII identifiers, and added as a related
point my own personal experience with typing '_' on a non-US keyboard
layout.
- At this point, I tracked down the python-dev archive of the
discussion thread that led to the stricter version of PEP-8, and I can
see that this is a windmill (like the choice of '@' sign for
decorators) that is not worth tilting at.

It is a bit reassuring that I am not the only one who turns a blind
eye to this part of the PEP, that l_c_w_u bothers others as well. But
as to the further purpose for this thread, I think there is little to
none. We will continue to see std lib code written using l_c_w_u.
Ordinarily, this would little concern me, since I go to read std lib
code about once/year. But it does mean that additions to the external
API to the std lib will contain method calls such as get_files,
send_message, delete_record, etc. I think this just promotes a
perception of Python as "so last century."

It would also seem we will continue to see 3rd party developers use
whatever their personal taste and/or project coding standards
dictate. So for these users, this part of the PEP is "not really a
code, its more of a guideline."*

-- Paul

*same joke was in Ghostbusters and Pirates of the Caribbean, Pt.1

[sjdevnull]

Stefan Sonnenberg-Carstens wrote:

Paul McGuire schrieb:

I'm starting a new thread for this topic, so as not to hijack the one
started by Steve Howell's excellent post titled "ten small Python
programs".

In that thread, there was a suggestion that these examples should
conform to PEP-8's style recommendations, including use of
lower_case_with_underscores style for function names. I raised some
questions about this suggestion, since I liked the names the way they
were, but as a result, part of the discussion has drifted into a
separate track about PEP-8, and naming styles.

I was under the impression that lower_case_with_underscores was a
dated recommendation, and that recent practice is more inclusive of
mixedCase style identifiers. On the contrary, Steven Bethard
straightened me out, saying that PEP-8 used to accept either style,
but has been amended to accept only lower_case_with_underscores.

My latest thought on the topic relates back to the Martin v. Lo:wis
thread-that-would-not-die requesting feedback about PEP 3131, on
adding support for non-ASCII identifiers in Py3K. I posted an out-of-
curiosity comment asking about how underscore separators mix with
Unicode identifiers, including the mechanics of actually typing an
underscore on a non-US keyboard. At this point, I realized that I was
taking things too far off-topic, so I decided to start a new thread.

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.

-- Paul

I prefer mixedCaseStyle, and I think that should be "standard", as this
style is commonly
used in all "major" languages , for example Java,C++,C#.
It shortens the identifiers but leaves the meaning intact.

Actually, proper_case is standard in C++ (see, e.g., the naming
section of http://www.research.att.com/~bs/bs_faq2.html ) . And C is
still more common than Java, and Perl and Lisp are about as common as
C#--all use proper case (though Lisp uses - instead of _).
Historically, it's only Java and the Windows world (including non-
standard Windows-style C++) that use forcedCase significantly (C#
draws from both).

The underscore version is not "lower case"; it is "proper case"--case
is used as in normal English. Compare plot_line_slope() vs.
plot_line_Besenheim(); with the underscore method, you preserve all
the natural meaning of case. Especially when you have, say, acronyms
in variable names, forcedCase can be somewhat confusing even for
native English speakers; the style forces you to use a specific case
for naming convention reasons, losing the natural meaning of the case.

[OKB (not okblacke)]

Carsten Haese wrote:

On Sun, 2007-05-27 at 07:30 +0000, OKB (not okblacke) wrote:

> Underscores are harder to type than any alphanumeric
character.

This is a discussion about underscores versus capital letters
denoting the word boundaries in identifiers. How is an underscore
harder to type than a capital letter?

It is harder in that the key that has the underscore on it is quite
out of the way compared to any letter key.
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

[Ben Finney]

"OKB (not okblacke)" <br************@NObrenSPAMbarn.netwrites:

Underscores are harder to type than any alphanumeric character.

I know of no keyboard layout in common use where it's more complicated
than <Shift>+<some key>, exactly the same as a single uppercase
letter. Care to enlighten me?

--
\ "Conscience is the inner voice that warns us somebody is |
`\ looking." -- Henry L. Mencken |
_o__) |
Ben Finney

[Ben Finney]

Stefan Sonnenberg-Carstens <st***************@pythonmeister.comwrites:

I prefer mixedCaseStyle, and I think that should be "standard",

I dislike it. It's inconsistent, and confusingly similar to
TitleCaseStyle used for class names in Python.

as this style is commonly used in all "major" languages , for
example Java,C++,C#.

Is C no longer a "major" language? The long-standing convention there
is for lower_case_with_underscores.

It shortens the identifiers but leaves the meaning intact.

The shortening is both minor, and irrelevant: clarity is worth more
than shorter names merely for the sake of shorter names.

--
\ "If you're a young Mafia gangster out on your first date, I bet |
`\ it's real embarrassing if someone tries to kill you." -- Jack |
_o__) Handey |
Ben Finney

[Paul Rubin]

Paul McGuire <pt***@austin.rr.comwrites:

code about once/year. But it does mean that additions to the external
API to the std lib will contain method calls such as get_files,
send_message, delete_record, etc. I think this just promotes a
perception of Python as "so last century."

I think you've got it backwards; the godawful MixedCase style goes
back to Smalltalk, which couldn't use underscores in identifiers
because it had assigned some other purpose to that character.
That it was picked up by Java is not evidence of anything other
than Java's Vogon-like tastelessness, and of course C# uses it since
C# is basically a Java dialect.

[Roy Smith]

Ben Finney <bi****************@benfinney.id.auwrote:

Is C no longer a "major" language? The long-standing convention there
is for lower_case_with_underscores.

Which dates back to the days of ASR-33's which only had one case (upper
case, as a matter of fact). Does nobody else remember C compilers which
accepted \( and \) for { and }?

[Ben Finney]

Paul McGuire <pt***@austin.rr.comwrites:

It is a bit reassuring that I am not the only one who turns a blind
eye to this part of the PEP, that l_c_w_u bothers others as well.

I see similar support for lower_case, and opposition to
camelCase. It's nice that we're both reassured by what we see. What
now?

We will continue to see std lib code written using l_c_w_u.
Ordinarily, this would little concern me, since I go to read std lib
code about once/year. But it does mean that additions to the
external API to the std lib will contain method calls such as
get_files, send_message, delete_record, etc. I think this just
promotes a perception of Python as "so last century."

If clearly-readable code is "so last century", I don't see how that's
a negative.

It would also seem we will continue to see 3rd party developers use
whatever their personal taste and/or project coding standards
dictate. So for these users, this part of the PEP is "not really a
code, its more of a guideline."*

Many of these libraries have users, and even primary developers, who
hope to find the modules added to the standard library one day. I
think using lower_case for names is good style in all Python code, for
consistency.

--
\ "You could augment an earwig to the point where it understood |
`\ nuclear physics, but it would still be a very stupid thing to |
_o__) do!" -- The Doctor, _The Two Doctors_ |
Ben Finney

[Maric Michaud]

Ben Finney a écrit :

Paul McGuire <pt***@austin.rr.comwrites:

>It is a bit reassuring that I am not the only one who turns a blind
eye to this part of the PEP, that l_c_w_u bothers others as well.

I see similar support for lower_case, and opposition to
camelCase. It's nice that we're both reassured by what we see. What
now?

So it's actually a matter of taste, and that's why PEP 8 exists, to
answer the subject's question, make decision about conventions when only
taste is in balance, am I wrong ?

Asking the question is like asking : "I don't like the convention, can I
use another one for myself ?" I think the answer is, of course, yes, but
it is highly discouraged... (and that's why PEP 8 exists after all).

[John J. Lee]

Paul McGuire <pt***@austin.rr.comwrites:
[...]

http://mail.python.org/pipermail/pyt...er/058750.html

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.

[...]

That rationale seems undermined by the frequent use of runtogether
names in the standard library. These can be confusing even to native
speakers. And every time you come up with a new name, or try to
remember an old one, you have to decide or remember whether it's
likethis or like_this.

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

[Steven Bethard]

John J. Lee wrote:

Paul McGuire <pt***@austin.rr.comwrites:
[...]

>http://mail.python.org/pipermail/pyt...er/058750.html

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.

[...]

That rationale seems undermined by the frequent use of runtogether
names in the standard library. These can be confusing even to native
speakers. And every time you come up with a new name, or try to
remember an old one, you have to decide or remember whether it's
likethis or like_this.

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.

STeVe

[Roy Smith]

In article <Ka******************************@comcast.com>,
Steven Bethard <st************@gmail.comwrote:

Stefan Sonnenberg-Carstens wrote:

Paul McGuire schrieb:

I'm starting a new thread for this topic, so as not to hijack the one
started by Steve Howell's excellent post titled "ten small Python
programs".

In that thread, there was a suggestion that these examples should
conform to PEP-8's style recommendations, including use of
lower_case_with_underscores style for function names. I raised some
questions about this suggestion, since I liked the names the way they
were, but as a result, part of the discussion has drifted into a
separate track about PEP-8, and naming styles.

I prefer mixedCaseStyle, and I think that should be "standard", as this
style is commonly
used in all "major" languages , for example Java,C++,C#.
It shortens the identifiers but leaves the meaning intact.

The argument for under_score_names is usually that non-native speakers
can more easily find the word boundaries. Not being a non-native speaker
;-) I can't verify that one, but it's pretty plausible given the current
amount of money spent on research on automatic word-segmentation for
languages like Chinese. =)

STeVe

I've gone through a few different flavors of composite name schemes over
the years (starting with FORTRAN's 6 upper case character limit). When
first exposed to camelCase, I thought it was horrible. Eventually, I came
to like it.

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.

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.

[Sergei Organov]

Roy Smith <ro*@panix.comwrites:
[...]

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]

sj*******@yahoo.com <sj*******@yahoo.comwrote:

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]

On Mon, 28 May 2007 14:12:33 -0700, Alex Martelli wrote:

sj*******@yahoo.com <sj*******@yahoo.comwrote:

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

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

[Paul Rubin]

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:

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]

Paul McGuire wrote:

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]

Roy Smith wrote:

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

On 5/29/07, Eric S. Johansson <es*@harvee.orgwrote:

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.

--
mvh Björn

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

Warren Stringer wrote:

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]

On May 29, 3:22 pm, "Eric S. Johansson" <[e-mail]:

Warren Stringer wrote:

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.

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]

Frank Swarbrick <in*****@earthlink.netwrote:

>
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".
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[John DeRosa]

+1 QOTW

On Wed, 30 May 2007 06:18:36 GMT, Tim Roberts <ti**@probo.comwrote:

>Frank Swarbrick <in*****@earthlink.netwrote:

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

[Szabolcs Nagy]

John DeRosa wrote:

+1 QOTW

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

actually it is "ADD 1 TO COBOL GIVING COBOL"

http://en.wikipedia.org/wiki/COBOL#A...or_about_COBOL

[Joe Riopel]

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

fooBar
foo_bar

[Szabolcs Nagy]

Joe Riopel wrote:

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

[John J. Lee]

Steven Bethard <st************@gmail.comwrites:

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.

On May 27, 3:25 pm, Roy Smith <[e-mail]:

Ben Finney <[e-mail]:

Is C no longer a "major" language? The long-standing convention there
is for lower_case_with_underscores.

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]

On May 26, 11:36 pm, Paul McGuire <[e-mail]:

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]

Tim Roberts wrote:

Frank Swarbrick <in*****@earthlink.netwrote:

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

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

[Roy Smith]

Dave Hansen <id**@hotmail.comwrote:

On May 27, 3:25 pm, Roy Smith <[e-mail]:

Ben Finney <[e-mail]:

Is C no longer a "major" language? The long-standing convention there
is for lower_case_with_underscores.

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.

Damn, I wish I had known that at the time :-)

Keywords are all
lower case, and always have been. "IF" is a syntax error...

I doubt it still works on anything made today, but back in those days, if
you typed your login name in all upper case, the terminal was put into
lcase mode. Upper case on input was automatically converted to lower case.
You typed "IF", the C compiler saw "if", and it all worked. Including \(
and \) for curly braces.

[Charles Sanders]

Dave Hansen wrote:

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

But the Unix terminal drivers of the day for
upper case only terminals translated to lower case and
you had to enter \A to get an upper case A, and so on.

Still hangs around in the stty options iuclc,
-iuclc, olcuc and -olcuc - You can make an x-term window
look like an old upper case only terminal.

I don't know if any still do it, but old unices
used to detect on logon if you typed your user name and
password in all caps and then turned on the iuclc and
olcuc options, assuming that the reason for the all caps
was a upper case only terminal - great fun if you hit caps
lock by accident.
Charles

[kc]

"Joe Riopel" <go****@gmail.comwrites:

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

[Joe Riopel]

Each requires exactly the same number of key strokes when I do the

math. (Too lazy to explain further...)

foo_bar
f, o, o, shift + underscore, b, a, r = 8
fooBar
f, o, o, shift + b, a, r = 7

[Marc 'BlackJack' Rintsch]

In <64**********@mail.com>, kc wrote:

"Joe Riopel" <go****@gmail.comwrites:

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

Let's leave 'foo' and 'ar':

1. B = <Shift+ <B= 2 key strokes.
2. _b = <Shift+ <-and <b= 3 key strokes.

At least on my keyboard + layout.

Ciao,
Marc 'BlackJack' Rintsch

[Christophe]

Joe Riopel a écrit :

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

foo_bar
f, o, o, shift + underscore, b, a, r = 8
fooBar
f, o, o, shift + b, a, r = 7

f, o, o, _, b, a, r = 7
f, o, o, shift + b, a, r = 8

Also the shift+b is much more work than 2 keypresses IMHO. On the other
hand, the underscore is done by pressing the 8 key without any other
modifier which is very easy and accessible. Yeap, french layout rules
for that naming convention :)

[Eric S. Johansson]

sj*******@yahoo.com wrote:

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.

unless you or someone with working hands helps fix up voicecoder, it is a major
point for people like me.

http://voicecode.iit.nrc.ca/

[John DeRosa]

On Wed, 30 May 2007 20:41:32 -0600, Frank Swarbrick
<in*****@earthlink.netwrote:

>Tim Roberts wrote:

>Frank Swarbrick <in*****@earthlink.netwrote:

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

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

Exactly the same situation as the OO in C++...

[Warren Stringer]

Perhaps a foot pedal? Hmmm....

My two cellphones don't like underbars very much. And the shift key -- while
much easier -- still is cumbersome. If outlook didn't autocaps on me, this
message would be in all lowercase. In fact, when communicating with friends
from outlook, to their sms, I take the trouble to correct my outlook's
autocorrect.

underbars are more of a reach and harder to read when you use a really nice
font. camelBack -- damn, I just had to correct outlook's autocorrect on
camelback -- so, what was I saying, oh yes -- camelBackNames are just
freaking weird. Sooooo....

i.prefer.dots -- no, seriously

sure it's slow, but forces you the think about names in a new way.

or, perhaps going deep is sacrilege?

-----Original Message-----
From: py*********************************@python.org [mailto:python-list-
bo*********************@python.org] On Behalf Of Christophe
Sent: Thursday, May 31, 2007 6:18 AM
To: py*********@python.org
Subject: Re: Is PEP-8 a Code or More of a Guideline?

Joe Riopel a écrit :>Each requires exactly the same number of key
strokes when I do the>math. (Too lazy to explain further...) foo_bar>
f, o, o, shift + underscore, b, a, r = 8fooBarf, o, o, shift + b, a, r
= 7
f, o, o, _, b, a, r = 7f, o, o, shift + b, a, r = 8
Also the shift+b is much more work than 2 keypresses IMHO. On the other
hand, the underscore is done by pressing the 8 key without any other
modifier which is very easy and accessible. Yeap, french layout rules for
that naming convention :)--
http://mail.python.org/mailman/listinfo/python-list

[Wildemar Wildenburger]

Warren Stringer wrote:

i.prefer.dots -- no, seriously

sure it's slow, but forces you the think about names in a new way.

Are you now suggesting that "addinfourl()" should actually be called
"url()", placed in a module named "info", which is part of a package
called "add", so as to enable you to call "add.info.url()"?
May I assume it wouldn't bother you having millions of packages
containing only one module each (plus their __init__.py's) where the
modules only provide around one function.

OK, go ahead. Modify the whole Python-library to conform to that style
and then send us the bill from your psychiatrist. This may be a nice
idea for the Next Overwhelming Programming Escapade (Codename: NOPE),
but you can just forget about it in Python.
Excuse my mocking, but while typing dots is far easier for US and German
keyboards, this may be a whole different story for any other layout (I
forget how it goes with the french layout; shift for the dot or the comma?).

Back to the drawing boards!
;)
/W

PS
You may want to elaborate on the "new way to think about names". Maybe
you have a point which I just don't see.

[Tim Roberts]

Carl Banks <pa************@gmail.comwrote:

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

That's an interesting idea. It would, perhaps, allow you to write programs
that read more like prose.

However, it would certainly make the parser more complicated, because it
could no longer be context-insensitive. For example, if I had identifiers
called "mine" and "not mine", how would it parse this:

if not mine:
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.