[Python-ideas] lint in stdlib

[CTO]

On May 6, 2:43 pm, Jeremy Hylton <jer... at alum.mit.edu> wrote:
> On Wed, May 6, 2009 at 8:50 AM, Jesse Noller <jnol... at gmail.com> wrote:
> > On Wed, May 6, 2009 at 3:14 AM, Ben Finney <ben+pyt... at benfinney.id.au> wrote:
> >> CTO <debat... 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.

Should we give another look to something like pep8.py, then? Less
complex, certainly, no dependencies and it runs cleanly under python3
after running it through 2to3. On the minus side, it is *much* less
rigorous.

Geremy Condra