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

[Paul McGuire]

On May 27, 3:35 am, Ben Finney <bignose+hates-s... at benfinney.id.au>
wrote:
> Paul McGuire <p... at austin.rr.com> writes:
> > 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