Re: Conforming to pep8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 08, 2014 at 08:54:29PM -0500, William Giokas wrote:
> So I have been looking into the python code in the git tree recently
> (contrib and core tree) and noticed that almost none of the files fully
> conform to pep8. Now I'm not just saying this because I like the code to
> be clean, readable and easily parsed by humans, but also because this is
> laid out in the coding style document that is distributed with the git
> source::
> 
>     For Python scripts:
> 
>      - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
> 
> It's even the first thing that you see when you go looking for 'python'
> in the coding style document. I just ran every file in the tree that
> either ended in '.py' or had a python #!, and was greeted with a whole
> bunch of output::
[snip]
> Which is a whole bunch of errors and warnings thrown by pep8. Is pep8
> just getting put by the wayside? I would much rather have these scripts
> conform to that and have an actual coding style rather than just be a
> hodge-podge of different styles.

The note about PEP-8 was only added to the CodingStyle document fairly
recently, so it's not that it is "getting put by the wayside" but rather
that no one has tidied up what was there before this decision was made,
which gets caught under the catch all rule at the top of
CodingGuidelines:

 - Fixing style violations while working on a real change as a
   preparatory clean-up step is good, but otherwise avoid useless code
   churn for the sake of conforming to the style.

   "Once it _is_ in the tree, it's not really worth the patch noise to
   go and fix it up."
   Cf. http://article.gmane.org/gmane.linux.kernel/943020


Of course, pushing an "apply PEP-8 to the entire file" patch as the
first part of a series that does something else may be worse than fixing
up the style at a time when the script is not otherwise subject to
change.  I suspect the part of CodingGuidelines I quoted above applies
more to local style issues than "change indentation from tabs to spaces"
across an entire file.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]