[yt-dev] PEP8

[Matthew Turk]

I am broadly in favor of using PEP-8 standards.  (As long as we're on
the topic, Kacper also had a great suggestion that we run static
analysis like pyflakes.)  Our oldest open ticket, from pre-BB
migration, is about PEP-8.

https://bitbucket.org/yt_analysis/yt/issue/39/follow-pep8-style-conventions

Fixing line length and so on I am fine with being done automatically
with one of those tools.  For changing method names, which I am also
in favor of, we should either identify them and fix them manually or
use a refactoring tool like rope or bicycle repair man.

For all of this I would like to do it in one go, with a single bandaid
to rip off, and beforehand consolidate all extant branches.  RIght now
we have a couple things under active development; we could do this
relatively soon, but I think we need some kind of coordinated effort
to merge relatively quickly back into those branches to make sure we
don't just cause a ton of merge conflicts.  Here's my proposal:

 * Make the change to main branch
 * Merge those into geometry, rockstar, volume rendering
 * Add pyflakes and/or pep8 checks to Jenkins

Thoughts?

-Matt

On Tue, Jan 31, 2012 at 10:56 PM, Casey W. Stark <caseywstark at gmail.com> wrote:
> Hi Stephen.
>
> Not sure about all of the pep8 suggestions, but I think this is important.
> Some are purely style/consistency, like whitespace before ')'. Some would
> hold yt back from Python3 in the future, like .has_key() is deprecated, use
> 'in'.
>
> Do you think it will be enough to autopep and run the full tests? I have no
> idea about coverage, but it would be great to fix some of these.
>
> Best,
> Casey
>
>
> On Tue, Jan 31, 2012 at 7:00 PM, Stephen Skory <s at skory.us> wrote:
>>
>> Hi all,
>>
>> while vegging out in front of the TV, I've been playing with a pep8
>> checker (http://pypi.python.org/pypi/pep8), and I get the statistics
>> below for all the *.py files in yt. How much do we care about this
>> stuff? There are automatic tools
>> (http://pypi.python.org/pypi/autopep8/0.3) but I don't know if we can
>> trust them. Thoughts?
>>
>> (the first column is the number of incidents)
>>
>> 70      E101 indentation contains mixed spaces and tabs
>> 76      E111 indentation is not a multiple of four
>> 605     E201 whitespace after '['
>> 68      E202 whitespace before ')'
>> 94      E203 whitespace before ','
>> 105     E211 whitespace before '['
>> 191     E221 multiple spaces before operator
>> 57      E222 multiple spaces after operator
>> 3769    E225 missing whitespace around operator
>> 4271    E231 missing whitespace after ','
>> 1080    E251 no spaces around keyword / parameter equals
>> 986     E261 at least two spaces before inline comment
>> 6       E262 inline comment should start with '# '
>> 414     E301 expected 1 blank line, found 0
>> 2061    E302 expected 2 blank lines, found 1
>> 369     E303 too many blank lines (2)
>> 168     E401 multiple imports on one line
>> 4644    E501 line too long (80 characters)
>> 1760    E701 multiple statements on one line (colon)
>> 276     E702 multiple statements on one line (semicolon)
>> 70      W191 indentation contains tabs
>> 1585    W291 trailing whitespace
>> 3       W292 no newline at end of file
>> 3163    W293 blank line contains whitespace
>> 221     W391 blank line at end of file
>> 197     W601 .has_key() is deprecated, use 'in'
>> 17      W602 deprecated form of raising exception
>>
>> --
>> Stephen Skory
>> s at skory.us
>> http://stephenskory.com/
>> 510.621.3687 (google voice)
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>