why no camelCase in PEP 8?

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

-----Original Message-----
From: Lance E Sloan <sloanlance at gmail.com> 
Sent: Monday, May 18, 2020 3:47 PM
To: python-list at python.org
Subject: why no camelCase in PEP 8?

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?