why no camelCase in PEP 8?

[Lance E Sloan]

I've been using Python for about 18 years. Several things have changed in the language in those years. I don't disagree with most of it, but one of the things that annoys me is the disapproval of using camelCase to name symbols such as variables, functions, etc.

I think PEP 8, the "Style Guide for Python Code" (https://www.python.org/dev/peps/pep-0008/), came out shortly after I began using Python. I think the old habits of the people I worked with and the relative lack of tools like Flake8 and Pylint led to the standard being ignored. However, now I see many developers really want to adhere to the standard.

My preference for using camelCase (in PEP 8, AKA mixedCase) is putting me at odds with my colleagues, who point to PEP 8 as "the rules". I have reasons for my preferring camelCase. I suspect the reasons the PEP 8 authors have for not using it are probably as strong as my reasons. So our reasons probably nullify each other and what's left is simple preference.

So, I'd like to know what was the reason behind favoring snake_case (AKA lower_case_with_underscores) in PEP 8 instead of camelCase.

Does anyone in this group know?

[Chris Angelico]

PEP 8 is a style guide for the Python standard library. It is the
rules you must comply with if you are submitting a patch *to Python
itself*. Nobody ever requires you to comply with it for any other
code.

ChrisA

[Paul Rubin]

Lance E Sloan <sloan...@gmail.com> writes:
> I have reasons for my preferring camelCase.

They can't be any good ;-).

> So, I'd like to know what was the reason behind favoring snake_case
> (AKA lower_case_with_underscores) in PEP 8 instead of camelCase.

I don't know if this was the explicit motivation for PEP 8, but it
has always seemed valid to me:

https://en.wikipedia.org/wiki/Camel_case#Readability_studies

[Eli the Bearded]

In comp.lang.python, Paul Rubin <no.e...@nospam.invalid> wrote:
> I don't know if this was the explicit motivation for PEP 8, but it
> has always seemed valid to me:
>
> https://en.wikipedia.org/wiki/Camel_case#Readability_studies

There are three things cited there. One is a NYTimes story from 2009
"Against Camel Case" starting out with criticism of "iPhone" which
the author describes but won't use as it it too difiguring. That's not a
programmer talking about program identifiers.

The other two are more relevant, two studies one from 2009 and one from
2010, each of which seems to reach a conclusion at odds with the other.
The 2009 one finds camelCase easier to read than snake_case, and the
2010 one finds people recognize snake_case identifiers faster than
camelCase ones. I don't think that Wikipedia page helps your case.

I personally abhor the use of inappropriate mid-word caps in English,
which fits the NYT piece, but am only mildly against them in code. I had
some bad expierences with code that forced use of capital letters in
college and that has tainted me against excess capitals ever since. This
is a highly personal reason that I don't expect anyone else to share.

Here's a simple argument against camel case: when it becomes necessary
to join identifiers, camel case requires modification of the original
unit while snake case just adds stuff to beginning and/or end. One
noteworthy example is when a negated version is needed.

camelCase -> noCamelCase
snake_case -> no_snake_case

One of those is easier to "grep" for than the other.

Elijah
------
grep-ability of code should on everyone's mond

[Chris Angelico]

On Tue, May 19, 2020 at 7:11 AM Eli the Bearded <*@eli.users.panix.com> wrote:
> Here's a simple argument against camel case

Here's an even simpler argument.

XMLHttpRequest

ChrisA

[Juergen Brendel]

Hello!

We have now moved into a pros/cons discussion of snake vs camel-case,
which wasn't the original question. But discussions about coding styles
are always fun, so why not... :-)

I agree with Eli's reasoning about the grep-ability. It's something
that people don't often pay attention to, but that is actually really
important.

One more note about the readability:

A good friend of mine is a great developer, but has incredibly poor
eye-sight. For him it's very important that the code has easily
recognizable patterns. Imagine you'd have to try to make sense of code
when you could only squint at the screen and see everything fuzzy and
you get the idea. For what are now immediately obvious reasons he
prefers snake-case.

His concerns about reading code and recognizable patterns have been a
guide in the development of my own coding style for more than 20 years
now and it has served me well.

Juergen

[Dan Sommers]

On Tue, 19 May 2020 09:55:04 +1200
Juergen Brendel <jue...@brendel.com> wrote:

> ... he prefers snake-case.

That's not snake_case. That's kebab-case.¹

¹ https://wiki.c2.com/?KebabCase

[Juergen Brendel]

:-)

[Paul Rubin]

Eli the Bearded <*@eli.users.panix.com> writes:
> One of those is easier to "grep" for than the other.

