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

[Hendrik van Rooyen]

"Tim Roberts" <ti**@probo.comwrote:

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:

The rules would have to change - currently you cannot use a reserved
word (or keyword) as an identifier. It would have to be legislated that
you cannot use a keyword as part of a space linked identifier - this should
not be a train smash to implement, and if it makes it easier for people with
disabilities, its probably not too much to ask.

Hey, it could lead to self documenting code such as:

That which will be returned = []
for The current element from the iterator in My iterable thingy:
My temporary variable called x = The current element from the iterator
if My temporary variable called x == None:
break
else:
Temporary variable = Complicated function(My temporary variable called
x)
That which will be returned.append(Temporary variable)

and so forth - kind of verbose, but clear...

Note that I have also just invented a rule - I shall call it
The German Noun Copycat Readability Style and Parser
Simplification Capitalisation Rule for short. It reads:

Space linked identifiers must start with a capital letter.

- Hendrik

[Ben Finney]

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

Identifiers should just allow spaces.

first element.get item(selected value)

This is not a joke.

It would be a hideous pain to read though. My decades of schooling
have carved channels in my brain that recognise the space as a
*separator* for lexical elements, and any non-space separator as being
lower down the hierarchy. The parentheses just look awkward, but the
period is *definitely* joining tokens together whereas the spaces
separate them.

Thus, the example you give parses as the tokens "first",
"element.get", "item", "selected", "value".

I don't see any language with the characteristics you describe being
at all useful until the major natural language of programmers ceases
to use spaces this way.

--
\ "First they came for the verbs, and I said nothing, for verbing |
`\ weirds language. Then, they arrival for the nouns and I speech |
_o__) nothing, for I no verbs." -- Peter Ellis |
Ben Finney

[Ben Finney]

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

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

Using camelCase instead of lower_case means harder reading. I am lazy.

Remember: a program is read by humans much more often than it is written.

--
\ "If you saw two guys named Hambone and Flippy, which one would |
`\ you think liked dolphins the most? I'd say Flippy, wouldn't |
_o__) you? You'd be wrong, though. It's Hambone." -- Jack Handey |
Ben Finney