pyflakes

pyflakes copied to clipboard

One of my uses cases for pyflakes is integrating into a testing/build system. As a result i found it necessary to have a way of skipping certain things that I'm choosing are "ok" to get to a point where i can enforce a "no warnings before deploy" type of rule.

(the specific warnings that i wanted to skip don't matter so much here, just that i needed that ability; mostly it was things where i had conditional re-imports or purposefully unused imports)

This change allows me to add a comment at the end of any python line which i want pyflakes to ignore.

... # pyflakes.ignore

+1 ! I'm waiting for that too :)

+1 This is important to a lot of people.

+1

+1

+1

+1

I also want to override pyflakes in some cases, but I prefer not to clog my code with comments designed for computers.

So instead of this patch I would prefer some mechanism to customize pyflakes for my whole package. For example:

# pyflakes-custom.py
def pyflakes_filter(complaint):
  if re.search("_.*imported but unused", complaint.msg):
    return None
  return complaint 

+1

Any reason not to merge this ?

+1

@jtriley

The project seems dead (last commit from 10 months ago), and there are many problems with it (e.g. setup.py incompatible with virtualenv). Should we fork it and maintain it ourselves?

@npinto The version on pypi (0.5.0) seems to be hosted by divmod folks (https://launchpad.net/pyflakes) and latest version was released last September. Also, according to https://github.com/kevinw/pyflakes/pull/23#issuecomment-4364365 the divmod pyflakes seems up to date/active. What do you think?

Good point, we should try to move everything to github on pyflakes/pyflakes. Submitted this request on launchpad: https://bugs.launchpad.net/pyflakes/+bug/954470

FYI: Subscribing to that bug increases it's "heat" by 2. The current high is 58.

Hi!

Do any of you know where / how to clone the official pyflakes source? I want to keep a GH clone of whatever is the official source. I believe the official source is in Launchpad but I can't seem to find a clear / easy way to clone whatever is official. In fact, in the official Launchpad source page, I can't find an lp: link but a "Launchpad does not know where Pyflakes hosts its code." message.

Thanks in advanced,

@jjmaestro According to the Pyflakes Launchpad, the source lives at https://launchpad.net/divmod.org/trunk - so I think you can do

bzr branch lp:divmod.org

..maybe? Launchpad is confusing.

Hmmm... @dbr thanks for the hint! will try that and see what happens :D

Nit: I would prefer that whatever mechanism we used to override pyflakes would also be natural for other static analysis tools to support. pyflakes.ignore is nice and concise, but I wonder if we should keep the "pyflakes" out of it.

Just to offer two (admittedly very late) cents: I'm kind of opinionated about using comments to squelch the output from lint tools—I think it sucks.

Comments in general tend to become useless over time. And in terms of general code base pollution, comments telling you (and, oh yeah, the static analysis tool that maybe only you use) that "up ahead lays some evil shit" are even worse.

I deal with a semi-largish project frequently that has both vim mode lines, and emacs folding mode comments—sometimes in the same file!—and the amount of extraneous noise due to just those two things when you're mentally parsing a file for the first time is actually enough to be annoying.

Do I have an alternative? What if we gave PyFlakes the ability to read in a blacklist of modules, or functions, or some combination of both, from some file? Remember how .gitignore works? What if you could do .lintignore in the same way? In any directory, you could put a .lintignore file. That file could look something like

uglymodule.py # ignore an entire module (bad)

uglymodule.py:gnarlyfunction # ignore a function (better)

uglymodule.py:gnarlyfunction(UndefinedExport,LateFutureImport) # ignore two specific messages in one function (bester?)

uglymodule.py:MyClass.my_method # class methods, etc....

There might even be existing syntax out there (or even better, code for parsing/handling) for this sort of "referring to parts of Python code" thing. We could add an option to make it an error for any of those declarations to point to code that doesn't exist anymore, so that if you wanted, you could be forced to keep it up to date.

TLDR

• code is for people to read
• our tools shouldn't force us to make our code less readable
• metadata not intrinsic to code should go outside the code

Thoughts? (I'm going to try to keep this project up to date, now, btw...)

I was actually thinking kinda the same thing, except I don't know how much I would use this with function-level granularity. Usually I just have a few specific lines I want to ignore. For instance, I've written code that tries import simplejson as json and falls back to import json. That complains about redefining json, and I'd like to suppress that. But then if later in the file I had json = '{}', I would want to see a warning about that one. Is that doable?

I was thinking of having some kind of .lintignore file, but maybe having it include a line number, the text of the line, and the warning, and then I guess some kind of fuzz factor on the line number and line text. That would tend to get off over time, especially if you add/delete code in the middle of files, but the only way I see around that is embedding comments in the file itself, which I don't like any more than you do.

My only complaint about comments like # pylint: disable=E201 is that I can never remember what E201 is, nor why whoever wrote it decided to disable the message..

If the lint-disabling message is short enough to fit nicely within a regular comment (by being shorter then pylint: disable=...), and reasonably understandably legible identifiers, it could be much less noisy:

try:
    import simplejson as json
except ImportError:
    # Allow fallback to slower builtin JSON module {IgnoreRedefinition}
    import json

The separate .lintignore could be useful to have, but I don't believe it would work for all cases, so having a sensible way to ignore via comments would still be very much worthwhile.

I do like {IgnoreRedefinition} better than disable=E201. But wouldn't it be better to allow import redefinitions within an ImportError block? That's the idiomatic way to handle different versions of a library anyways.

But wouldn't it be better to allow import redefinitions within an ImportError block? Excellent point. I'd really like that.

But I do think there's merit in being able to to ignore known pyflakes warnings, as there will always be cases where pyflakes isn't smart enough.

I am just wondering if pull request #28 solves the most immediate need for this change? Would be glad if you could check.

saper: yep, I just checked #28 against the code in amoffat/sh and it gets rid of all the redefinition warnings I wanted to see suppressed without breaking any legitimate warnings. I also played with some legitimate cases like

if True:
    import os
if True:
    import os

and it correctly warned, so I think it's as good as it's gonna be without risking being too aggressive in suppressing warnings.

Pull request #28 addresses bug in pyflakes, while ignoring is rather for locally overriding something. For example see http://stackoverflow.com/questions/8427701/import-files-in-init-py - Django test discovery forces you to import everything into one module and you don't want to be warned about this, having dozens of not interesting warnings just masks the interesting ones.