If you're going to continue to maintain this fork you should join the
mailing list so your messages do not need to be moderated.

That said, I have a few points of feedback for you:

Error numbers in tools such as pep8 and pyflakes (although flake8 adds
them to pyflakes) are usually not made to be entirely successive. For
the most part, there are groupings of errors. The best explanation of
this is pep8's documentation:
http://pep8.readthedocs.org/en/latest/intro.html#error-codes

Anything starting with E1 is related to indentation, anything starting
with E2 is related to whitespace. These are conceptually classes of
errors. PyLint also follows this convention if I remember correctly
and you would do well to do the same. The error codes that Flake8 adds
to PyFlakes follow that convention as well.

This probably also means that if you're following semver that this
will be a new major version bump since you're changing how items are
ignored.

On Sun, Jan 19, 2014 at 9:50 AM, timothy crosley
<timothy.crosley@gmail.com> wrote:
> Hi Everyone,
>
> I just wanted to let you know, after Pyflakes seemed dead for about 5 months
> I created a fork called Frosted:
>
> https://github.com/timothycrosley/frosted
>
> While it seems that Pyflakes is somewhat alive again, In the fork a lot of
> code has been simplified and a lot of necessary but missing features (such
> as configuration) have been added. Additionally, I've merged in a lot of
> improvements from the Pyflakes community at large. I will be working hard to
> improve Frosted further, and any suggestions / feature improvements that are
> recommended will be met with enthusiasm :).
>
> While, I would be willing to merge the two projects at some later point, I
> think in the short-term the rapid development and freedom working under a
> new project name will bring - will be very beneficial. I have added Florent
> Xicluna and Steven Myint as collaborators on the project, as these are both
> developers I have high regard for, and remove the possibility of me being
> the single source of failure for unmerged pull-requests.
>
> So if you have time, please check out the project, request features, and
> make pull requests. Lets make a great Python code checker even better!
>
> Thanks!
>
> Timothy
>

> _______________________________________________
> code-quality mailing list
> code-quality@python.org
> https://mail.python.org/mailman/listinfo/code-quality
>