I like this approach.  PEP-8 for the python code for all the reasons stated
previously.

-Cam


On Fri, Jul 19, 2013 at 9:57 AM, Michael Joyce <[email protected]> wrote:

> 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
> >
>

Reply via email to