PEP 8 and function names

Hi all, "There should be one-- and preferably only one --obvious way to do it." We all love this mantra. But one thing that often confuses people : function naming. The standard library is kind of inconsistent. Some functions are separated by underscores and others aren't. It's not intuitive and new pythonistas end up constantly reading the doc. (Time saving one char typing vs time guessing function names.) Would it be a good idea to clarify PEP 8 on this ? I mean for future libraries. Regards, Sébastien

PEP8 consistency is a question to the development team commitment. Nothing prevents you add pep8 checks to build process, contribute fixes. This inconsistency has been analyzed for various web frameworks recently: http://mindref.blogspot.com/2012/10/python-web-pep8-consistency.html No much in the list are paying attention to this... Andriy ________________________________
Date: Sun, 26 May 2013 11:48:50 +0200 From: se8.and@gmail.com To: python-dev@python.org Subject: [Python-Dev] PEP 8 and function names
Hi all,
"There should be one-- and preferably only one --obvious way to do it."
We all love this mantra.
But one thing that often confuses people : function naming. The standard library is kind of inconsistent. Some functions are separated by underscores and others aren't. It's not intuitive and new pythonistas end up constantly reading the doc. (Time saving one char typing vs time guessing function names.)
Would it be a good idea to clarify PEP 8 on this ? I mean for future libraries.
Regards,
Sébastien

On Sun, May 26, 2013 at 7:48 PM, Sébastien Durand <se8.and@gmail.com> wrote:
Hi all,
"There should be one-- and preferably only one --obvious way to do it."
We all love this mantra.
But one thing that often confuses people : function naming. The standard library is kind of inconsistent. Some functions are separated by underscores and others aren't. It's not intuitive and new pythonistas end up constantly reading the doc. (Time saving one char typing vs time guessing function names.)
Would it be a good idea to clarify PEP 8 on this ? I mean for future libraries.
As far as I am aware, there's nothing to clarify: new code should use underscores as word separators, code added to an existing module or based on existing API should follow the conventions of that module or API. This is what PEP 8 already says. The standard library is inconsistent because it's a 20 year old code base with severe backwards compatibility constraints, and much of it was written before there was even a PEP process, let alone PEP 8. We did do one wholesale conversion to PEP 8 compliance (for the threading module) and decided the cost/benefit ratio was too low to justify ever doing that again. We do have a general guideline requiring PEP 8 compliance for *new* modules added to the standard library. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 26/05/2013 14:02, Stephen J. Turnbull wrote:
Nick Coghlan writes:
threading module) and decided the cost/benefit ratio was too low to justify ever doing that again.
I think you just failed Econ 101, Nick.<wink/>
I-teach-that-s**t-for-a-living-ly y'rs,
P.S. Of course we all understood what you meant. :-)
Yet another reference to Orwell's worst room in the world, what does this imply about Python? :) -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence

On May 26, 2013, at 08:34 PM, Nick Coghlan wrote:
As far as I am aware, there's nothing to clarify: new code should use underscores as word separators, code added to an existing module or based on existing API should follow the conventions of that module or API. This is what PEP 8 already says.
Exactly so. -Barry

But one thing that often confuses people : function naming. The standard library is kind of inconsistent. Some functions are separated by underscores and others aren't.
I think there are a number of reasons for this: * Despite PEP 8's age, significant chunks of the standard library predate it * Modules which are thin wrappers around various C libraries tend to mimic those libraries' names * Modules which were heavily influenced by similar libraries from other languages often carry over spelling * PEP 8 hasn't always been a checklist item for inclusion (not sure it even is today) * Sometimes Cerberus was sleeping, and they snuck past him In any case, once a module makes it into the standard library, the cost of changing spelling outweighs the benefits of slavish adherence to PEP 8. Skip
participants (7)
-
Andriy Kornatskyy
-
Barry Warsaw
-
Mark Lawrence
-
Nick Coghlan
-
Skip Montanaro
-
Stephen J. Turnbull
-
Sébastien Durand