grep -i might help.

[Eli the Bearded]

In comp.lang.python, Paul Rubin <no.e...@nospam.invalid> wrote:

Or might not, if I want case sensitivity in the rest of my RE.

Elijah
------
can, but doesn't want to, build REs that are flexible about partial sensitivity

[Barry Scott]

> On 18 May 2020, at 22:07, Eli the Bearded <*@eli.users.panix.com> wrote:
>
> camelCase -> noCamelCase
> snake_case -> no_snake_case
>
> One of those is easier to "grep" for than the other.

I guess you mean that a case-sensitive grep can tell
camelCase from noCamelCase.

In all cases you need to use a \b to mark the boundary of the word.
Otherwise the RE will match more than you expect, assuming a
large set of identifiers.

grep '\bsnake_case\b *.py

Barry

[Rhodri James]

On 18/05/2020 22:07, Eli the Bearded wrote:
> camelCase -> noCamelCase
> snake_case -> no_snake_case
>
> One of those is easier to "grep" for than the other.

Eh. A changed case in the one, an extra character in the other; that's
pretty much the same difficulty really. I certainly don't find it
"hard" to grep for _snake_case.

--
Rhodri James *-* Kynesim Ltd

[Richard Damon]

On 5/19/20 4:02 AM, Barry Scott wrote:

>
>> On 18 May 2020, at 22:07, Eli the Bearded <*@eli.users.panix.com> wrote:
>>
>> camelCase -> noCamelCase
>> snake_case -> no_snake_case
>>
>> One of those is easier to "grep" for than the other.

> I guess you mean that a case-sensitive grep can tell
> camelCase from noCamelCase.
>
> In all cases you need to use a \b to mark the boundary of the word.
> Otherwise the RE will match more than you expect, assuming a
> large set of identifiers.
>
> grep '\bsnake_case\b *.py
>
> Barry
>

