[Twisted-Python] twistedchecker - Names of constant which are used as configuration options

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Sun Jan 25 08:21:47 MST 2015


On 02:09 pm, adi at roiban.ro wrote:
>On 25 January 2015 at 01:01,  <exarkun at twistedmatrix.com> wrote:
>>On 24 Jan, 07:51 pm, adi at roiban.ro wrote:
>>>
>>>On 24 January 2015 at 19:23,  <exarkun at twistedmatrix.com> wrote:
>>>>
>>>>On 06:45 pm, adi at roiban.ro wrote:
>>>>>
>>>>>
>>>>>Hi,
>>>>>
>>>>>Why reviewing a patch I got into this error from twistedchecker.
>>>>>This is old code, just that someone it was touched by recent 
>>>>>changes,
>>
>>
>>Also: pre-existing errors like this one should not block new 
>>development
>>work being done.  It is *not* a requirement that a patch fix all 
>>nearby but
>>unrelated problems like this one.
>
>OK. but then maybe twistededchecker and pyflakes should not be part of
>the stable builders.
>In my head, all stable builders should pass before merging new code.
>>New and changed code should conform to the standard and try not to 
>>introduce
>>new errors.  If the "errors" being introduced are due to bugs in a 
>>tool that
>>reports errors, the bugs should be fixed.
>
>New code should only try not to introduce new errors?

The tools are there to help development, not hinder it.  If a tool is 
producing an error that doesn't help development, slavishly adhering to 
a policy that requires additional work that doesn't help the project is 
counter-productive.

If all the tools were perfect we could say that all new code *must* 
never introduce new errors.  Unfortunately the tools are not perfect.
>I was expecting that new code is not allowed to introduce new errors. 
>Period.
>>Existing code *near* new or changed code can and should be left alone.
>
>Does this mean that The (boy) scout rule does not apply for Twisted 
>development?

I'm not familiar with "The (boy) scout rule".

Jean-Paul




More information about the Twisted-Python mailing list