I have reformated all files according
to PEP8 - whitespaces, 80 column etc.
Details
py.test --functional
it should run as usual.
Diff Detail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
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
Next time you can use
--update revision_id Always update a specific revision.
Ugh, can we just use two lines here?