Original report by w-thomas-q on Launchpad:

Hi,

thanks for this really great tool! One issues I stumbled upon was that type hints seem to be ignored / not detected. For example, we have an import at the top of a file:

from typing import List

And then later in an __init__ function something like this:

self.scripts = []  # type: List[script.Script]

Now running pyflakes (through flake8) gives me this error:

foo.py:4:1: F401 'List' imported but unused

PEP484 defines this kind of type comments. Is there an option to enable type hint detection? Or can we have that as feature request? I guess I'm fine with type comments only for the time being, but of course a fully PEP484 compliant solution would be greatly appreciated :)

Thanks!

Original report by archardlias on Launchpad:

Would it be possible to ignore variables named "_" from "Unused Variable" checks?

I'm not really sure whether "_" is officially specified anywhere. But I do see it a lot and in a lot of languages including python to denote a variable to be ignored (place holder dummy). PyLint implements this pseudo(?)-convention (? second-hand knowledge).

Would be great, since I would love to be explicit about "things returned but not used" instead of just calling without assignment which looks tantamount to "this function does never return anything / does not contain a return statement". A great plus in signature visibility throughout the code, specially for first-time readers.

Best regards, ~arlias

Point people to GitHub, not Launchpad. All that's left on Launchpad are a bunch of stale bugs.

Update the author field to reflect the large number of contributors. Remove the maintainer field because a bug in something (setuptools?) overwrites the author field with the maintainer field when the package gets uploaded to PyPI.

The following code is invalid on Python 3:

try:
    raise ValueError('ve')
except ValueError as exc:
    pass

print("Last exception:", exc)    # raises an UnboundLocalError

This pull request makes the Checker warn against this problem. There are new tests that pass on both Python 2 and Python 3.

With this code:

for i in seq_a:
    for j in seq_b:
        print(i, j)

Running flake8 gives me this exception:

CRITICAL:flake8.checker:Plugin F raised an unexpected exception
Traceback (most recent call last):
  File "/home/ubuntu/.local/lib/python3.6/site-packages/flake8/checker.py", line 435, in run_check
    return plugin["plugin"](**arguments)
  File "/home/ubuntu/.local/lib/python3.6/site-packages/flake8/plugins/pyflakes.py", line 94, in __init__
    file_tokens=file_tokens,
  File "/home/ubuntu/.local/lib/python3.6/site-packages/pyflakes/checker.py", line 672, in __init__
    self.handleChildren(tree)
  File "/home/ubuntu/.local/lib/python3.6/site-packages/pyflakes/checker.py", line 1073, in handleChildren
    self.handleNode(node, tree)
  File "/home/ubuntu/.local/lib/python3.6/site-packages/pyflakes/checker.py", line 1120, in handleNode
    handler(node)
  File "/home/ubuntu/.local/lib/python3.6/site-packages/pyflakes/checker.py", line 1073, in handleChildren
    self.handleNode(node, tree)
  File "/home/ubuntu/.local/lib/python3.6/site-packages/pyflakes/checker.py", line 1120, in handleNode
    handler(node)
  File "/home/ubuntu/.local/lib/python3.6/site-packages/pyflakes/checker.py", line 1541, in TUPLE
    if not PY2 and isinstance(node.ctx, ast.Store):
AttributeError: 'Tuple' object has no attribute 'ctx'
"pyflakes" failed during execution due to "'Tuple' object has no attribute 'ctx'"
Run flake8 with greater verbosity to see more details

:wave: I'd like to organize the next release of pyflakes

I'll be pinning this issue and collecting feedback on things that should end up in this release

Due to the number of contributions that have gone into pyflakes since the last release, I'm planning to do this as 2.2.0a1 first (an alpha pre-release) -- this should hopefully expand the number of people trying the release (though I suspect not all that many will use the alpha still)

How you can help:

• try out the latest master on your repositories: pip install --force-reinstall git+https://github.com/pycqa/pyflakes
• review open PRs

Adding a simple reporter class to log to a list of dictionaries with a consistent format across all message types and sources:

• message_class: analogous to E/W/L, e.g., "error"
• message_type: more specific type or description, e.g., "syntax_error"
• filename: file name if provided, else None
• lineno: line number if provided, else None
• message: "message" from the perspective of the sender
• source: source code if provided, else None

Sample output:

>>> reporter = pyflakes.reporter.ListReporter()
>>> pyflakes.api.check(source_bytes, file_name, reporter)
>>> print(reporter.entries)
[{'message_class': 'warning',
  'message_type': 'flake_warning',
  'filename': '0-core-client-1.1.0a8/zeroos/core0/client/__init__.py',
  'lineno': 1,
  'offset': 0,
  'message': "'.client.Client' imported but unused",
  'source': None},
 {'message_class': 'warning',
  'message_type': 'flake_warning',
  'filename': '0-core-client-1.1.0a8/zeroos/core0/client/__init__.py',
  'lineno': 1,
  'offset': 0,
  'message': "'.client.ResultError' imported but unused",
  'source': None},
 {'message_class': 'warning',
  'message_type': 'flake_warning',
  'filename': '0-core-client-1.1.0a8/zeroos/core0/client/__init__.py',
  'lineno': 1,
  'offset': 0,
  'message': "'.client.JobNotFoundError' imported but unused",
  'source': None},
 {'message_class': 'warning',
  'message_type': 'flake_warning',
  'filename': '0-core-client-1.1.0a8/zeroos/core0/client/client.py',
  'lineno': 742,
  'offset': 8,
  'message': "'raise NotImplemented' should be 'raise NotImplementedError'",
  'source': None}]

