Alex, Yes, it is standard to not place spaces around an equals in that instance. The wiki mentions that to handle all the cases save that edge case. If we end up following PEP-8 the wiki page for documentation standards is going to be drastically simpler. I imagine it'll mostly consist of
"Follow PEP-8 and use Pylint" =) -- Joyce On Fri, Jul 19, 2013 at 9:14 AM, Goodman, Alexander (398J-Affiliate) < [email protected]> wrote: > +1 to removing camelCase. When I first began working on this project, I did > think using the camelCase naming convention for variables and functions was > contrary to what I had typically seen in python code up to that point, so I > think it would be good to be consistent with the rest of the pythonic > community at large. A few of us did spend a significant amount of time > refactoring some of our older code to adhere to the camelCase convention, > but nevertheless it is a fact that a lot of our python code still doesn't > follow the convention properly. > > One other thing: The "operators must be surrounded by single spaces" > convention as stated in our wiki does not explicitly account for the > exceptional case of optional and keyword arguments for functions, where it > is standard to not surround the equals signs by spaces, eg f(arg=None), but > this is explicitly mentioned in the PEP-8 document. As a result some of our > modules (namely plots.py and metrics.py) do not follow this convention > correctly. I think it would be good to mention this on the wiki page. > > Thanks, > Alex > > > On Fri, Jul 19, 2013 at 7:48 AM, Michael Joyce <[email protected]> wrote: > > > Agreed. It seems that now is the perfect time given how much code we're > > moving/changing. So much code is being committed for the "first time" as > we > > refactor. It's simple to lint prior to committing and making our life > > easier later! > > > > Joyce > > > > > > -- Joyce > > > > > > On Fri, Jul 19, 2013 at 7:39 AM, Ramirez, Paul M (398J) < > > [email protected]> wrote: > > > > > +1 to PEP-8 (no camelCase) > > > > > > Either way looks like our compliance to a style is bad overall and > > > something we need to work towards. I'd say just work on as we go though > > > and not let it stand as a blocker to anything. The interesting thing > here > > > is if its merely variable names then any changes would remain backwards > > > compatible as we don't have many classes at this point. > > > > > > --Paul > > > > > > On 7/19/13 7:28 AM, "Michael Joyce" <[email protected]> wrote: > > > > > > >Hi all, > > > > > > > >I would like to discuss our style guides, specifically regarding the > > style > > > >guide for the Python part of OCW. > > > > > > > >Currently our style guide is effectively PEP-8 + camelCase variable > > names > > > >+ > > > >slightly longer line lengths. > > > > > > > >I propose that we switch to plain PEP-8. Our compliance is fairly > > terrible > > > >either way and since we're already going through a large refactoring I > > > >don't see losing those few points of compliance as that big of an > issue. > > > > > > > >Following the Python communities standard makes it easier for > developers > > > >to > > > >jump into the project and it keeps our code in line with the rest of > the > > > >Python that we use. We also don't need a custom pylint config file. > The > > > >linting documentation is now simply "run pylint". > > > > > > > >-- > > > > > > > >I ran pylint over the toolkit with and without our config. > > > > > > > >With (This is our CamelCase version of Pep8) 3.41/10 > > > > > > > >Without (This is PEP8) 2.27/10 > > > > > > > > > > > >Thoughts? > > > > > > > >-- Joyce > > > > > > > > > > > > -- > Alex Goodman >
