[Python-Dev] pep8 reasoning

Guido van Rossum guido at python.org
Thu Apr 24 18:05:40 CEST 2014


On Wed, Apr 23, 2014 at 11:48 PM, Chris Withers <chris at withers.org> wrote:

> Apologies if this is considered off topic, but I'm keen to get the
> "language designers" point of view and short of emailing Barry, Guido and
> Nick directly, this seemed like the best place.
>
> I'm having a tough time persuading some people of the benefits of pep8,
> particularly when it comes to applying to an existing large code base.
>

I guess you're not in a position of power or authority there? :-)


> The biggest sticking point is naming, particularly as it's the one thing
> that can't necessarily be changed module by module. What were the
> compelling reasons to go from mixedCase to underscore_separated? What's
> considered the best approach for migrating from the former to the latter?
>

Changing method names is always very painful. E.g. it took us forever to
make threading.py compliant with the PEP. What we did there is to keep all
the old method names (as aliases). E.g. search threading.py for notify_all
and notifyAll. Then compare how this is done in Python 2.7 vs. 3.4.
Eventually the old names will be summarily removed.

Why we did this? Before I wrote PEP 8 people were using different
conventions and I (perhaps foolishly) didn't want to declare half of the
modules out of style, so the original PEP 8 (and my style guide that
predated it) allowed either. But eventually we got agreement on what style
we preferred, so we took out the "you can name modules and methods either
way."


> A couple of others that have raised some consternation; what are the
> technical reasons for this pattern being bad:
>
> if len(seq)
> if not len(seq)
>
> Some user-defined data types have an expensive __len__() (e.g. when you
have to count the items one by one) while __bool__() can be more efficient.


> ...or, for me, the rather ugly:
>
> if 0 != len(seq)
>

I know several engineering teams whose style prefers this, but personally I
hate it with a vengeance -- it always makes me jump when trying to
understand code written like that. In math on a blackboard you would never
write this (unless as the result of a simplification of a more complex
equation). Also, try to read it out loud -- it sounds awful. (The reason
people write this doesn't really apply in Python anyway -- it comes from a
desire to avoid the bug in C where you write

if (x = 42) { ... }

instead of

if (x == 42) { ... }

But the Python equivalent of the former is invalid syntactically in Python
anyway.


> Likewise, these:
>
> if greeting == True:
> if greeting is True:
>

Both these consider as falsey many values that are actually considered
truthy by convention (e.g. non-zero numbers, non-empty
sequences/containers).


> Please don't misunderstand me: I dislike the above intensely, but it's an
> emotional response based on 10-15 years of doing things the other way. I'm
> interested in arguments that don't include things like "it's pythonic"
> (which some people consider a derogatory term ;-)), or "just because", I
> trust that the stuff in pep8 was done with specific reasoning in mind, but
> I'm feeling rather useless at giving that reasoning and I'm hoping you can
> help :-)
>
> cheers,
>
> Chris
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140424/5990aa4d/attachment-0001.html>


More information about the Python-Dev mailing list