Adherence to PEP 8 for published code (was: ANN: pry unit testing framework)

Aldo Cortesi aldo at nullcube.com
Mon Apr 7 09:51:42 CEST 2008


Thus spake Ben Finney (bignose+hates-spam at benfinney.id.au):

> PEP 8 only has the force that people grant it. Nevertheless, it's a
> style guide that's widely accepted in the Python community, and
> adhering to it in one's code makes it easier to read for the majority,
> because it reduces the needless inconsistencies between different
> bodies of code.
> 
> Conversely, deliberately diverging from the widely-accepted style
> guide increases the cognitive load on the reader; if that divergence
> is not done for a very good reason, one is imposing needless burden on
> every reader of the code.

This is getting silly. Let's recap. You are upset because I prefer this
widely-used method naming convention:
    
    object.myName()

... to this one, which was recently adopted as a recommendation in PEP
008 for modules in the standard library:

    object.my_name()

By doing so, you say, I am "imposing needless burden on every reader"
of my code... Well, lets look at the facts:

First, PEP 8 recommends a naming scheme only for the standard library,
and it is not follwed consistently even there. 

Second, mixedCase is very common both inside and outside the Python
project. No-one who codes regularly in Python can be unfamiliar with
it, even if they never stray beyond the standard library. 

Third, this is a minor, recently-introduced convention. Anyone would 
dislike code that chose not to name classes with an initial capital, or
used something other than "self" as the first method parameter. Method
naming conventions are far, far fuzzier.  The primary issue is simply
to clearly distinguish between words in multi-word names - mymethodname
would be bad, MYMETHODNAME would be even worse, but my_method_name and
myMethodName are both perfectly legible.


You are mis-interpreting the intent behind PEP-8 if you think its
authors intended to provoke shrill public condemnation of any module
that dares to use a long-standing, widely-used alternative method
naming scheme. In fact, PEP 8 contains an entire section warning
against exactly this kind of inflexible and small-minded application of
its recommendations - perhaps you should read it sometime.


> > You're also vastly overstating the impact of a minor naming
> > convention choice. Calling this a "large black mark" smacks of
> > scare-mongering to me.
> 
> When distributing code with the expectation that others use it, it's a
> large black mark if it deliberately shun the widely-accepted,
> easily-followed coding standards, for the above reasons.
> 
> I don't see why that would be scary. If you find it so, you have my
> sympathy.

You re-enforce the point you're trying to counter beautifully. Thanks
for driving my argument home.






Regards,


Aldo



-- 
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com



More information about the Python-list mailing list