Reformat all files to conform with PEP8
ClosedPublic

Authored by garretraziel on Mar 14 2014, 12:29 PM.

Details

Summary

I have reformated all files according
to PEP8 - whitespaces, 80 column etc.

Test Plan

py.test --functional
it should run as usual.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
kparal requested changes to this revision.Mar 14 2014, 3:58 PM

Thanks for your work. I assume you used some kind of automatic reformatter to do this. Can it be modified so that it doesn't replace ' with " (' is easier to type, no reason to force " everywhere) and more importantly so that it doesn't remove blank lines? For example I consider having two empty lines between method definitions to be much more readable. The main request in T96 was really just to wrap the long lines. Some other pylint-related fixes might also be nice, but I didn't want to imply that we need to convert our whole source code to PEP8-compliant code :-)

libtaskotron/directives/koji_directive.py
72–74

Ugh, can we just use two lines here?

libtaskotron/logger.py
65–68

Let's use just two lines here.

73–75

Let's use just two lines here.

libtaskotron/python_utils.py
16–17

Let's use just two lines here.

libtaskotron/runner.py
135–139

Doesn't this add a lots of whitespace to the help message? I assume we don't want that.

libtaskotron/tap.py
26 ↗(On Diff #73)

I'm not sure if you don't break pylint directives here.

Let's not modify this file at all, we plan to get rid of it in T101 anyway.

libtaskotron/yamlish.py
119 ↗(On Diff #73)

Let's not modify this file at all, we plan to get rid of it in T101 anyway.

testing/test_check.py
151–155 ↗(On Diff #73)

There are the cases where I think that some PEP8 guidelines don't make much sense ;) Unless you want to have as many source code lines as possible, of course. The original code was fine.

testing/test_koji_directive.py
29–31

Personally, I would use

self.ref_url = ('http://downloads.example.com/builds/%s.noarch.rpm' % 
                self.ref_nvr)

The URL seems to be more readable this way.

testing/test_koji_utils.py
15–29

Ditto.

testing/test_runner.py
295–297

This is actually longer than 80 chars.

Yep, my IDE does wrapping to 80. column and PEP8 reformatting automatically (it also does static analysis of code, it can check data types, so it is kinda neat). It is fully configurable, so I can disable removing/adding whitespaces (but single newline between methods and two whitespaces between class definitions is required by PEP8). Also, PEP8 says that all triplequoted docstrings should use " instead of '.

If we don't want to stick to PEP8, I can remove all PEP8 reformatting and only wrap long lines.

If we don't want to stick to PEP8, I can remove all PEP8 reformatting and only wrap long lines.

Yes, please. Thanks.

Thanks for your work. I assume you used some kind of automatic reformatter to do this. Can it be modified so that it doesn't replace ' with " (' is easier to type, no reason to force " everywhere) and more importantly so that it doesn't remove blank lines? For example I consider having two empty lines between method definitions to be much more readable. The main request in T96 was really just to wrap the long lines. Some other pylint-related fixes might also be nice, but I didn't want to imply that we need to convert our whole source code to PEP8-compliant code :-)

So what parts of PEP8 do we want to follow? Do we want to set some code style guidelines if we're not completely following PEP8? I'd like to be at least reasonably consistent on this.

So what parts of PEP8 do we want to follow? Do we want to set some code style guidelines if we're not completely following PEP8? I'd like to be at least reasonably consistent on this.

At this moment, I'd like to make 80 characters our preferred line length (in the past I liked longer lines, but hey, my 12'' screen helped me to change my mind!:-)). I'd leave the rest of code styling up to the consideration of the particular author. Of course we can evolve in time, if we find something we believe we should have a guideline for, we can always add it.

@garretraziel: In your patch with pylint fixes (probably next review?) please also include this change (kudos to @pschindl for finding basestring):

diff --git a/libtaskotron/python_utils.py b/libtaskotron/python_utils.py
index 48cc691..c61c1b1 100644
--- a/libtaskotron/python_utils.py
+++ b/libtaskotron/python_utils.py
@@ -14,4 +14,4 @@ def listlike(obj):
     a list/set/etc of strings.
     '''
     return isinstance(obj, collections.Iterable) and not isinstance(obj,
-                                                         (str, unicode))
+                                                                    basestring)

Thanks.

> So what parts of PEP8 do we want to follow? Do we want to set some code style guidelines if we're not completely following PEP8? I'd like to be at least reasonably consistent on this.

At this moment, I'd like to make 80 characters our preferred line length (in the past I liked longer lines, but hey, my 12'' screen helped me to change my mind!:-)). I'd leave the rest of code styling up to the consideration of the particular author. Of course we can evolve in time, if we find something we believe we should have a guideline for, we can always add it.

I'm not looking to argue about specific guidelines here but I definitely don't agree with the idea of leaving style up to individual people. That's a great way to have a messy code base and make it harder for folks to figure out what their code is supposed to look like.

I can't think of a good reason to not stick with mostly PEP8 - it's a common standard for Python code. I'm not suggesting that we start enforcing any new guidelines right now but this is probably a good conversation for the list.

So let's have this patch just wrap the long lines (we can probably agree on that) and discuss the other guidelines on the list.

So let's have this patch just wrap the long lines (we can probably agree on that) and discuss the other guidelines on the list.

Sounds like a plan.

I don't know why, but arcanist created new revision for my changes - it is D27.

I don't know why, but arcanist created new revision for my changes - it is D27

Next time you can use

--update revision_id
    Always update a specific revision.
garretraziel updated this revision.Mar 25 2014, 12:13 PM
  • reformated all lines to 80 column
garretraziel updated this revision.Mar 25 2014, 12:48 PM
  • remaining pyflakes/pylint changes
garretraziel updated this revision.Mar 25 2014, 1:35 PM
  • another set of changes
kparal accepted this revision.Mar 25 2014, 1:35 PM
garretraziel closed this revision.Mar 25 2014, 2:09 PM

Closed by commit rLTRNd8e3675cefdc (authored by Garret Raziel <boloomka@gmail.com>).