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

[Roy Smith]

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]

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

 

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

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 :

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]

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]

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?

 

[Wildemar Wildenburger]

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]

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:

 

[Hendrik van Rooyen]

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]

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.

 

[Ben Finney]

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.