[Python-ideas] lint in stdlib

Jeremy Hylton jeremy at alum.mit.edu
Wed May 6 20:43:14 CEST 2009


On Wed, May 6, 2009 at 8:50 AM, Jesse Noller <jnoller at gmail.com> wrote:
> On Wed, May 6, 2009 at 3:14 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
>> CTO <debatem1 at gmail.com> writes:
>>
>>> Skipping over some of the wrangling about where it goes for a minute,
>>> is there any firm consensus on which tool to put in? I've only heard
>>> back from pylint, and there seems to be a general feeling that that's
>>> the strictest (and therefore best), but that its external dependencies
>>> constitute a liability. Does anybody have a firm objection on that
>>> score?
>>
>> Not a firm objection: pylint is also the most complex (AFAICT). Perhaps
>> a simpler one that still does a good job would be best for stdlib
>> consideration.
>
> +1, something which does simple linting, and pep 8 checking would be a
> big enough benefit over what we have now. Ideally, it would support
> extensibility for additional rules.

I don't see much value in building a new lint tool.  I might like it
if pylint were less complex than it is, but I don't understand the
design fully enough to have justification for that.  If we can get a
good PEP 8 checker out of pylint, it would be silly to write something
from scratch.  We went through a similar exercise at work two summers
ago and concluded that we'd it would be faster to build on pylint than
to write something from scratch.  I don't think there are any special
considerations for python stdlib development that would lead me to
reach a different conclusion.  Certainly, it would be convenient if
the lint tool was part of the source tree, but our editors, compilers,
debuggers, and source control tools aren't part of the source tree
either.  I don't think the desire to put it in tools or stdlib
outweighs the cost of building and maintaining a new tool when a
perfectly good one already exists.

Jeremy



More information about the Python-ideas mailing list