[openstack-dev] Pep8 versions??

Brian Waldon bcwaldon at gmail.com
Tue Nov 20 21:06:56 UTC 2012


On Nov 20, 2012, at 1:57 AM, Monty Taylor wrote:

> 
> 
> On 11/19/2012 09:15 PM, Brian Waldon wrote:
>> 
>> On Nov 19, 2012, at 4:28 PM, Brian Waldon wrote:
>> 
>>> 
>>> On Nov 19, 2012, at 4:16 PM, Chuck Short wrote:
>>> 
>>>> On 12-11-19 06:40 PM, Joe Gordon wrote:
>>>>> 
>>>>> 
>>>>> On Mon, Nov 19, 2012 at 3:06 PM, Monty Taylor
>>>>> <mordred at inaugust.com <mailto:mordred at inaugust.com>> wrote:
>>>>> 
>>>>> I think these are orthogonal. In general I believe we're in
>>>>> agreement that we should be targetting the same version of
>>>>> pep8, and that we should pin that version early in the cycle.
>>>>> However we install that version of pep8 is a different
>>>>> argument.
>>>>> 
>>>>> 
>>>>> Targeting the same version of pep8 is only part of the problem,
>>>>> we would also need to agree on what rules to ignore. For
>>>>> example:
>>>>> 
>>>>> glance (pep8 1.3.3) ignores: E125,E126,E711,E712 nova (pep8
>>>>> 1.2) ignores: E12,E711,E721 keystone (pep8 1.3.3) ignores: ---
>>>> 
>>>> Is there a reason why these were ignored?
>>> 
>>> I just ran glance's pep8 check without ignoring any errors, and it
>>> appears most of them are just arbitrary spacing. I'll attempt to
>>> minimize the number of pep8 violations we ignore.
>> 
>> After walking through the type of errors we're ignoring, I'm not
>> actually comfortable removing any of the PEP8 violations (E125, E126,
>> E711, E712) from Glance's ignore list. The first two are quite
>> fragile and enforce a somewhat awkward coding style, while the second
>> two are asking us to write code that is incompatible with sqlalchemy.
>> Hopefully the maintainers will help improve this situation.
> 
> What about downgrading our pep8 level to 1.2? It doesn't sound like people are really thrilled in general with 1.3…

That's definitely an option, but I'd be interested to see if there are any helpful rules we're losing in that case. I'm fine with ignoring dumb rules.

I think what's most important to get out of this discussion is that we need to decide as a community what we want to stabilize on, with the understanding that there may be some wiggle room within each project with respect to ignores.




More information about the OpenStack-dev mailing list