On Wed, Apr 23, 2014 at 11:48 PM, Chris Withers <ch...@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@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com