I use sublime and I found this https://github.com/tanelpuhu/sublime-text-2-packages/tree/master/Python%20PE...
Sublime is so much better than other editors in programming. I really recommend you to test it
Best
On 7/30/13, Antoine Musso hashar+wmf@free.fr wrote:
Le 30/07/13 10:52, Merlijn van Deen a écrit :
On 30 July 2013 00:08, Dr. Trigon <dr.trigon@surfeu.ch mailto:dr.trigon@surfeu.ch> wrote:
I don't think so.
I would be interested to understand how. Because pep8 validation works /on the entire repository/ and not just on /the patchset, /the following is what I'm afraid will happen:
- all code passes pep8 validation
- someone uploads a patchset that adds a mistake: the merged repository
does not pass validation 3) the bot reports the patchset failed validation 4) the change is merged -> the repository no longer passes validation!
And because the repository no longer passes validation, the bot will also report 'failure' on any following patchset!
As such, the repository needs to always pass validation. To make sure the repository always passes validation, no changes should be merged if they fail validation. The easiest way to prevent the changes to be merged is to set the bot to voting.
That is exactly how it "should" work if one want to prevent new style error from entering the repository. Note that I am not enforcing the pywikipediabot developers one way or another :-]
What I would recommend is:
- make the repositories to pass the pep8 / pyflakes tests
- enable blocking
After a few days, you will get a good idea of style errors you do not care about. pep8 style is sometime annoying:
Given the code:
somemodule.longmethod.chaining.there(p='foo', anotherpara=('value which can potentially be super long'))
pep8 yields:
E128 continuation line under-indented for visual indent
One can make it pass with the very ugly:
somemodule.chaining.there(p='foo', anotherpara=('value which can potentially' 'be super long'))
Or putting each parameter on each on line:
somemodule.longmethod.chaining.there( p='foo', anotherpara=('value which can potentially be super long'))
That specific E128 code can be ignored with a .pep8 file containing:
[pep8] # This is a commented out line # E128 continuation line under-indented for visual indent ignore = E128
So once you experimented pep8 annoyance, you can selectively get rid of some checks :-]
Another issue, is people sending their patch without checking the style locally. The best way to handle this is to use a code editor that triggers pep8 on file save and reports back to you straight in the code editor. I am sure IDE dedicated to python already support that.
For vim there is the syntastic plugin: https://github.com/scrooloose/syntastic (screenshot included)
That is a huge time saver.
cheers,
-- Antoine "hashar" Musso
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l