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

P

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
 
S

Stefan Sonnenberg-Carstens

Paul said:
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.
 
S

Steven Bethard

Stefan said:
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
 
O

OKB (not okblacke)

Paul said:
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
 
P

Paul McGuire

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/python-dev/2005-December/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
 
B

Ben Finney

Paul McGuire said:
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?
 
B

Ben Finney

OKB (not okblacke) said:
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?
 
B

Ben Finney

Stefan Sonnenberg-Carstens said:
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.
 
C

Carsten Haese

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

Gabriel Genellina

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

Paul McGuire

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
 
S

sjdevnull

Stefan said:
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.
 
O

OKB (not okblacke)

Carsten said:
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
 
P

Paul Rubin

Paul McGuire said:
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.
 
R

Roy Smith

Ben Finney said:
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 }?
 
B

Ben Finney

Paul McGuire said:
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.
 
M

Maric Michaud

Ben Finney a écrit :
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).
 
J

John J. Lee

Paul McGuire said:
http://mail.python.org/pipermail/python-dev/2005-December/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
 
S

Steven Bethard

John said:
Paul McGuire said:
http://mail.python.org/pipermail/python-dev/2005-December/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
 
R

Roy Smith

Steven Bethard said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top