This is the successor to https://github.com/pyflakes/pyflakes/pull/8.

So far, I have only extended https://github.com/pyflakes/pyflakes/pull/13 to check for return at a module scope.

I have worked on checking for break and continue outside of loops, but it's tricky to get all the corner cases right. I'll need to double check what Python does with every type of ast node to make sure I don't miss anything. For instance, a naive "bubble up until we see a loop" is wrong, because the following are all syntax errors

while True:
    def f():
        continue

while True:
    pass
else:
    continue

while True:
    try:
        pass
    finally:
        continue

The compile.c code in CPython uses some different kind of ast object that already knows what kinds of valid blocks a node is in, so doesn't seem to be directly helpful in this case.

I do plan to push more changes up here, though, including this one when I finish it. Feel free to merge early, however, if the work so far is fine (I may get stalled on this, so don't feel that you need to hold off until everything is finished).

Original report by ma-latorre-diaz on Launchpad:

This simple code make pyflakes throw and exception (python 2.7.11 and 3.5.1).

# -*- coding: utf-8 -*-

from . import foo

class MyClass(object):
    pass

Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "pyflakes/__main__.py", line 5, in <module>
    main(prog='pyflakes')
  File "/home/mal/develop/python/pyflakes/pyflakes/api.py", line 184, in main
    warnings = checkRecursive(args, reporter)
  File "/home/mal/develop/python/pyflakes/pyflakes/api.py", line 141, in checkRecursive
    warnings += checkPath(sourcePath, reporter)
  File "/home/mal/develop/python/pyflakes/pyflakes/api.py", line 108, in checkPath
    return check(codestr, filename, reporter)
  File "/home/mal/develop/python/pyflakes/pyflakes/api.py", line 69, in check
    w = checker.Checker(tree, filename)
  File "/home/mal/develop/python/pyflakes/pyflakes/checker.py", line 403, in __init__
    self.handleChildren(tree)
  File "/home/mal/develop/python/pyflakes/pyflakes/checker.py", line 725, in handleChildren
    self.handleNode(node, tree)
  File "/home/mal/develop/python/pyflakes/pyflakes/checker.py", line 772, in handleNode
    handler(node)
  File "/home/mal/develop/python/pyflakes/pyflakes/checker.py", line 1151, in IMPORTFROM
    node.module, alias.name)
  File "/home/mal/develop/python/pyflakes/pyflakes/checker.py", line 199, in __init__
    full_name = module + '.' + self.real_name
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

This includes return and yield outside of a function and break and continue outside of a loop. Fixes lp 1293654.

The problem is that these SyntaxErrors are not encoded in the ast grammar, so they are not detected when just compiling to ast. You must compile down to bytecode to catch them. The advantage here is that we can still check for other kinds of errors in this case, because the ast is still valid.

Is it possible for flake8 F401 to ignore this kind of re-exports? https://github.com/typeddjango/django-stubs/blob/master/django-stubs/db/models/init.pyi

mypy uses those to be able to discern between imports which could, and which could not be imported from the file.

I'm creating this mostly as a duplicate target

pyflakes currently does not do any branch analysis and as such can't really know when things are conditionally defined / undefined / dead code / etc.

doing accurate branch analysis is a hard problem and often requires some amount of dynamic analysis so it is unlikely pyflakes will ever actually implement this

there are better alternatives which attempt to do this such as type checkers (mypy, pyright) and to some extent pylint

I was pointed to this buggy line:

  if x is None != y is None:

(For context, Python allows chaining any of the comparison operators ==, !=, is, is not, >, >=, <, <=, in, not in. a OP b OP c is equivalent to a OP b and b OP c except that b is only evaluated once.)

I find it hard to imagine a use case for combining is and != in the same chained comparison, so it would be useful for linters to warn about this and similar patterns.

In my company's internal linter, I implemented a check that disallows all chained comparison pairs except == + ==, is + is, </<= + </<=, and >/>= + >/>=.

It found one false positive where someone had intentionally written == + !=, but I'd argue it's clearer with and:

-                        value.fullName == existing.fullName != "*"
+                        (value.fullName == existing.fullName and value.fullName != "*")

Would pyflakes be interested in a similar check?

Closes #454.

• [x] Added offset when handling positions in docstrings (same as for the start coordinates)
• [x] Added test for the offset handling, conditional on Python >= 3.8\
• [x] Checked that tests pass locally and no flake8 warnings are introduced

pyflakes does some format specifier checks (https://github.com/PyCQA/pyflakes/pull/443), but it isn't able to detect invalid format specifiers. For example

f"{x:f.1}"
"{x:f.1}".format(x=1)

are both wrong (the f is supposed to go after the .1). Also the f-string one is a ValueError and is only checked at runtime.

The format specification mini-language is pretty complicated, so this would be useful, but also maybe not easy to implement. For .format strings you can use https://docs.python.org/3/library/string.html#string.Formatter.parse, but for f-strings, there's nothing in the standard library that can tokenize the f-string components (it would be useful if there were). Libraries like pygments and parso can tokenize them, or maybe the tokenizer added in https://github.com/PyCQA/pyflakes/pull/443 can be extended to handle them.

When importing or defining values in if typing.TYPE_CHECKING blocks the bound names will not be available at runtime and may cause errors when used in the following way:

import typing

if typing.TYPE_CHECKING:
    from module import Type  # some slow import or circular reference

def method(value) -> Type:  # the import is needed by the type checker
    assert isinstance(value, Type)  # this is a runtime error

This change allows pyflakes to track what names are bound for runtime use, and allows it to warn when a non runtime name is used in a runtime context.