I'm in favor of this, too. There's a good amount of code written by myself that does not comply but has not gotten changed because I didn't want to break old scripts. I wouldn't mind fixing it all as a part of one big effort.<br>
<br><div class="gmail_quote">On Wed, Feb 1, 2012 at 7:42 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am broadly in favor of using PEP-8 standards. (As long as we're on<br>
the topic, Kacper also had a great suggestion that we run static<br>
analysis like pyflakes.) Our oldest open ticket, from pre-BB<br>
migration, is about PEP-8.<br>
<br>
<a href="https://bitbucket.org/yt_analysis/yt/issue/39/follow-pep8-style-conventions" target="_blank">https://bitbucket.org/yt_analysis/yt/issue/39/follow-pep8-style-conventions</a><br>
<br>
Fixing line length and so on I am fine with being done automatically<br>
with one of those tools. For changing method names, which I am also<br>
in favor of, we should either identify them and fix them manually or<br>
use a refactoring tool like rope or bicycle repair man.<br>
<br>
For all of this I would like to do it in one go, with a single bandaid<br>
to rip off, and beforehand consolidate all extant branches. RIght now<br>
we have a couple things under active development; we could do this<br>
relatively soon, but I think we need some kind of coordinated effort<br>
to merge relatively quickly back into those branches to make sure we<br>
don't just cause a ton of merge conflicts. Here's my proposal:<br>
<br>
* Make the change to main branch<br>
* Merge those into geometry, rockstar, volume rendering<br>
* Add pyflakes and/or pep8 checks to Jenkins<br>
<br>
Thoughts?<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Jan 31, 2012 at 10:56 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>> wrote:<br>
> Hi Stephen.<br>
><br>
> Not sure about all of the pep8 suggestions, but I think this is important.<br>
> Some are purely style/consistency, like whitespace before ')'. Some would<br>
> hold yt back from Python3 in the future, like .has_key() is deprecated, use<br>
> 'in'.<br>
><br>
> Do you think it will be enough to autopep and run the full tests? I have no<br>
> idea about coverage, but it would be great to fix some of these.<br>
><br>
> Best,<br>
> Casey<br>
><br>
><br>
> On Tue, Jan 31, 2012 at 7:00 PM, Stephen Skory <<a href="mailto:s@skory.us">s@skory.us</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> while vegging out in front of the TV, I've been playing with a pep8<br>
>> checker (<a href="http://pypi.python.org/pypi/pep8" target="_blank">http://pypi.python.org/pypi/pep8</a>), and I get the statistics<br>
>> below for all the *.py files in yt. How much do we care about this<br>
>> stuff? There are automatic tools<br>
>> (<a href="http://pypi.python.org/pypi/autopep8/0.3" target="_blank">http://pypi.python.org/pypi/autopep8/0.3</a>) but I don't know if we can<br>
>> trust them. Thoughts?<br>
>><br>
>> (the first column is the number of incidents)<br>
>><br>
>> 70 E101 indentation contains mixed spaces and tabs<br>
>> 76 E111 indentation is not a multiple of four<br>
>> 605 E201 whitespace after '['<br>
>> 68 E202 whitespace before ')'<br>
>> 94 E203 whitespace before ','<br>
>> 105 E211 whitespace before '['<br>
>> 191 E221 multiple spaces before operator<br>
>> 57 E222 multiple spaces after operator<br>
>> 3769 E225 missing whitespace around operator<br>
>> 4271 E231 missing whitespace after ','<br>
>> 1080 E251 no spaces around keyword / parameter equals<br>
>> 986 E261 at least two spaces before inline comment<br>
>> 6 E262 inline comment should start with '# '<br>
>> 414 E301 expected 1 blank line, found 0<br>
>> 2061 E302 expected 2 blank lines, found 1<br>
>> 369 E303 too many blank lines (2)<br>
>> 168 E401 multiple imports on one line<br>
>> 4644 E501 line too long (80 characters)<br>
>> 1760 E701 multiple statements on one line (colon)<br>
>> 276 E702 multiple statements on one line (semicolon)<br>
>> 70 W191 indentation contains tabs<br>
>> 1585 W291 trailing whitespace<br>
>> 3 W292 no newline at end of file<br>
>> 3163 W293 blank line contains whitespace<br>
>> 221 W391 blank line at end of file<br>
>> 197 W601 .has_key() is deprecated, use 'in'<br>
>> 17 W602 deprecated form of raising exception<br>
>><br>
>> --<br>
>> Stephen Skory<br>
>> <a href="mailto:s@skory.us">s@skory.us</a><br>
>> <a href="http://stephenskory.com/" target="_blank">http://stephenskory.com/</a><br>
>> <a href="tel:510.621.3687" value="+15106213687">510.621.3687</a> (google voice)<br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br>