I think the issue is that you can easy search for all 'snake_case' and
get them, but you have more difficulty searching for all 'camelCase',
needing to go case insensitive, but if leading case matters (like there
is a type CamelCase that you don't want) you get unwanted hits.

--
Richard Damon

[Schachner, Joseph]

I don't actually know, but I can take a guess. CamelCase can be problematic with terms that are abbreviations and always upper case. For example FIRFilter or USBPLL
The first violated camelCase because it has no lower case letters before Filter, and the second completely violates camelCase because both USB and PLL are well known always capitalized abbreviations so that name has no lower case letters.

On the other hand FIR_filter and USB_PLL have no problem showing where the split should be.

And, because '_' looks sort of like a space, the individual words are more easily readable. notEveyoneThinksReadingCamelCaseIsEasy.

-- Joseph S.

[Chris Angelico]

On Wed, May 20, 2020 at 4:03 AM Schachner, Joseph
<Joseph.S...@teledyne.com> wrote:
>
> And, because '_' looks sort of like a space, the individual words are more easily readable. notEveyoneThinksReadingCamelCaseIsEasy.
>

Me: "What does casels mean?"

*beat*

Me: "Well, I guess that's the point then, isn't it."

ChrisA

[Jim]

Couldn't resist: Why not Chris_A :)

Jim

[Chris Angelico]

Heh. Actually a fair question! It's actually been my shorthand name
for many many years, and originally I used the username "chrisa" since
that was the email convention at the company. I later started
uppercasing it to avoid being thought of as a "Christa" or somesuch,
and wanted to remain compatible with the existing address, so case
changes were all I'd do. But if I were to identify myself in a more
Pythonic way, it would be Chris_Angelico.

Backward compatibility trumps PEP 8.

ChrisA

[DL Neil]

On 20/05/20 8:49 AM, Chris Angelico wrote:
> On Wed, May 20, 2020 at 6:38 AM Jim <jf_b...@comcast.net> wrote:
>>
>> On 5/19/20 1:24 PM, Chris Angelico wrote:
>>> On Wed, May 20, 2020 at 4:03 AM Schachner, Joseph
>>> <Joseph.S...@teledyne.com> wrote:
>>>>
>>>> And, because '_' looks sort of like a space, the individual words are more easily readable. notEveyoneThinksReadingCamelCaseIsEasy.
>>>>
>>>
>>> Me: "What does casels mean?"

Chris
Angelico
Shortens
Every
Long-name
Savagely
?
Significantly
?
--
Regards =dn

[Jim]

On 5/19/20 3:49 PM, Chris Angelico wrote:
> On Wed, May 20, 2020 at 6:38 AM Jim <jf_b...@comcast.net> wrote:
>>
>> On 5/19/20 1:24 PM, Chris Angelico wrote:
>>> On Wed, May 20, 2020 at 4:03 AM Schachner, Joseph
>>> <Joseph.S...@teledyne.com> wrote:
>>>>
>>>> And, because '_' looks sort of like a space, the individual words are more easily readable. notEveyoneThinksReadingCamelCaseIsEasy.
>>>>
>>>
>>> Me: "What does casels mean?"
>>>

>>> *beat*
>>>
>>> Me: "Well, I guess that's the point then, isn't it."
>>>
>>> ChrisA
>>>
>>
>> Couldn't resist: Why not Chris_A :)
>
> Heh. Actually a fair question! It's actually been my shorthand name
> for many many years, and originally I used the username "chrisa" since
> that was the email convention at the company. I later started
> uppercasing it to avoid being thought of as a "Christa" or somesuch,
> and wanted to remain compatible with the existing address, so case
> changes were all I'd do. But if I were to identify myself in a more
> Pythonic way, it would be Chris_Angelico.
>
> Backward compatibility trumps PEP 8.
>
> ChrisA
>

Fair point.

Jim

[Peter J. Holzer]

On 2020-05-19 09:53:01 +0100, Rhodri James wrote:

> On 18/05/2020 22:07, Eli the Bearded wrote:
> > camelCase -> noCamelCase
> > snake_case -> no_snake_case
> >
> > One of those is easier to "grep" for than the other.
>

> Eh. A changed case in the one, an extra character in the other; that's
> pretty much the same difficulty really. I certainly don't find it "hard" to
> grep for _snake_case.

I think you misunderstood his argument. He is saying that by searching
for /snake_case/ you will find both "snake_case" and "no_snake_case".
But /camelCase/ won't match "noCamelCase" - you have to search for
/[cC]amelCase/ instead.

I'm not sure if I'm convinced by that. I prefer snake_case simply for
aesthetic reasons. My native language is German, so I should be used to
gratuitous capitalisation from early childhood - but I still find
camelCase ugly.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | h...@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

[Peter J. Holzer]

On 2020-05-19 05:59:30 +1000, Chris Angelico wrote:
> PEP 8 is a style guide for the Python standard library. It is the
> rules you must comply with if you are submitting a patch *to Python
> itself*. Nobody ever requires you to comply with it for any other
> code.

That's obviously not true: Many companies and projects have a coding
standard. Many of those coding standards will be based on or even
identical to PEP 8. And as an employee or contributor you may be
required to comply with it. Now you might argue that in this case you
aren't required to comply with PEP 8, but with the coding standard of
your company, but I would consider that excessive nitpickery.

[Chris Angelico]

On Fri, May 29, 2020 at 6:20 AM Peter J. Holzer <hjp-p...@hjp.at> wrote:
>
> On 2020-05-19 05:59:30 +1000, Chris Angelico wrote:
> > PEP 8 is a style guide for the Python standard library. It is the
> > rules you must comply with if you are submitting a patch *to Python
> > itself*. Nobody ever requires you to comply with it for any other
> > code.
>
> That's obviously not true: Many companies and projects have a coding
> standard. Many of those coding standards will be based on or even
> identical to PEP 8. And as an employee or contributor you may be
> required to comply with it. Now you might argue that in this case you
> aren't required to comply with PEP 8, but with the coding standard of
> your company, but I would consider that excessive nitpickery.
>

The OP said:
> My preference for using camelCase (in PEP 8, AKA mixedCase) is putting me at odds with my colleagues, who point to PEP 8 as "the rules".
>

This smells like the incredibly strong misconception that PEP 8 needs
to govern every line of Python code ever written, or else it's "bad
code". This thread wouldn't have been started if it had been any other
style guide that the company had been chosen, because then it's
obvious that the choice is the company's. It's only when PEP 8 is
considered to be some sort of universal standard that we get this kind
of discussion.

ChrisA

[Roel Schroeven]

Peter J. Holzer schreef op 28/05/2020 om 22:09:

> On 2020-05-19 09:53:01 +0100, Rhodri James wrote:
>> On 18/05/2020 22:07, Eli the Bearded wrote:

>>> camelCase -> noCamelCase
>>> snake_case -> no_snake_case
>>>
>>> One of those is easier to "grep" for than the other.
>>

>> Eh. A changed case in the one, an extra character in the other; that's
>> pretty much the same difficulty really. I certainly don't find it "hard" to
>> grep for _snake_case.
>
> I think you misunderstood his argument. He is saying that by searching
> for /snake_case/ you will find both "snake_case" and "no_snake_case".
> But /camelCase/ won't match "noCamelCase" - you have to search for
> /[cC]amelCase/ instead.
>
> I'm not sure if I'm convinced by that. I prefer snake_case simply for
> aesthetic reasons. My native language is German, so I should be used to
> gratuitous capitalisation from early childhood - but I still find
> camelCase ugly.

For me, the reason for disliking camelCase is consistency. I don't like
how in camelCase words are written differently just because they appear
at the front or not at the front. I don't like that the c of camelCase
changes to the C in noCamelCase; not for the easy of searching (though
that is an argument, just not the one that irks me most) but because
it's not consistent. Things should change when their meaning changes,
not when their place changes.

Both PascalCase and snake_case don't have that inconsistency, which is
why I like them a lot better than camelCase.

There's another reason why I don't like camelCase: it smells like Java,
and I don't like Java. That's an entirely irrational feeling though, of
course.

--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

[Peter J. Holzer]

On 2020-05-29 06:27:31 +1000, Chris Angelico wrote:
> On Fri, May 29, 2020 at 6:20 AM Peter J. Holzer <hjp-p...@hjp.at> wrote:
> > On 2020-05-19 05:59:30 +1000, Chris Angelico wrote:
> > > PEP 8 is a style guide for the Python standard library. It is the
> > > rules you must comply with if you are submitting a patch *to Python
> > > itself*. Nobody ever requires you to comply with it for any other
> > > code.
> >
> > That's obviously not true: Many companies and projects have a coding
> > standard. Many of those coding standards will be based on or even
> > identical to PEP 8. And as an employee or contributor you may be
> > required to comply with it. Now you might argue that in this case you
> > aren't required to comply with PEP 8, but with the coding standard of
> > your company, but I would consider that excessive nitpickery.
> >
>
> The OP said:

> > My preference for using camelCase (in PEP 8, AKA mixedCase) is
> > putting me at odds with my colleagues, who point to PEP 8 as "the
> > rules".
> >
>

> This smells like the incredibly strong misconception that PEP 8 needs
> to govern every line of Python code ever written, or else it's "bad
> code". This thread wouldn't have been started if it had been any other
> style guide that the company had been chosen, because then it's
> obvious that the choice is the company's. It's only when PEP 8 is
> considered to be some sort of universal standard that we get this kind
> of discussion.

It may be the case in this specific instance (although I don't know, as
I don't work for the OP's company and don't know his colleagues). I
don't think it is generally the case.

When a company introduces a coding standard, I think "just use PEP 8" is
a very reasonable choice (it's not inherently better or worse than any
other style, but just by being familiar to a lot of Python programmers
it is likely to elicit less resistance and bike-shedding).

So this might lead to the following exchange during a code review:

A: Please don't use camelCase for variables. It's against our coding
style.

B: Why don't we allow camelCase for variables?

A: Because PEP 8 doesn't allow it.

B: Why doesn't PEP 8 allow it?

A: Uh, ask the PEP 8 authors.

At which point B becomes the OP of this thread.

[Terry Reedy]

On 5/28/2020 4:18 PM, Peter J. Holzer wrote:
> On 2020-05-19 05:59:30 +1000, Chris Angelico wrote:
>> PEP 8 is a style guide for the Python standard library. It is the
>> rules you must comply with if you are submitting a patch *to Python
>> itself*. Nobody ever requires you to comply with it for any other
>> code.
>
> That's obviously not true: Many companies and projects have a coding
> standard. Many of those coding standards will be based on or even
> identical to PEP 8. And as an employee or contributor you may be
> required to comply with it.

Revise Chris' claim to "Neither the PSF nor the Python core developers
require* that owners of non-stdlib code comply with PEP 8" and it would
be true.

* We could have, by baking it into the language, by making uppercase
following lowercase in identifiers illegal. But that would disabled
part of the stdlib.

> Now you might argue that in this case you
> aren't required to comply with PEP 8, but with the coding standard of
> your company, but I would consider that excessive nitpickery.

I don't. If an entity with a police force adopts part of the Model Fire
Code written by an International Association of Fire Marshals (or
whatever), it matters that any enforcement is done by that state's
officials rather toothless disapproval of the association.

In any case, Guido as BDFL did not enforce the function-name rule, as
illustrated by unittest (I would have prefered otherwise). Moveover, he
made it clear in PEP 8 that strict enforcement of its rules was not one
of its rules. Many of the rules explicitly allow for exceptions in
exceptional circumstances. So required no-exception compliance is an
add-on by other entities.

--
Terry Jan Reedy

[Peter J. Holzer]

On 2020-05-29 06:27:31 +1000, Chris Angelico wrote:

> On Fri, May 29, 2020 at 6:20 AM Peter J. Holzer <hjp-p...@hjp.at> wrote:
> > On 2020-05-19 05:59:30 +1000, Chris Angelico wrote:
> > > PEP 8 is a style guide for the Python standard library. It is the
> > > rules you must comply with if you are submitting a patch *to Python
> > > itself*. Nobody ever requires you to comply with it for any other
> > > code.
> >
> > That's obviously not true: Many companies and projects have a coding
> > standard. Many of those coding standards will be based on or even
> > identical to PEP 8. And as an employee or contributor you may be
> > required to comply with it.

[...]

> The OP said:
> > My preference for using camelCase (in PEP 8, AKA mixedCase) is
> > putting me at odds with my colleagues, who point to PEP 8 as "the
> > rules".
> >
>

> This smells like the incredibly strong misconception that PEP 8 needs
> to govern every line of Python code ever written, or else it's "bad
> code". This thread wouldn't have been started if it had been any other
> style guide that the company had been chosen, because then it's
> obvious that the choice is the company's. It's only when PEP 8 is
> considered to be some sort of universal standard that we get this kind
> of discussion.

I got a bit side-tracked in my previous reply, so I'm trying to stick to my
original point more closely this time.

Your claim was that "nobody ever requires you to comply with [PEP 8] for
any other code".

For this claim to be false, only one person/company/project needs to
require somebody to comply with PEP 8. Their motives are completely
irrelevant. They may believe that compliance with PEP 8 is necessary
for any Python code. They may just think that PEP 8 is a good idea. They
may have had a vision of Elvis singing the text of PEP 8 to the tune of
Jailhouse Rock. It doesn't matter. Your claim was about their actions,
not their motives.

The OP seems to feel that he is required by his colleagues to comply
with PEP 8. So his company would serve as a counter-example (though
maybe a weak one, since it doesn't seem to be a hard requirement).

hp

PS: We have "PEP 8, unless you have a good reason to deviate" in our
style guide, but we don't enforce that at all (unfortunately).

[Peter J. Holzer]

On 2020-05-28 18:14:53 -0400, Terry Reedy wrote:

> On 5/28/2020 4:18 PM, Peter J. Holzer wrote:
> > On 2020-05-19 05:59:30 +1000, Chris Angelico wrote:
> > > Nobody ever requires you to comply with it for any other code.
> >
> > That's obviously not true:

[...]

> Revise Chris' claim to "Neither the PSF nor the Python core developers
> require* that owners of non-stdlib code comply with PEP 8" and it would be
> true.

Well, yes. But "Neither the PSF nor the Python core developers" is quite
different from "Nobody ever".

That's like saying "Nobody has ever been on the moon" is true if you
replace "Nobody" with "No catholic bishop".

hp

[Terry Reedy]

On 5/29/2020 4:30 PM, Peter J. Holzer wrote:
> On 2020-05-28 18:14:53 -0400, Terry Reedy wrote:
>> On 5/28/2020 4:18 PM, Peter J. Holzer wrote:
>>> On 2020-05-19 05:59:30 +1000, Chris Angelico wrote:
>>>> Nobody ever requires you to comply with it for any other code.
>>>
>>> That's obviously not true:
> [...]
>> Revise Chris' claim to "Neither the PSF nor the Python core developers
>> require* that owners of non-stdlib code comply with PEP 8" and it would be
>> true.
>
> Well, yes. But "Neither the PSF nor the Python core developers" is quite
> different from "Nobody ever".

Right, I modified a statement that takenly literally is obvious false,
undefensible, and not worth discussing to one that I believe to be true
and that says something important. I would qualify further to people in
their PSF/core-dev roles. There might be core-devs who enforce PEP-8 in
other roles.

> That's like saying "Nobody has ever been on the moon" is true if you
> replace "Nobody" with "No catholic bishop".

Only as the level of an empty generic template. <noun> has ever
<verbed>. Semantically, the two statements are not at all paralley.
The PSF/core-devs own python and PEP-8. Catholic bishops do not own
either the moon or means of walking there. And there would be nothing
wrong if a Catholic bishop were to walk on the moon, and I can imagine
(and hope) that one might someday do so.


--
Terry Jan Reedy

[Dennis Carachiola]

From PEP8--
"The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, "Readability counts".
A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important.
However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!
In particular: do not break backwards compatibility just to comply with this PEP!"