[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