Skip to content

Instantly share code, notes, and snippets.

@myint
Last active May 24, 2017 02:41
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save myint/df7b7f6a537a19b5a813a6d8b3cec52c to your computer and use it in GitHub Desktop.
Save myint/df7b7f6a537a19b5a813a6d8b3cec52c to your computer and use it in GitHub Desktop.
Issues in Pyflakes Launchpad
[
{
"status": "Fix Released",
"security_related": false,
"description": "Running pyflakes on this file https://github.com/conda/conda/blob/10ac568e39086df377c5f6e7fe4ecc41fda8015f/conda/logic.py I get\n\nTraceback (most recent call last):\n File \"bin/pyflakes\", line 3, in <module>\n main()\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/api.py\", line 172, in main\n warnings = checkRecursive(args, reporter)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/api.py\", line 129, in checkRecursive\n warnings += checkPath(sourcePath, reporter)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/api.py\", line 96, in checkPath\n return check(codestr, filename, reporter)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/api.py\", line 57, in check\n w = checker.Checker(tree, filename)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/checker.py\", line 295, in __init__\n self.runDeferred(self._deferredFunctions)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/checker.py\", line 332, in runDeferred\n handler()\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/checker.py\", line 818, in runFunction\n self.handleNode(stmt, node)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/checker.py\", line 607, in handleNode\n handler(node)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/checker.py\", line 565, in handleChildren\n self.handleNode(node, tree)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/checker.py\", line 607, in handleNode\n handler(node)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/checker.py\", line 729, in NAME\n self.handleNodeStore(node)\n File \"/Users/aaronmeurer/Documents/pyflakes/pyflakes/checker.py\", line 514, in handleNodeStore\n if used and used[0] is self.scope and name not in self.scope.globals:\nTypeError: 'bool' object is not subscriptable",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1465824,
"duplicate_of": null,
"title": "'bool' object is not subscriptable",
"comments": [
{
"owner": "asmeurer",
"content": "The change from 531b6b58 (shown below) seems to be related, but even after reverting it it gives the same error. \n\n@@ -473,8 +477,8 @@ class Checker(object):\n # if the name was defined in that scope, and the name has\n # been accessed already in the current scope, and hasn't\n # been declared global\n- if (name in scope and scope[name].used and scope[name].used[0] is self.scope\n- and name not in self.scope.globals):\n+ used = name in scope and scope[name].used\n+ if used and used[0] is self.scope and name not in self.scope.globals:\n # then it's probably a mistake\n self.report(messages.UndefinedLocal,\n scope[name].used[1], name, scope[name].source)",
"date_created": "2015-06-16T19:46:23Z"
},
{
"owner": "asmeurer",
"content": "I think the problem is https://github.com/pyflakes/pyflakes/pull/19/files#diff-f0429ba5bb9de6e83abcf687aca4c012R702. That change from the older commit still looks wrong, though (used will always be a boolean). ",
"date_created": "2015-06-16T19:48:17Z"
},
{
"owner": "asmeurer",
"content": "Oh derp, 'and' returns the object, not a boolean. Still, it's a bit confusing. \n\nThe bug itself is fixed by https://github.com/pyflakes/pyflakes/pull/22. ",
"date_created": "2015-06-17T01:27:30Z"
},
{
"owner": "bitglue",
"content": "Released 0.9.2.",
"date_created": "2015-06-17T10:24:23Z"
}
],
"importance": "Critical",
"lp_url": "https://bugs.launchpad.net/bugs/1465824",
"date_created": "2015-06-16T19:41:07Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "This simple code make pyflakes throw and exception (python 2.7.11 and 3.5.1).\n-------------------------------------------\n# -*- coding: utf-8 -*-\n\nfrom . import foo\n\nclass MyClass(object):\n pass\n-------------------------------------------\nTraceback (most recent call last):\n File \"/usr/lib/python3.5/runpy.py\", line 170, in _run_module_as_main\n \"__main__\", mod_spec)\n File \"/usr/lib/python3.5/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"pyflakes/__main__.py\", line 5, in <module>\n main(prog='pyflakes')\n File \"/home/mal/develop/python/pyflakes/pyflakes/api.py\", line 184, in main\n warnings = checkRecursive(args, reporter)\n File \"/home/mal/develop/python/pyflakes/pyflakes/api.py\", line 141, in checkRecursive\n warnings += checkPath(sourcePath, reporter)\n File \"/home/mal/develop/python/pyflakes/pyflakes/api.py\", line 108, in checkPath\n return check(codestr, filename, reporter)\n File \"/home/mal/develop/python/pyflakes/pyflakes/api.py\", line 69, in check\n w = checker.Checker(tree, filename)\n File \"/home/mal/develop/python/pyflakes/pyflakes/checker.py\", line 403, in __init__\n self.handleChildren(tree)\n File \"/home/mal/develop/python/pyflakes/pyflakes/checker.py\", line 725, in handleChildren\n self.handleNode(node, tree)\n File \"/home/mal/develop/python/pyflakes/pyflakes/checker.py\", line 772, in handleNode\n handler(node)\n File \"/home/mal/develop/python/pyflakes/pyflakes/checker.py\", line 1151, in IMPORTFROM\n node.module, alias.name)\n File \"/home/mal/develop/python/pyflakes/pyflakes/checker.py\", line 199, in __init__\n full_name = module + '.' + self.real_name\nTypeError: unsupported operand type(s) for +: 'NoneType' and 'str'",
"tags": [],
"duplicates": [
1580214
],
"assignee": "jayvdb",
"milestone": null,
"owner": "ma-latorre-diaz",
"id": 1560134,
"duplicate_of": null,
"title": "TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'",
"comments": [
{
"owner": "bitglue",
"content": "I'm pretty sure this is fixed in the current version of pyflakes. What version are you using?",
"date_created": "2016-03-21T20:22:26Z"
},
{
"owner": "ma-latorre-diaz",
"content": "Version: 1.1.0\nLatest commit: aec68a7847d8dbd1371242f42f9302103a68178f\n\ncommit aec68a7847d8dbd1371242f42f9302103a68178f\nAuthor: John Vandenberg <email address hidden>\nDate: Thu Nov 26 01:24:53 2015 +1100\n\n Importation classes with imported name and alias\n\n In order to solve many corner cases related to imports,\n more information is needed about each import.\n\n This change creates two new classes:\n - SubmoduleImportation\n - ImportationFrom\n\n And adds an optional parameter full_name to the super class\n Importation.\n\n Functionally, this change only improves existing error messages\n to report the full imported name where previously an error\n would include only the import alias.\n\n",
"date_created": "2016-03-21T20:37:21Z"
},
{
"owner": "ma-latorre-diaz",
"content": "I'm a mercurial user so, just in case:\n> git status\nOn branch master\nYour branch is up-to-date with 'origin/master'.\nnothing to commit, working directory clean\n",
"date_created": "2016-03-21T20:47:48Z"
},
{
"owner": "bitglue",
"content": "Hm...1.1.0 is pretty recent. I'll have to investigate this more when I have some time. Thanks for the report.",
"date_created": "2016-03-21T21:45:49Z"
},
{
"owner": "predder",
"content": "This happens for me in 1.2 but not 1.0 or 1.1.\n\nnathan@w530 ~/code/inbox-persist \u266a flake8 inboxpersist/\nTraceback (most recent call last):\n File \"/usr/local/bin/flake8\", line 11, in <module>\n sys.exit(main())\n File \"/usr/local/lib/python2.7/dist-packages/flake8/main.py\", line 33, in main\n report = flake8_style.check_files()\n File \"/usr/local/lib/python2.7/dist-packages/flake8/engine.py\", line 180, in check_files\n return self._retry_serial(self._styleguide.check_files, paths=paths)\n File \"/usr/local/lib/python2.7/dist-packages/flake8/engine.py\", line 171, in _retry_serial\n return func(*args, **kwargs)\n File \"/usr/local/lib/python2.7/dist-packages/pep8.py\", line 1840, in check_files\n self.input_dir(path)\n File \"/usr/local/lib/python2.7/dist-packages/pep8.py\", line 1876, in input_dir\n runner(os.path.join(root, filename))\n File \"/usr/local/lib/python2.7/dist-packages/flake8/engine.py\", line 125, in input_file\n return fchecker.check_all(expected=expected, line_offset=line_offset)\n File \"/usr/local/lib/python2.7/dist-packages/pep8.py\", line 1574, in check_all\n self.check_ast()\n File \"/usr/local/lib/python2.7/dist-packages/pep8.py\", line 1520, in check_ast\n checker = cls(tree, self.filename)\n File \"/usr/local/lib/python2.7/dist-packages/flake8/_pyflakes.py\", line 43, in __init__\n withDoctest=self.withDoctest)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/checker.py\", line 402, in __init__\n self.handleChildren(tree)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/checker.py\", line 724, in handleChildren\n self.handleNode(node, tree)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/checker.py\", line 771, in handleNode\n handler(node)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/checker.py\", line 1150, in IMPORTFROM\n node.module, alias.name)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/checker.py\", line 198, in __init__\n full_name = module + '.' + self.real_name\nTypeError: unsupported operand type(s) for +: 'NoneType' and 'str'\n",
"date_created": "2016-05-04T07:29:41Z"
},
{
"owner": "jayvdb",
"content": "fwiw, there is a version mixup at the moment, with pypi providing 1.2.0 but master is still 1.1.0\n(https://github.com/pyflakes/pyflakes/blob/master/pyflakes/__init__.py)\n\nThanks for the report Miguel. I can see where the problem is, and should have a fix shortly.\n",
"date_created": "2016-05-04T07:55:39Z"
},
{
"owner": "bitglue",
"content": "I just updated master. Forgot to push last night when I made the release :)",
"date_created": "2016-05-04T11:26:13Z"
},
{
"owner": "jayvdb",
"content": "fwiw, I have a fix https://github.com/jayvdb/pyflakes/commit/5c039f90b78fb4eb2b10287295f411e86baa8233\n\nBut I am working on another approach, as relative imports can also be star imports, and it would be nice to fix the error messages for star import at the same time. Should only be an hour or so.",
"date_created": "2016-05-04T11:44:44Z"
},
{
"owner": "jayvdb",
"content": "https://github.com/pyflakes/pyflakes/pull/61",
"date_created": "2016-05-04T12:31:58Z"
},
{
"owner": "patrick-m-dunnigan",
"content": "This is still a problem in 1.2.2. Cannot run pyflakes whatsoever. ",
"date_created": "2016-05-06T16:57:49Z"
},
{
"owner": "bitglue",
"content": "If you'd like to see a fix faster, feel free to review https://github.com/pyflakes/pyflakes/pull/61\n",
"date_created": "2016-05-06T17:14:23Z"
},
{
"owner": "smoser",
"content": "Just ran into this in Ubuntu Yakkety which and filed bug 1580214. Then duped that here.\nRecreate is as simple as:\n\n$ mkdir x\n$ echo \"FOO = 1\" > x/__init__.py\n$ echo \"from . import FOO\" > x/wark.py\n$ python -m pyflakes x/\n",
"date_created": "2016-05-10T14:58:41Z"
},
{
"owner": "barry",
"content": "This currently only affects Yakkety (or a PyPI or from-source install). Xenial isn't affected. I've subscribed to the upstream bug and will cherry pick it once they land the fix, or upload a new upstream if that's provided soon after.",
"date_created": "2016-05-10T18:18:29Z"
},
{
"owner": "ma-latorre-diaz",
"content": "My current workaround is changing checker.py:212 from:\n\nfull_name = module + '.' + self.real_name\n\nto\n\nfull_name = (module or '') + '.' + self.real_name\n",
"date_created": "2016-05-10T19:58:44Z"
},
{
"owner": "smoser",
"content": "well, heres to hoping there is something for barry to cherry pick soon.\nCurrently anything that uses this in its build is probably FTBFS (fails to build from source). Example is curtin. I'm forced to skip or wait to upload.\n\nI'm sure that curtin isn't the only thing that does this.\n",
"date_created": "2016-05-10T20:59:12Z"
},
{
"owner": "barry",
"content": "@ma-latorre-diaz: That fixes it for me too. I've added a DEP-8 test for this case, and a quilt patch as you suggest. I see no other regressions, so I'll upload this fix to Debian and it should autosync to Yakkety soon enough. We can remove the patch when a new upstream with the fix is available. Thanks!",
"date_created": "2016-05-11T21:29:22Z"
},
{
"owner": "jayvdb",
"content": "With that one-line fix, the error message reported will be wrong. The correct fix is in the github PR.",
"date_created": "2016-05-12T00:50:54Z"
},
{
"owner": "barry",
"content": "On May 12, 2016, at 12:50 AM, John Vandenberg wrote:\n\n>With that one-line fix, the error message reported will be wrong. The\n>correct fix is in the github PR.\n\nI'm subscribed to the PR and will update the patch once that gets accepted and\nmerged. It looks like there's still some discussion going on about it?\n\nFor now, it's good just that pyflakes doesn't crash.\n",
"date_created": "2016-05-12T13:16:45Z"
},
{
"owner": "jayvdb",
"content": "The current patch addresses all previous review comments by reviewers.",
"date_created": "2016-05-12T15:29:13Z"
},
{
"owner": "barry",
"content": "On May 12, 2016, at 03:29 PM, John Vandenberg wrote:\n\n>The current patch addresses all previous review comments by reviewers.\n\nI'll try it out instead of the current quick hack. Once a new upstream is\nreleased with the fix, I'll upload it dropping the patch.\n",
"date_created": "2016-05-12T16:50:59Z"
}
],
"importance": "Critical",
"lp_url": "https://bugs.launchpad.net/bugs/1560134",
"date_created": "2016-03-21T17:12:45Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "The following code causes an exception\n\ntry:\n pass\nexcept Exception as e:\n del e\n\n$ python3.4 -m pyflakes test_del_exception.py\nTraceback (most recent call last):\n File \"/usr/lib64/python3.4/runpy.py\", line 170, in _run_module_as_main\n \"__main__\", mod_spec)\n File \"/usr/lib64/python3.4/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/__main__.py\", line 5, in <module>\n main(prog='pyflakes')\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/api.py\", line 184, in main\n warnings = checkRecursive(args, reporter)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/api.py\", line 141, in checkRecursive\n warnings += checkPath(sourcePath, reporter)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/api.py\", line 108, in checkPath\n return check(codestr, filename, reporter)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/api.py\", line 69, in check\n w = checker.Checker(tree, filename)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/checker.py\", line 425, in __init__\n self.handleChildren(tree)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/checker.py\", line 747, in handleChildren\n self.handleNode(node, tree)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/checker.py\", line 794, in handleNode\n handler(node)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/checker.py\", line 1196, in TRY\n self.handleChildren(node, omit='body')\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/checker.py\", line 747, in handleChildren\n self.handleNode(node, tree)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/checker.py\", line 794, in handleNode\n handler(node)\n File \"/usr/lib/python3.4/site-packages/pyflakes-1.2.1-py3.4.egg/pyflakes/checker.py\", line 1226, in EXCEPTHANDLER\n del self.scope[node.name]\nKeyError: 'e'\n\nThis was introduced in 1.2.0 with https://github.com/pyflakes/pyflakes/commit/2a698f87c02a43d4489e30481e9def14ed4b4431",
"tags": [],
"duplicates": [],
"assignee": "bitglue",
"milestone": null,
"owner": "jayvdb",
"id": 1578903,
"duplicate_of": null,
"title": "del of exception causes Exception",
"comments": [
{
"owner": "bitglue",
"content": "Looks like this happens with Python 3 only.",
"date_created": "2016-05-06T10:45:50Z"
},
{
"owner": "bitglue",
"content": "https://github.com/pyflakes/pyflakes/pull/67",
"date_created": "2016-05-06T10:53:39Z"
},
{
"owner": "jayvdb",
"content": "Yes, the new exception processing which causes this is Python 3 only",
"date_created": "2016-05-06T11:22:32Z"
}
],
"importance": "Critical",
"lp_url": "https://bugs.launchpad.net/bugs/1578903",
"date_created": "2016-05-06T03:37:03Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Pyflakes complains that 'a' is unused, and doesn't spot that 'b' and 'c' are undefined, in the following code:\n\ndef f(seq):\n a = 0\n seq[a] += 1\n seq[b] /= 2\n c[0] *= 2\n\nIt seems to work correctly with assignments to slices, and in-place operations that don't involve slices.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.6.1",
"owner": "bistromathic1-5",
"id": 1108904,
"duplicate_of": null,
"title": "Variables on LHS of in-place slice operations are ignored",
"comments": [
{
"owner": "florent.x",
"content": "This is confirmed as a regression of pyflakes 0.6.",
"date_created": "2013-01-29T15:00:19Z"
},
{
"owner": "florent.x",
"content": "Thank you, fixed in 0.6.1.",
"date_created": "2013-01-29T15:41:17Z"
}
],
"importance": "High",
"lp_url": "https://bugs.launchpad.net/bugs/1108904",
"date_created": "2013-01-29T13:58:05Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "The calculation of the line number is wrong for Doctest syntax error.\n\nhttps://bitbucket.org/tarek/flake8/issue/105/indexerror-on-pep8\n\nThis is a regression of Pyflakes 0.7 and 0.7.1",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7.2",
"owner": "florent.x",
"id": 1172130,
"duplicate_of": null,
"title": "Wrong line number for Doctext syntax error",
"comments": [],
"importance": "High",
"lp_url": "https://bugs.launchpad.net/bugs/1172130",
"date_created": "2013-04-24T05:57:21Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "As of python 3.4.0 pyflakes will crash in checker.py: \n\nFile \"../site-packages/pyflakes/checker.py\", line 730, in LAMBDA\n for annotation in (node.args.varargannotation,\nAttributeError: 'arguments' object has no attribute 'varargannotation'\n\nCode that generates the error\n\n if hasattr(node, 'returns'): # Only for FunctionDefs \n for annotation in (node.args.varargannotation,\n node.args.kwargannotation, node.returns):\n\t self.handleNode(annotation, node)\n\n\nIt seems that the module ast has changed from python 3.3 to 3.4. The attribute 'varargannotation' is no longer present in the newer version.\n\nIn 3.3 the documentation: (http://docs.python.org/3.3/library/ast.html#abstract-grammar)\n \narguments = (arg* args, identifier? vararg, expr? varargannotation,\n arg* kwonlyargs, identifier? kwarg,\n expr? kwargannotation, expr* defaults,\n expr* kw_defaults)\n\nIn 3.4 the dokumentation says: (http://docs.python.org/3.4/library/ast.html#abstract-grammar)\n\narguments = (arg* args, arg? vararg, arg* kwonlyargs, expr* kw_defaults,\n arg? kwarg, expr* defaults)",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "moln",
"id": 1295554,
"duplicate_of": null,
"title": "pyflakes crashes with AttributeError. No attribute 'varargannotation'",
"comments": [
{
"owner": "moln",
"content": "Circumventing the reported error reveals a second bug:\n\nAttributeError: 'FlakesChecker' object has no attribute 'NAMECONSTANT'. I assume this has to do with the new Enumeration type in 3.4. Anyhow a second fix avoids also this crash to get it back to a \"working\" state.\n\nThese fixes should just be considered a hint at how to fix these problems.\n\n\n\n\n\n",
"date_created": "2014-03-21T09:20:08Z"
},
{
"owner": "florent.x",
"content": "Alreasy fixed in trunk.",
"date_created": "2014-03-22T14:07:36Z"
},
{
"owner": "sorin-sbarnea",
"content": "This tells me that people are probably not using not using pyflakes with python 3.5 or 3.4",
"date_created": "2016-03-01T11:04:04Z"
},
{
"owner": "sorin-sbarnea",
"content": "Here is another one that seems very similar to me:\n\n File \"/Users/sorins/bmll/flare/env/lib/python3.5/site-packages/pyflakes/checker.py\", line 462, in getNodeHandler\n self._nodeHandlers[node_class] = handler = getattr(self, nodeType)\nAttributeError: 'FlakesChecker' object has no attribute 'MATMULT'\n",
"date_created": "2016-03-01T11:05:29Z"
}
],
"importance": "High",
"lp_url": "https://bugs.launchpad.net/bugs/1295554",
"date_created": "2014-03-21T08:28:10Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "There are numerous bug fixes included in pyflakes since 0.8.1 was released (over a year ago). A new release would be greatly appreciated.",
"tags": [],
"duplicates": [
1459239
],
"assignee": "bitglue",
"milestone": null,
"owner": "icordasc",
"id": 1459240,
"duplicate_of": null,
"title": "Release 0.8.2 or 0.9.0",
"comments": [
{
"owner": "bitglue",
"content": "Acknowledged. I should have access to the PyPI listing now so I'll give this a shot soon.",
"date_created": "2015-05-27T14:49:36Z"
},
{
"owner": "frewsxcv",
"content": "0.9.0 has been released, so this can be closed, right?",
"date_created": "2015-06-02T19:07:13Z"
},
{
"owner": "bitglue",
"content": "Yuppers!",
"date_created": "2015-06-02T20:04:37Z"
}
],
"importance": "High",
"lp_url": "https://bugs.launchpad.net/bugs/1459240",
"date_created": "2015-05-27T13:28:52Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "The following code:\n\nclass Foo(object):\n from bar import baz\n def __init__(self):\n self.foo = self.baz()\n\ndetects 'baz' as \"imported but unused\".\n\n____\nPlease open github for issues!",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "spaceone",
"id": 1463566,
"duplicate_of": null,
"title": "false positive: imported but unused",
"comments": [
{
"owner": "jayvdb",
"content": "https://github.com/pyflakes/pyflakes/pull/44 proposes a fix for this.",
"date_created": "2015-11-15T09:56:34Z"
}
],
"importance": "High",
"lp_url": "https://bugs.launchpad.net/bugs/1463566",
"date_created": "2015-06-09T20:59:13Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "The latest published pyflakes version doesn't process brand new async def constructions from pep 492.\nBut I see https://github.com/pyflakes/pyflakes/pull/30 with fix is merged to master.\n\nPlease make a PyPI release with the fix -- Python 3.5 has been release last week.",
"tags": [],
"duplicates": [],
"assignee": "bitglue",
"milestone": null,
"owner": "andrew-svetlov",
"id": 1497690,
"duplicate_of": null,
"title": "Create new PyPI release",
"comments": [
{
"owner": "bitglue",
"content": "done!",
"date_created": "2015-09-20T16:01:00Z"
},
{
"owner": "andrew-svetlov",
"content": "Thanks!",
"date_created": "2015-09-20T17:51:23Z"
}
],
"importance": "High",
"lp_url": "https://bugs.launchpad.net/bugs/1497690",
"date_created": "2015-09-20T07:28:05Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Let's say you have this file:\n\n#! /usr/bin/python\nfrom __future__ import print_function\nimport sys\nprint('test', file=sys.stderr)\n\nthen pyflakes correct recognizes the print function and is happy. However, let's say you change the first line to\n\n#!/usr/bin/python3\n\nand remove the future import. Then pyflakes isn't so happy about the print() function.\n\nNo doubt it's a considerable amount of work to support Python 3 directly, but at least with this bug we can track that effort.",
"tags": [],
"duplicates": [
1085352
],
"assignee": "florent.x",
"milestone": "0.6.1",
"owner": "barry",
"id": 989203,
"duplicate_of": null,
"title": "pyflakes native support for Python 3",
"comments": [
{
"owner": "florent.x",
"content": "This branch brings Python 3 support https://github.com/florentx/pyflakes\n\nIt is based on version 0.5 from lp:divmod.org",
"date_created": "2012-12-29T22:25:33Z"
},
{
"owner": "florent.x",
"content": "Planned after the switch to unittest2 for the tests (https://bugs.launchpad.net/pyflakes/+bug/1097061).\n\nThe only limitation will be that you need to run with Python2 to check Python2 code, and you'll need to run with Python3 to check Python3 code.",
"date_created": "2013-01-08T01:30:10Z"
},
{
"owner": "bistromathic1",
"content": "Maybe you are aware of this (and thanks for adding python 3 support!), but there are some bits of new syntax that don't seem to be covered by this fix. The following code causes pyflakes to complain that ABCMeta is unused:\n\nfrom abc import ABCMeta\n\n\nclass A(metaclass=ABCMeta): # new metaclass syntax\n pass\n\n\ndef f(a: ABCMeta): # annotations\n pass\n\n\ndef g(a, *args, b=ABCMeta): # defaults for keyword-only arguments\n pass",
"date_created": "2013-01-28T14:32:50Z"
},
{
"owner": "florent.x",
"content": "Thank you for reporting it\r\n\r\nI will investigate these cases.",
"date_created": "2013-01-28T15:37:26Z"
},
{
"owner": "florent.x",
"content": "Should be fixed with latest change (rev 61).\r\n\r\nhttps://github.com/pyflakes/pyflakes/commit/02864b26e590893f7effd61d96460e60ff6dec7f\r\n\r\nThank you",
"date_created": "2013-01-28T17:58:10Z"
},
{
"owner": "florent.x",
"content": "Change landed in trunk: http://bazaar.launchpad.net/~pyflakes-dev/pyflakes/master/revision/61",
"date_created": "2013-01-28T17:59:38Z"
}
],
"importance": "Medium",
"lp_url": "https://bugs.launchpad.net/bugs/989203",
"date_created": "2012-04-26T20:25:49Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Hello,\n\nFollowing the discussion on the mailing-list, I propose to extract the Pyflakes repository and publish it under the Pyflakes project.\n\nThe main reason is that it is less confusing for all\nthe actors (users, developers, etc...) to find the project at a single\nplace: the source code, the issue tracker, the downloads...\nSecond reason, is that it makes it easier for external contributions. You\nonly clone the PyFlakes project, without need to download the code of all\nthe unrelated Divmod's projects. Same benefit when someone want to mirror\nthe code on any other VCS.\nAnd the PyFlakes project is so widely used, that it deserves to have its\nown repository.\n\n\nI did an export of the current state of the Pyflakes/ folder, with history.\nIt is available as lp:~divmod-dev/pyflakes/trunk\n\nIf accepted, the next moves are:\n\n* setup lp:pyflakes as the alias for lp:~divmod-dev/pyflakes/trunk\n* submit a MP to remove Pyflakes from the lp:divmod.org repository\n* update the homepage of https://launchpad.net/pyflakes to inform where is the source code\n* update the documentation at http://divmod.readthedocs.org/en/latest/products/pyflakes.html\n\nThen the open issues will be reviewed and the merge proposals will be updated to target the new repository.\n(There's only few small patches, I already had a look)",
"tags": [],
"duplicates": [],
"assignee": "florent.x",
"milestone": "0.6.1",
"owner": "florent.x",
"id": 1095248,
"duplicate_of": null,
"title": "move Pyflakes to its own repository",
"comments": [
{
"owner": "florent.x",
"content": "The repository is now linked with lp:pyflakes.\n\nThe branch for the issue 916264 is migrated too: lp:~divmod-dev/pyflakes/less-redef\nThe other branch has a single change http://bazaar.launchpad.net/~witsch/divmod.org/Pyflakes/revision/2699/Pyflakes/setup.py but it does not seem related to any existing issue.\n\n\nThe old directory can be removed from divmod.org/Pyflakes : merge proposal is attached to this issue.",
"date_created": "2013-01-07T20:59:35Z"
},
{
"owner": "florent.x",
"content": "Pyflakes is now removed from divmod.org repository.\n\nI've submitted a pull-request for the documentation:\nhttps://github.com/MostAwesomeDude/divmod-docs/pull/8\n",
"date_created": "2013-01-08T02:02:10Z"
}
],
"importance": "Medium",
"lp_url": "https://bugs.launchpad.net/bugs/1095248",
"date_created": "2013-01-07T07:06:42Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "I propose to switch to unittest2 instead of Twisted in order to test against more versions of Python (2.5 and Python 3).\n\nMoreover unittest is more focused than the Twisted framework and it is less code to download and install (for automated tests).",
"tags": [],
"duplicates": [],
"assignee": "florent.x",
"milestone": "0.6.1",
"owner": "florent.x",
"id": 1097061,
"duplicate_of": null,
"title": "switch to unittest2 for the test framework",
"comments": [
{
"owner": "florent.x",
"content": "Related to issue #989203 too.\nhttps://bugs.launchpad.net/pyflakes/+bug/989203\n",
"date_created": "2013-01-07T22:36:18Z"
}
],
"importance": "Medium",
"lp_url": "https://bugs.launchpad.net/bugs/1097061",
"date_created": "2013-01-07T22:35:52Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "When updating from pyflakes 0.5.0 to pyflakes 0.6.1 many occurances of 'list comprehension redefines' are listed erroneously. The issue appears to be that pyflakes will complain about reusing the same loop variable name in multiple list comprehensions.\n\nHere are two lines for example:\n\n168:\nwells = Well.objects.filter(id__in=(well.id for well in wells))\n \n...\n\n183:\nfx_wells = [well for well in wells if well.assay_subtype == fx_subtype]\n\nAnd a message such as below appears.\n\nfoo/bar.py:183:: list comprehension redefines 'well' from line 168\n\nIn this case pyflakes should be smart enough to realize that 'well' will not be incorrectly used because it will be initialized immediately with the expected value in the second list comprehension.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7",
"owner": "jfalkner",
"id": 1112067,
"duplicate_of": null,
"title": "Erroneous 'list comprehension redefines' in Python 2.7 pyflakes 0.6.1",
"comments": [
{
"owner": "icordasc",
"content": "I couldn't reproduce this with the attached file.",
"date_created": "2013-02-02T18:43:11Z"
},
{
"owner": "bistromathic1",
"content": "This problem seems to occur when a dummy variable name in a generator expression, a dict comprehension, or a set comprehension is then reused in a list comprehension, for example:\n\na = [1, 2, 3, 4, 5, 6]\n\nb = (i + 1 for i in a)\nc = [i + 2 for i in b]\n\nprint(c)\n\nThe pyflakes output is:\n\ntest-1.py:4: list comprehension redefines 'i' from line 3\n\nI only tried this in python 3.2.",
"date_created": "2013-02-07T23:30:47Z"
},
{
"owner": "florent.x",
"content": "actually, this should not report redefinition of variable for:\r\n * generator expressions\r\n * dict comprehensions\r\n * set comprehensions\r\n\r\nOnly the list comprehension leaks its variable, and only with Python 2.x.\r\n(Though we'll keep reporting the warning for 3.x as well)",
"date_created": "2013-02-08T00:56:00Z"
},
{
"owner": "florent.x",
"content": "This should fix it.\n\nhttps://code.launchpad.net/~pyflakes-dev/pyflakes/1112067-comprehension-scope/+merge/147264",
"date_created": "2013-02-08T01:02:46Z"
},
{
"owner": "danken",
"content": "I'm not sure it's the very same bug, but pylakes 0.6.1 (python 2.7.3) considers the following as having a redefinition of x:\n\nif False:\n x = 1\nelse:\n [x for x in [1]]\n",
"date_created": "2013-02-28T12:40:41Z"
},
{
"owner": "florent.x",
"content": "> I'm not sure it's the very same bug, but pylakes 0.6.1 (python 2.7.3) considers the following as having a redefinition of x:\n> \n> if False:\n> x = 1\n> else:\n> [x for x in [1]]\n\n\nthis last one is a different bug, it should be reported separately.",
"date_created": "2013-03-05T18:21:21Z"
},
{
"owner": "florent.x",
"content": "The fix for this second bug was added to the same branch:\nhttps://code.launchpad.net/~pyflakes-dev/pyflakes/1112067-comprehension-scope/+merge/147264\n",
"date_created": "2013-03-06T22:42:04Z"
}
],
"importance": "Medium",
"lp_url": "https://bugs.launchpad.net/bugs/1112067",
"date_created": "2013-02-01T03:19:15Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "This is with pyflakes 0.7, Python 2.7.3, LANG=en_US.UTF-8 on Fedora 17:\n\n$ pyflakes p\u00f6\u00f6\nTraceback (most recent call last):\n File \"/usr/bin/pyflakes\", line 9, in <module>\n load_entry_point('pyflakes==0.7', 'console_scripts', 'pyflakes')()\n File \"/usr/lib/python2.7/site-packages/pyflakes/api.py\", line 129, in main\n warnings = checkRecursive(args, reporter)\n File \"/usr/lib/python2.7/site-packages/pyflakes/api.py\", line 120, in checkRecursive\n warnings += checkPath(sourcePath, reporter)\n File \"/usr/lib/python2.7/site-packages/pyflakes/api.py\", line 86, in checkPath\n reporter.unexpectedError(filename, msg.args[1])\n File \"/usr/lib/python2.7/site-packages/pyflakes/reporter.py\", line 40, in unexpectedError\n self._stderr.write(u(\"%s: %s\\n\") % (filename, msg))\nUnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)\n\n0.6.1 fails the same way, but 0.5 works:\n\n$ pyflakes p\u00f6\u00f6\np\u00f6\u00f6: No such file or directory",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7.1",
"owner": "vskytta",
"id": 1170459,
"duplicate_of": null,
"title": "Reporting errors in non-ASCII filenames fails",
"comments": [
{
"owner": "florent.x",
"content": "Confirmed with Python 2.x",
"date_created": "2013-04-18T21:10:10Z"
},
{
"owner": "vskytta",
"content": "Fix otherwise confirmed, but if stderr is redirected to a file it still fails:\n\n$ pyflakes p\u00f6\u00f6 2>stderr.out\n$ cat stderr.out\nTraceback (most recent call last):\n File \"/usr/bin/pyflakes\", line 9, in <module>\n load_entry_point('pyflakes==0.7.1a0', 'console_scripts', 'pyflakes')()\n File \"/usr/lib/python2.7/site-packages/pyflakes/api.py\", line 129, in main\n warnings = checkRecursive(args, reporter)\n File \"/usr/lib/python2.7/site-packages/pyflakes/api.py\", line 120, in checkRecursive\n warnings += checkPath(sourcePath, reporter)\n File \"/usr/lib/python2.7/site-packages/pyflakes/api.py\", line 86, in checkPath\n reporter.unexpectedError(filename, msg.args[1])\n File \"/usr/lib/python2.7/site-packages/pyflakes/reporter.py\", line 45, in unexpectedError\n _write(self._stderr, \"%s: %s\\n\" % (filename, msg))\n File \"/usr/lib/python2.7/site-packages/pyflakes/reporter.py\", line 11, in _write\n stream.write(text.decode(encoding, 'replace'))\nUnicodeEncodeError: 'ascii' codec can't encode characters in position 1-2: ordinal not in range(128)\n",
"date_created": "2013-04-19T14:16:26Z"
},
{
"owner": "florent.x",
"content": "Thank you for this review.\n\nI've reworked the fix, and it seems to work better in all cases.",
"date_created": "2013-04-21T09:51:31Z"
}
],
"importance": "Medium",
"lp_url": "https://bugs.launchpad.net/bugs/1170459",
"date_created": "2013-04-18T19:14:14Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Running the pyflakes checker on a code I get this:\n\n File \"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyflakes-0.8.1-py2.6.egg/pyflakes/api.py\", line 88, in checkPath\n return check(codestr, filename, reporter)\n File \"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyflakes-0.8.1-py2.6.egg/pyflakes/api.py\", line 58, in check\n w = checker.Checker(tree, filename)\n File \"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyflakes-0.8.1-py2.6.egg/pyflakes/checker.py\", line 294, in __init__\n self.handleChildren(tree)\n File \"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyflakes-0.8.1-py2.6.egg/pyflakes/checker.py\", line 547, in handleChildren\n self.handleNode(node, tree)\n File \"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyflakes-0.8.1-py2.6.egg/pyflakes/checker.py\", line 589, in handleNode\n handler(node)\n File \"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyflakes-0.8.1-py2.6.egg/pyflakes/checker.py\", line 547, in handleChildren\n self.handleNode(node, tree)\n File \"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyflakes-0.8.1-py2.6.egg/pyflakes/checker.py\", line 589, in handleNode\n handler(node)\n File \"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyflakes-0.8.1-py2.6.egg/pyflakes/checker.py\", line 696, in RETURN\n if node.value and not self.scope.returnValue:\nAttributeError: 'ModuleScope' object has no attribute 'returnValue'\n\nUnluckily I'm not able to check the code that raise the error (it's a 3rd party legacy code full of errors).\n\nI skipped the issue changing the line 696 to:\n\n if node.value and hasattr(self.scope, 'returnValue') and not self.scope.returnValue:",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8.2",
"owner": "lucafbb",
"id": 1332451,
"duplicate_of": null,
"title": "AttributeError: 'ModuleScope' object has no attribute 'returnValue'",
"comments": [
{
"owner": "florent.x",
"content": "I can reproduce this case with the following (invalid) snippet:\r\n\r\nclass Foo(object):\r\n return\r\n\r\n\r\nAll versions of Python.",
"date_created": "2014-07-26T11:04:50Z"
},
{
"owner": "adiroiban",
"content": "I have created a pull request to work on this https://github.com/pyflakes/pyflakes/pull/13\n\nIt looks like code on master already handles this condition so I think that we should not merge pull #13 but just close this tickets as solved.\n\nThanks!",
"date_created": "2015-02-14T12:00:56Z"
},
{
"owner": "gforcada",
"content": "I hit the same error... can we get a new release please? I see that there are quite a few changes pending to be released... ",
"date_created": "2015-05-28T10:19:24Z"
}
],
"importance": "Medium",
"lp_url": "https://bugs.launchpad.net/bugs/1332451",
"date_created": "2014-06-20T08:05:44Z"
},
{
"status": "Confirmed",
"security_related": false,
"description": "$ cat tt.py\n#!/usr/bin/python -tt\nimport random\nimport sys\n\ndef main():\n\u00a0\u00a0\u00a0\u00a0f = None\n\u00a0\u00a0\u00a0\u00a0try:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0f = \"bob\"\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if random.choice((True, False)):\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0raise Exception('test')\n\u00a0\u00a0\u00a0\u00a0except:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0del f\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0raise Exception('my custom exception')\n\u00a0\u00a0\u00a0\u00a0print f\n\nif '__main__' == __name__:\n\u00a0\u00a0\u00a0\u00a0sys.exit(main())\n\n$ $ pyflakes tt.py\ntt.py:15: undefined name 'f'",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "happycamp",
"id": 1431099,
"duplicate_of": null,
"title": "pyflakes gives erroneous 'undefined name'",
"comments": [
{
"owner": "bitglue",
"content": "Confirmed. Thanks for the report.",
"date_created": "2015-05-27T15:06:34Z"
},
{
"owner": "peuchele",
"content": "I was about to report the same issue, but with a different example. Pasting here for reference:\nx = 0\nwhile True:\n data = \"dummy\"\n if x == 1:\n del data\n break\n print data\n del data\n break\n\nReal life example:\nhttps://github.com/jelmer/dulwich/blob/master/dulwich/protocol.py#L353",
"date_created": "2015-09-29T11:47:14Z"
},
{
"owner": "jayvdb",
"content": "I believe these are both the same problem as https://bugs.launchpad.net/pyflakes/+bug/1308508 .",
"date_created": "2015-11-20T21:07:19Z"
}
],
"importance": "Medium",
"lp_url": "https://bugs.launchpad.net/bugs/1431099",
"date_created": "2015-03-12T01:02:41Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Tested with pyflakes 0.8.1. Make this file:\n\nclass A():\n def a():\n return 5\n return 7\n\nRun it with pyflakes, you get:\n\nTraceback (most recent call last):\n File \"/usr/bin/pyflakes\", line 9, in <module>\n load_entry_point('pyflakes==0.8.1', 'console_scripts', 'pyflakes')()\n File \"/usr/lib/python2.7/dist-packages/pyflakes/api.py\", line 130, in main\n warnings = checkRecursive(args, reporter)\n File \"/usr/lib/python2.7/dist-packages/pyflakes/api.py\", line 121, in checkRecursive\n warnings += checkPath(sourcePath, reporter)\n File \"/usr/lib/python2.7/dist-packages/pyflakes/api.py\", line 88, in checkPath\n return check(codestr, filename, reporter)\n File \"/usr/lib/python2.7/dist-packages/pyflakes/api.py\", line 58, in check\n w = checker.Checker(tree, filename)\n File \"/usr/lib/python2.7/dist-packages/pyflakes/checker.py\", line 294, in __init__\n self.handleChildren(tree)\n File \"/usr/lib/python2.7/dist-packages/pyflakes/checker.py\", line 547, in handleChildren\n self.handleNode(node, tree)\n File \"/usr/lib/python2.7/dist-packages/pyflakes/checker.py\", line 589, in handleNode\n handler(node)\n File \"/usr/lib/python2.7/dist-packages/pyflakes/checker.py\", line 812, in CLASSDEF\n self.handleNode(stmt, node)\n File \"/usr/lib/python2.7/dist-packages/pyflakes/checker.py\", line 589, in handleNode\n handler(node)\n File \"/usr/lib/python2.7/dist-packages/pyflakes/checker.py\", line 696, in RETURN\n if node.value and not self.scope.returnValue:",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "orblivion",
"id": 1432087,
"duplicate_of": null,
"title": "Return statement in class scope after method causes crash",
"comments": [
{
"owner": "orblivion",
"content": "Oops, forgot the last line of the stack trace:\n\nAttributeError: 'ClassScope' object has no attribute 'returnValue'",
"date_created": "2015-03-14T01:53:45Z"
},
{
"owner": "myint",
"content": "I think this was fixed a month previous to this report:\n\nhttps://github.com/pyflakes/pyflakes/pull/13\n\n(It would be cool if this bug tracker was moved to GitHub where the repository is now.)",
"date_created": "2015-04-03T16:21:02Z"
},
{
"owner": "bitglue",
"content": "I can confirm that this is fixed in master, but not yet released. I'll be doing a release soon, hopefully. Thanks for the report.",
"date_created": "2015-05-27T15:03:45Z"
}
],
"importance": "Medium",
"lp_url": "https://bugs.launchpad.net/bugs/1432087",
"date_created": "2015-03-14T01:53:04Z"
},
{
"status": "Triaged",
"security_related": false,
"description": "With the new pyflakes-0.9.0, and python-2.7.10, the following program:\n\n----\nif 1:\n name = 1 # line 2\n del name\n [ name for name in [] ] # line 4\n\nother = 1 # line 6\ndel other\n[ other for other in [] ] # line 8\n----\n\nreports:\n\n /tmp/pf.py:4: list comprehension redefines 'name' from line 2\n\nI see two problems:\n\n* the 'del name' on line 3 should probably prevent the warning. (this sample\n is a stripped-down version of a larger file, in which I added the 'del\n name' to hush an earlier pyflakes complaint)\n\n* the same pattern on lines 6+8 was not reported, the only difference being\n that it occurred at the top-level scope and not in a function scope.\n\nthanks!\n -Brian",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "warner",
"id": 1461208,
"duplicate_of": null,
"title": "inconsistent redefinition complaint, despite 'del'",
"comments": [
{
"owner": "bitglue",
"content": "Ah, yeah. So there was another change, which I can't find now, which addressed this situation (going from memory here):\n\nfoo = \"foo\"\nif False:\n del foo\nprint foo\n\nThis would complain about the final 'print foo' referencing an undefined foo, but as you can see, this code runs just fine.\n\nThe underlying issue here is that pyflakes doesn't have any notion of of conditional branches. Whenever it sees an 'if', 'while', 'try/except', or similar, it just ignores it, and proceeds as if the body of the branch were not in any branch at all. Another case illustrates why:\n\nif False:\n foo = \"foo\"\nprint foo\n\nYou'll notice pyflakes won't complain about this, even though it clearly won't work. Of course usually the conditional expression is something more complicated, and pyflakes can't actually evaluate it since that would require that it is a python interpreter. So it just makes a stupid assumption.\n\nSo, I'll have to think more about how to fix this. I think it's a situation where all cases can't be accurately covered without making some changes to the underlying assumptions that pyflakes makes. Probably it needs to build a graph of the possible code paths and consider the state of the namespace along each possible path through the graph.\n\nI'm calling this medium priority for now since it's hard to fix without making at least one of these cases wrong, and hopefully just a minor annoyance. If that characterization seems wrong, please post some more code examples and we can look at reverting to the previous behavior.",
"date_created": "2015-06-02T20:24:21Z"
}
],
"importance": "Medium",
"lp_url": "https://bugs.launchpad.net/bugs/1461208",
"date_created": "2015-06-02T18:26:40Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Since pyflakes website is down I am reporting this bug in LP.\n\nThe undefined name WindowsError is raised by pyflakes when running on Unix systems.\n\nIt would be nice if pyflakes would trust the developer that such code is only loaded on Windows and allow to check Windows specific Python code on Unix.\n\n----\n\nPlease let me know if you thinks it is a valid problem.\n\nAlso any advice about how to move this bug report upstream is much appreciated.\n\n----\n\nI have also attached a pocket-lint branch that works around this problem.\n\nCheers,",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.6.1",
"owner": "adiroiban",
"id": 764627,
"duplicate_of": null,
"title": "pyflakes complains about missing WindowsError on Unix",
"comments": [
{
"owner": "adiroiban",
"content": "Hi Curtis,\n\nDo you have any suggestion about how this bug should be solved?\n\nDo you want to have it fixed in pocket-lint or in pyflakes?\n\nWhat do you say about the changes from the attached branch?\n\nCheers,\nAdi",
"date_created": "2011-04-18T17:52:38Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/764627",
"date_created": "2011-04-18T13:35:19Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Pyflakes script is installed on Windows without any extension. As a result, on Windows, it has no file type and cannot be executed from a command-line. Consider using setuptools console_script entry_points or adding a .py extension when installing under Windows.\n\nPS C:\\Users\\jaraco> easy_install pyflakes\nSearching for pyflakes\nReading http://pypi.python.org/simple/pyflakes/\nReading http://www.divmod.org/projects/pyflakes\nReading http://www.divmod.org/trac/wiki/DivmodPyflakes\nBest match: pyflakes 0.4.0\nDownloading http://pypi.python.org/packages/source/p/pyflakes/pyflakes-0.4.0.tar.gz#md5=630a72510aae8758f48cf60e4fa17176\nProcessing pyflakes-0.4.0.tar.gz\nRunning pyflakes-0.4.0\\setup.py -q bdist_egg --dist-dir c:\\users\\jaraco\\appdata\\local\\temp\\easy_install-bi_1bs\\pyflakes-0.4.0\\egg-dist-tmp-u6vcvn\nhgtools.SubprocessManager('.') could not find files: abort: There is no Mercurial repository here (.hg not found)!\nzip_safe flag not set; analyzing archive contents...\npyflakes.checker: module references __file__\npyflakes.checker: module references __path__\npyflakes.test.test_undefined_names: module references __file__\npyflakes.test.test_undefined_names: module references __path__\nAdding pyflakes 0.4.0 to easy-install.pth file\nInstalling pyflakes script to C:\\Python\\Scripts\n\nInstalled c:\\python\\lib\\site-packages\\pyflakes-0.4.0-py2.7.egg\nProcessing dependencies for pyflakes\nFinished processing dependencies for pyflakes",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.6.1",
"owner": "jaraco",
"id": 794331,
"duplicate_of": null,
"title": "pyflakes script not executable on Windows",
"comments": [
{
"owner": "mfoord",
"content": "I get this trying to use pyflakes on Windows (Python 2.6 - windows 7 - pyflakes 0.4.0):\n\nC:\\My Dropbox\\RoboRally\\RoboRallyIronPython\n> pyflakes MyBrain.py\nTraceback (most recent call last):\n File \"C:\\Python26\\Scripts\\pyflakes.py\", line 3, in <module>\n from pyflakes.scripts.pyflakes import main\n File \"C:\\Python26\\Scripts\\pyflakes.py\", line 3, in <module>\n from pyflakes.scripts.pyflakes import main\nImportError: No module named scripts.pyflakes\n\nThat is after installation with easy_install. Using pip it doesn't install an executable script for Windows at all.",
"date_created": "2011-08-21T19:25:29Z"
},
{
"owner": "sorin-sbarnea",
"content": "In fact pyflakes doesnt install an executable at all on windows. It must install a pyflakes.bat with the following content\n\n@echo off\nrem Use python to execute the python script having the same name as this batch\nrem file, but without any extension, located in the same directory as this\nrem batch file\npython \"%~dpn0\" %*\n\n\nI have 22 other scripts following the same recipe, or you could try to comeone with an pyflakes.exe but I'm sure it's not what you want.",
"date_created": "2011-12-07T11:12:54Z"
},
{
"owner": "lbolognini",
"content": "The fix for this is super easy. Just rename the Scripts\\pyflakes file something like runpyflakes also if it had an extension it would be nice.\n\nSolution for this bug was found here:\n\nhttp://stackoverflow.com/questions/11444245/how-can-i-get-pyflakes-to-run-on-windows",
"date_created": "2012-09-08T00:41:03Z"
},
{
"owner": "florent.x",
"content": "The missing entry_point is proposed in this patch:\nhttp://bazaar.launchpad.net/~witsch/divmod.org/Pyflakes/revision/2699",
"date_created": "2013-01-08T10:38:32Z"
},
{
"owner": "florent.x",
"content": "Merged with revision 60 (rev 59.1.4)",
"date_created": "2013-01-27T16:52:25Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/794331",
"date_created": "2011-06-08T00:53:20Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Such code:\n\ndef f(a):\n if a:\n def g(): pass\n else:\n def g(): do_something()\n\nwill issue a warning with a redefinition of g",
"tags": [],
"duplicates": [
969920
],
"assignee": "florent.x",
"milestone": "0.6.1",
"owner": "fijal",
"id": 800691,
"duplicate_of": null,
"title": "False positive redefinition with functions defined in conditionals",
"comments": [
{
"owner": "jtaylor",
"content": "does not only affect closures but any conditional:\n\nif True:\n def f():\n pass\nelse:\n def f():\n pass\n\nredefinition of function 'f' from line 2",
"date_created": "2012-03-15T20:40:33Z"
},
{
"owner": "exarkun",
"content": "I expect this is a duplicate of https://bugs.launchpad.net/pyflakes/+bug/916264\n",
"date_created": "2012-03-15T21:19:57Z"
},
{
"owner": "adiroiban",
"content": "It looks like #916264 is about RedefinedWhileUnused while this is about the generic Redefined\n\n\nMaybe they can be solved from one go... I will check to see what can be done.",
"date_created": "2012-04-30T15:07:15Z"
},
{
"owner": "mirko-dziadzka+launchpad-net",
"content": "This also affect try/except statement like:\n\ntry:\n from a import f\nexcept ImportError:\n from b import f",
"date_created": "2012-11-01T12:11:11Z"
},
{
"owner": "saperski",
"content": "I think I have a fix for this problem for a slightly different fork of pyflakes here: https://github.com/kevinw/pyflakes/pull/28",
"date_created": "2013-01-06T02:19:26Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/800691",
"date_created": "2011-06-22T13:22:56Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Code from: http://docs.python.org/library/functions.html#property\n\n-------------------------------------- foo.py\n\nclass C(object):\n\u00a0\u00a0\u00a0\u00a0def __init__(self):\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0self._x = None\n\n\u00a0\u00a0\u00a0\u00a0@property\n\u00a0\u00a0\u00a0\u00a0def x(self):\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"\"\"I'm the 'x' property.\"\"\"\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return self._x\n\n\u00a0\u00a0\u00a0\u00a0@x.setter\n\u00a0\u00a0\u00a0\u00a0def x(self, value):\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0self._x = value\n\n\u00a0\u00a0\u00a0\u00a0@x.deleter\n\u00a0\u00a0\u00a0\u00a0def x(self):\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0del self._x\n\n---------------------------------------------\n\npyflakes output is\n\n$ pyflakes foo.py\nfoo.py:11: redefinition of function 'x' from line 6\nfoo.py:15: redefinition of function 'x' from line 11",
"tags": [
"decorator",
"property",
"redefinition"
],
"duplicates": [],
"assignee": null,
"milestone": "0.6.1",
"owner": "cassapanco",
"id": 812958,
"duplicate_of": null,
"title": "property decorator -> redefinition of function",
"comments": [
{
"owner": "kamil.paral",
"content": "I can confirm this problem.",
"date_created": "2012-02-08T09:23:17Z"
},
{
"owner": "kisielk",
"content": "There's a patch in a pending pull request on the kevinw/pyflakes fork on github that addresses this issue:\n\nhttps://github.com/ervandew/pyflakes/commit/b971f2775500b4154619dc5d71ba77fc7e4efdf6",
"date_created": "2012-02-21T00:07:09Z"
},
{
"owner": "exarkun",
"content": "The feature seems questionable to me. However, it would be easier to evaluate the implementation if there were unit tests for the change.\n",
"date_created": "2012-02-21T13:56:06Z"
},
{
"owner": "glyph",
"content": "It looks like this was fixed - inadvertently perhaps? - by <http://bazaar.launchpad.net/~divmod-dev/divmod.org/trunk/revision/2685>.",
"date_created": "2012-03-31T22:23:53Z"
},
{
"owner": "mestrelion",
"content": "Any news on when this fix will be released in Ubuntu?",
"date_created": "2012-11-22T06:31:17Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/812958",
"date_created": "2011-07-19T15:21:19Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "If you have a Python program like this:\n\nclass Foo: pass\nclass Foo: pass\n\nPyflakes won't emit a warning, but it should.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.6.1",
"owner": "glyph",
"id": 823369,
"duplicate_of": null,
"title": "no warning for duplicate classes",
"comments": [
{
"owner": "hjd",
"content": "Confirmed. Pyflakes 0.5.0 prints no warning on a file containing your example.\r\n\r\nPylint warns about the duplicate class though.",
"date_created": "2012-12-30T20:00:28Z"
},
{
"owner": "florent.x",
"content": "Fixed in trunk.\nhttp://bazaar.launchpad.net/~divmod-dev/divmod.org/trunk/revision/2685",
"date_created": "2013-01-08T10:51:23Z"
},
{
"owner": "florent.x",
"content": "Of course I linked the old repository...\n\nThe current one is:\nhttp://bazaar.launchpad.net/~divmod-dev/pyflakes/trunk/revision/42",
"date_created": "2013-01-08T11:22:12Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/823369",
"date_created": "2011-08-09T15:52:08Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "With the attached example file, pyflakes reports\n\npf.py:6: redefinition of unused 'connect' from line 3\npf.py:6: redefinition of unused 'PARSE_DECLTYPES' from line 3\npf.py:6: redefinition of unused 'PARSE_COLNAMES' from line 3\n\nThey're not redefinitions, but fallbacks in case defining them the first time fails. I don't know if there's a way to catch this, but it's worth noting.",
"tags": [
"except",
"import",
"redefinition",
"try"
],
"duplicates": [
1035108
],
"assignee": "florent.x",
"milestone": "0.6.1",
"owner": "4-launchpad-tim-thechases-com",
"id": 916264,
"duplicate_of": null,
"title": "Cascading try/except imports report duplicates",
"comments": [
{
"owner": "4-launchpad-tim-thechases-com",
"content": "",
"date_created": "2012-01-13T22:05:38Z"
},
{
"owner": "adiroiban",
"content": "This is on the TODO list: pyflakes.test.test_imports.Test.test_tryingMultipleImports",
"date_created": "2012-04-30T15:41:39Z"
},
{
"owner": "fpinard",
"content": "The same duplication warning occurs if one assigns the import name, like in:\n\ntry:\n import signal\nexcept ImportError:\n signal = None\n\nThis code comes from a program which sometimes runs under Jython, so it could quickly test if \"signal\" was available.\n\nFran\u00e7ois",
"date_created": "2012-06-10T10:49:24Z"
},
{
"owner": "saperski",
"content": "I think I have a fix for this problem for a slightly different fork of pyflakes here: https://github.com/kevinw/pyflakes/pull/28\n\n",
"date_created": "2013-01-06T02:19:08Z"
},
{
"owner": "zbyszek-in",
"content": "Tested this on multi-import from http://lxml.de/tutorial.html and it seems to work well.\n\nOTOH, stuff like:\nchoice = sys.getenv('CHOICE')\nif choice == 'A':\n import A as backend\n\nif choice == 'B':\n import B as backend\n\ndon't work, as expected.\n",
"date_created": "2013-01-08T19:17:47Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/916264",
"date_created": "2012-01-13T22:05:38Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "A user came into the #vim channel on IRC looking for help with the pyflakes plugin. I tracked down the error to a bug(?) in pyflakes: it doesn't work in a Turkish locale. Instead you get\n\nAttributeError: 'Checker' object has no attribute 'ATTRiBUTE'\n\nScreenshot of the original error: http://i.imgur.com/gAfRB.png\n\nThe user's locale:\nLANG=tr_TR.UTF-8\nLANGUAGE=\nLC_CTYPE=\"tr_TR.UTF-8\"\nLC_NUMERIC=\"tr_TR.UTF-8\"\nLC_TIME=\"tr_TR.UTF-8\"\nLC_COLLATE=\"tr_TR.UTF-8\"\nLC_MONETARY=\"tr_TR.UTF-8\"\nLC_MESSAGES=\"tr_TR.UTF-8\"\nLC_PAPER=\"tr_TR.UTF-8\"\nLC_NAME=\"tr_TR.UTF-8\"\nLC_ADDRESS=\"tr_TR.UTF-8\"\nLC_TELEPHONE=\"tr_TR.UTF-8\"\nLC_MEASUREMENT=\"tr_TR.UTF-8\"\nLC_IDENTIFICATION=\"tr_TR.UTF-8\"\nLC_ALL=\n\nThis workaround fixed the error for that user:\n\n<mgedmin> edit that pyflakes/checker.py file, find line 317 (actual number might differ depending on the version) -- the line that does 'nodeType = node.__class__.__name__.upper()'\n<mgedmin> change it to 'nodeType = node.__class__.__name__.upper().replace(\"i\", \"I\")'",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7",
"owner": "mgedmin",
"id": 942603,
"duplicate_of": null,
"title": "AttributeError in a Turkish locale",
"comments": [
{
"owner": "orc-avs",
"content": "That bothered me, too. This happens resulting from a well-known problem for Turkish locale. Lower 'i' stays as 'i' on upper() function, so 'assign' becomes 'ASSiGN' instead of 'ASSIGN' and that causes further error when getattr(node, 'ASSiGN') is called. I don't know what upper() is used for. But you should either accept this workaround or use locale.setlocale(locale.LC_ALL, 'en_US.UTF-8') at the top of the code somewhere as upper() and lower() functions are locale-dependent.",
"date_created": "2012-11-18T13:12:27Z"
},
{
"owner": "florent.x",
"content": "Committed on trunk, rev 77",
"date_created": "2013-03-30T17:59:17Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/942603",
"date_created": "2012-02-28T13:28:30Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Hello,\nI'm reporting http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674797:\n\n>>>\nIf the tested file contains invalid \\x escape, pyflakes fails with traceback:\n\n$ pyflakes test.py\nTraceback (most recent call last):\n File \"/usr/bin/pyflakes\", line 5, in <module>\n sys.exit(main(sys.argv[1:]))\n File \"/usr/lib/pymodules/python2.7/pyflakes/scripts/pyflakes.py\", line 92, in main\n warnings += checkPath(arg)\n File \"/usr/lib/pymodules/python2.7/pyflakes/scripts/pyflakes.py\", line 74, in checkPath\n return check(fd.read(), filename)\n File \"/usr/lib/pymodules/python2.7/pyflakes/scripts/pyflakes.py\", line 28, in check\n tree = compile(codeString, filename, \"exec\", _ast.PyCF_ONLY_AST)\nValueError: invalid \\x escape\n<<<\n\nwith test.py being:\n\n>>>\nfoo = '\\xyz'\n<<<\n\nRegards,\nSandro",
"tags": [],
"duplicates": [],
"assignee": "florent.x",
"milestone": "0.6.1",
"owner": "morph-debian",
"id": 1005602,
"duplicate_of": null,
"title": "ValueError: invalid \\x escape",
"comments": [],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1005602",
"date_created": "2012-05-28T17:21:16Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Hello,\nI'm reporting http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674796:\n\n>>>\n\nIf the tested file contains null bytes, pyflakes fails with traceback:\n\n$ pyflakes test.py\nTraceback (most recent call last):\n File \"/usr/bin/pyflakes\", line 5, in <module>\n sys.exit(main(sys.argv[1:]))\n File \"/usr/lib/pymodules/python2.7/pyflakes/scripts/pyflakes.py\", line 92, in main\n warnings += checkPath(arg)\n File \"/usr/lib/pymodules/python2.7/pyflakes/scripts/pyflakes.py\", line 74, in checkPath\n return check(fd.read(), filename)\n File \"/usr/lib/pymodules/python2.7/pyflakes/scripts/pyflakes.py\", line 28, in check\n tree = compile(codeString, filename, \"exec\", _ast.PyCF_ONLY_AST)\nTypeError: compile() expected string without null bytes\n<<<\n\nAttached the test file.\n\nRegards,\nSandro",
"tags": [],
"duplicates": [],
"assignee": "florent.x",
"milestone": "0.6.1",
"owner": "morph-debian",
"id": 1005603,
"duplicate_of": null,
"title": "TypeError: compile() expected string without null bytes",
"comments": [
{
"owner": "morph-debian",
"content": "",
"date_created": "2012-05-28T17:23:07Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1005603",
"date_created": "2012-05-28T17:23:07Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "The setup.py could optionally use distribute/setuptools if it is available in the path.\n\nThe library distribute (or setuptools) is very common in the Python ecosystem, and many tools depend on them, like \"pip install\", \"virtualenv\", \"zc.buildout\", ...\nOf course there's some criticism about these tools, but they exist, they are compatible, and they work fine for a lot of developers.\nThey fill a use case as explained below.\n\nThe benefit of using distribute/setuptools is the additional verbs which are available, like:\n\n $ python setup.py test\n\nThis allows to run the tests, and it takes care of installing the 'test_requires' dependencies without other action. Anyone can run the tests without any assumption about the test framework, and without digging through the source code to know which libraries are required (nose, py.test, twisted.trial, unittest, etc...).\nThis particular use case is not supported by the distutils library.\n\nAnother verb which is widely used but not supported by distutils:\n\n $ python setup.py develop\n\n\nAnd the best is that it is fully optional.\nWhen the distribute/setuptools package is not installed, it imports 'setup' from distutils and it behaves exactly the same as before.\n\nFor the record, there are some users which already suggested this change: https://github.com/kevinw/pyflakes/pull/19",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.6.1",
"owner": "florent.x",
"id": 1097379,
"duplicate_of": null,
"title": "support \"setup.py test\" and \"setup.py develop\"",
"comments": [],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1097379",
"date_created": "2013-01-08T18:09:22Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "The example below reports incorrectly \"undefined name in __all__\"\n\n try:\n from _codecs import *\n except ImportError as why:\n raise SystemError('Failed to load the builtin codecs: %s' % why)\n\n __all__ = [\"register\", \"lookup\", \"register_error\", \"lookup_error\"]\n\nThe \"import *\" should disable the reporting of undefined name, here.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.6.1",
"owner": "florent.x",
"id": 1106832,
"duplicate_of": null,
"title": "false report of undefined name in __all__ when import * is used",
"comments": [
{
"owner": "florent.x",
"content": "The feature about \"undefined name in __all__\" was added here:\n\nhttp://bazaar.launchpad.net/~divmod-dev/divmod.org/pyflakes-all-2826/revision/2614/Pyflakes/pyflakes/checker.py",
"date_created": "2013-01-27T12:13:43Z"
},
{
"owner": "florent.x",
"content": "Fixed in r59.1.3 and merged with revision 60",
"date_created": "2013-01-27T16:55:25Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1106832",
"date_created": "2013-01-27T11:27:31Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "This would be useful for projects using gettext, that add '_' as a built-in (for example).\n\nWorkaround in flake8:\nhttps://bitbucket.org/tarek/flake8/commits/b8fe4f73e6c3e875107640e6d26f19c2c7462b42\n\nWorkaround in Ninja-IDE:\nhttps://github.com/ninja-ide/ninja-ide/issues/1087#issuecomment-12767381",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.6.1",
"owner": "florent.x",
"id": 1107587,
"duplicate_of": null,
"title": "Support additional built-ins",
"comments": [],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1107587",
"date_created": "2013-01-28T07:27:24Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "bin/pyflakes is missing from the 0.7 tarball, and the test suite fails without it:\n\n$ tar xf pyflakes-0.7.tar.gz\n$ cd pyflakes-0.7\n$ python setup.py test\n[...]\n======================================================================\nFAIL: test_errors (pyflakes.test.test_api.IntegrationTests)\n----------------------------------------------------------------------\n[...]\nFirst differing element 1:\n/usr/bin/python: can't open file '/path/to/pyflakes-0.7/pyflakes/../bin/pyflakes': [Errno 2] No such file or directory\n[...etc other failing tests due to the same error...]",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7.1",
"owner": "vskytta",
"id": 1170461,
"duplicate_of": null,
"title": "bin/pyflakes missing from 0.7 tarball",
"comments": [
{
"owner": "florent.x",
"content": "Thank you for reporting it.\r\n\r\nWeird, I don't see any change since 0.6.1 which explain this exclusion (except the upgrade of distribute on my laptop).\r\nI'll have a look.",
"date_created": "2013-04-18T21:22:44Z"
},
{
"owner": "florent.x",
"content": "I confirmed some discrepancies when the tarball is generated from distribute versus distutils.core.\r\n\r\nIt should be fixed with revision 93",
"date_created": "2013-04-21T11:11:39Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1170461",
"date_created": "2013-04-18T19:19:37Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "pyflakes.test.test_api.CheckTests.test_invalidEscape() fails with Python >=3.2.\n\n======================================================================\nFAIL: test_invalidEscape (pyflakes.test.test_api.CheckTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File \"/tmp/pyflakes-0.7.2/pyflakes/test/test_api.py\", line 395, in test_invalidEscape\n sourcePath, [decoding_error])\n File \"/tmp/pyflakes-0.7.2/pyflakes/test/test_api.py\", line 252, in assertHasErrors\n (count, err.getvalue()), (len(errorList), ''.join(errorList)))\nAssertionError: Tuples differ: (1, \"/tmp/tmprzp_3x:1: (unicod... != (1, \"/tmp/tmprzp_3x:1: (unicod...\n\nFirst differing element 1:\n/tmp/tmprzp_3x:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-1: truncated \\xXX escape\nfoo = '\\xyz'\n ^\n\n/tmp/tmprzp_3x:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \\xXX escape\nfoo = '\\xyz'\n ^\n\n\n (1,\n- \"/tmp/tmprzp_3x:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-1: truncated \\\\xXX escape\\nfoo = '\\\\xyz'\\n ^\\n\")\n? ^\n\n+ \"/tmp/tmprzp_3x:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \\\\xXX escape\\nfoo = '\\\\xyz'\\n ^\\n\")\n? ^\n\n\n----------------------------------------------------------------------\nRan 544 tests in 1.801s\n\nFAILED (failures=1, skipped=23)",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7.3",
"owner": "arfrever-fta",
"id": 1172463,
"duplicate_of": null,
"title": "test_api.CheckTests.test_invalidEscape() fails with Python >=3.2.4",
"comments": [
{
"owner": "florent.x",
"content": "Thank you for the report.\r\n\r\nHowever it works in some environments:\r\n - OS X, Python 3.2.3\r\n - Travis-CI https://travis-ci.org/pyflakes/pyflakes/builds/6597546\r\n\r\nCould you provide details to help investigate?\r\n\r\n - which OS\r\n - exact Python version which fails\r\n python -c 'import sys; print(sys.version)'\r\n - which version(s) of Python are ok\r\n - any other hint...\r\n",
"date_created": "2013-04-24T20:46:36Z"
},
{
"owner": "arfrever-fta",
"content": "It might occur only with very recent versions. Please try 3.2.4.\nI tested with both 3.2.4 and 3.3.1+ (a snapshot from between 3.3.1 and 3.3.2) on Gentoo GNU/Linux.\nAll tests pass with Python 2.6.8, 2.7.4+ and 3.1.5",
"date_created": "2013-04-24T20:58:34Z"
},
{
"owner": "arfrever-fta",
"content": "This bug also occurs in pyflakes-0.6.1.\nPreviously I tested pyflakes-0.6.1 on 2013-01-29 and then test suite passed with some snapshot of Python 3.2 from january.",
"date_created": "2013-04-24T21:01:20Z"
},
{
"owner": "florent.x",
"content": "Now I can confirm the issue with Python 3.3.1\r\nThe test suite should be updated to accommodate this change.\r\n\r\n$ python -c 'import sys; print(sys.version)'\r\n3.3.1 (default, Apr 21 2013, 17:17:19) \r\n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]\r\n\r\nPython 3.3.0 and Python 3.2.3 are not affected.",
"date_created": "2013-04-24T21:25:21Z"
},
{
"owner": "johneed",
"content": "It occurs in 3.2.4, I just ran it.",
"date_created": "2013-05-31T06:16:28Z"
},
{
"owner": "florent.x",
"content": "It should be fixed in trunk",
"date_created": "2013-06-15T12:13:01Z"
},
{
"owner": "arfrever-fta",
"content": "I confirm that revision 0c4405d946c6c1be9be3e3a52191ab23968d1244 fixed this bug.",
"date_created": "2013-06-15T15:34:49Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1172463",
"date_created": "2013-04-24T20:23:26Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Example file:\n\ndef func():\n \"\"\"\n A docstring\n >>> func()\n 1\n >>> _\n 1\n \"\"\"\n return 1\n\n\npyflakes reports\n\ntest.py:6: undefined name '_'\n\nBut _ is a valid variable name in doctests (python -m doctest test.py passes)",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "asmeurer",
"id": 1178096,
"duplicate_of": null,
"title": "_ is a valid variable name in doctests",
"comments": [
{
"owner": "asmeurer",
"content": "Just glancing at the code, I think it's easy to fix. How do you send patches using Launchpad?",
"date_created": "2013-05-09T23:58:02Z"
},
{
"owner": "florent.x",
"content": "thank you for the bug report.\n\nYou can propose a patch either on Launchpad or GitHub.\n\nLaunchpad way:\n * clone the repository\n : bzr branch lp:pyflakes pyflakes_fix\n * commit the fix\n : bzr commit -m \"_ is a variable name in doctests\" --fixes lp:1178096\n * publish the branch\n : bzr push lp:~asmeurer/pyflakes/1178096-underscore\n * visit the Launchpad website, view the new branch and click \"propose for merging\"\n https://code.launchpad.net/pyflakes\n",
"date_created": "2013-05-10T07:49:36Z"
},
{
"owner": "asmeurer",
"content": "Oh I didn't realize you were on github. I would have just done that in the first place if I knew. ",
"date_created": "2013-05-10T16:12:51Z"
},
{
"owner": "asmeurer",
"content": "OK, on further inspection, this isn't as easy to fix as I thought, or at least not if I want to fix it right. \n\nMy plan was to just add _ to the list of defined names when in a doctest. But that's not entirely correct. It is defined only if a previous statement had a result. So for example, _ won't be defined if it's in the first line of the doctest. It also won't be defined if all the executions were assignments or function definitions. Is there a nice way to check this in the ast, or do I just need to enumerate all the cases?\n\nBy the way, would you actually prefer a patch on GitHub or here on Launchpad. GitHub is way easier for me, because I know git and am used to the pull request interface (and it's IMO better anyway), but I'll do it here on Launchpad if that's easier for you (assuming I can figure it out).",
"date_created": "2013-05-10T18:20:21Z"
},
{
"owner": "florent.x",
"content": "The issue reported here is fixed in trunk.\r\n\r\nActually _ is only defined after the first statement which returns a value not equal to None, as explained by ameurer in the previous comment.\r\n\r\nHowever, the static analysis provided by the AST is not able to detect such condition.\r\n\r\nWe prefer to avoid false-positives here.",
"date_created": "2014-03-22T16:03:04Z"
},
{
"owner": "asmeurer",
"content": "Hmm, actually, playing around with it, it looks like the doctest runner *always* defines _. If nothing has been evaluated yet, it is set to None (this is unlike the interactive Python session where the behavior you described takes place).",
"date_created": "2014-03-22T16:19:39Z"
},
{
"owner": "florent.x",
"content": "So the fix is better than I thought.\n\nThank you for this update.",
"date_created": "2014-03-22T16:38:39Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1178096",
"date_created": "2013-05-09T05:45:48Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Pyflakes reports \"undefined name A\" on the third line of this code:\n\nclass C(object):\n A = [1, 2, 3]\n B = dict((i, str(i)) for i in A)\n\nThis construction works in every version of Python since at least 2.5. (real-world use case from which this was extracted: https://github.com/facebook/tornado/blob/master/tornado/options.py#L444)",
"tags": [],
"duplicates": [
1190075
],
"assignee": null,
"milestone": "0.7.3",
"owner": "ben-darnell",
"id": 1184732,
"duplicate_of": null,
"title": "False positive on comprehensions in class scope",
"comments": [
{
"owner": "asmeurer",
"content": "Changing the except clause at line 444 to also catch ClassScope fixes it, i.e.,\n\ndiff --git a/pyflakes/checker.py b/pyflakes/checker.py\nindex ed9381e..6ed7f9c 100644\n--- a/pyflakes/checker.py\n+++ b/pyflakes/checker.py\n@@ -441,7 +441,7 @@ class Checker(object):\n importStarred = self.scope.importStarred\n for scope in self.scopeStack[-2:0:-1]:\n importStarred = importStarred or scope.importStarred\n- if not isinstance(scope, FunctionScope):\n+ if not isinstance(scope, (FunctionScope, ClassScope)):\n continue\n try:\n scope[name].used = (self.scope, node)\n\nBut I'm not sure what the implications of this change are. It seems to lead to some test failures (which I cannot understand how to read).",
"date_created": "2013-05-27T21:08:12Z"
},
{
"owner": "florent.x",
"content": "Another test case from issue #1190075 (marked duplicate)\n\nclass A:\n T = range(10)\n\n X = {x for x in T}\n Y = {x:x for x in T}\n Z = (x for x in T)\n L = [x for x in T]\n\nI tried the patch proposed by @asmeurer and it fixes the issue.\nHowever it gives a failure in another part of the test suite. Under investigation...",
"date_created": "2013-06-15T10:38:57Z"
},
{
"owner": "florent.x",
"content": "Patch attached.",
"date_created": "2013-06-15T12:05:37Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1184732",
"date_created": "2013-05-27T19:38:03Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "It would be nice if you could tag releases in git. It's useful if you want to build releases from git.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7.3",
"owner": "dwnarvaez",
"id": 1198323,
"duplicate_of": null,
"title": "Tag 0.7.3 in git",
"comments": [
{
"owner": "florent.x",
"content": "Done.\r\n\r\nThank you.",
"date_created": "2014-01-17T10:00:02Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1198323",
"date_created": "2013-07-05T20:34:29Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "for i in range(i):\n print i\n\nPyflakes doesn't report any errors here, even though the i in range(i) is undefined. If I change the loop variable to j, it reports it as undefined.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8.1",
"owner": "asmeurer",
"id": 1205907,
"duplicate_of": null,
"title": "Undefined variable in for loop not caught",
"comments": [
{
"owner": "florent.x",
"content": "Thank you for reporting this issue.\r\nIt's fixed in trunk (planned for 0.8.1)\r\n\r\nhttps://github.com/pyflakes/pyflakes/commit/3d54e69e337481970faac3eae60ef35f4cfc6719",
"date_created": "2014-03-29T22:37:44Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1205907",
"date_created": "2013-07-28T19:50:20Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Compare these outputs\n\n$pyflakes test.py\ntest.py:6: invalid syntax\n print 1\n ^\n\n$python test.py\n File \"test.py\", line 6\n print 1\n ^\nSyntaxError: invalid syntax\n\nPython correctly puts the caret under the 1. Pyflakes puts it one character past the 1",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "asmeurer",
"id": 1249873,
"duplicate_of": null,
"title": "Wrong caret position on syntax error",
"comments": [
{
"owner": "asmeurer",
"content": "Fixed at https://github.com/pyflakes/pyflakes/pull/15",
"date_created": "2013-11-13T01:34:25Z"
},
{
"owner": "florent.x",
"content": "Thank you for the report. This is fixed in trunk on Github.",
"date_created": "2014-01-17T09:09:51Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1249873",
"date_created": "2013-11-11T01:11:33Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Sample code:\n\n__all__ = ('urlparse',)\nfrom urlparse import urlparse\n\nOutput:\n\nF401: 'urlparse' imported but unused\n\nExpected:\n\nNo error, because 'urlparse' is used - it is intentionally imported for providing out to other packages. These intentions should be obvious from __all__.\n\nNote:\n\nActually I am using https://github.com/dreadatour/Flake8Lint, but I guess this warning comes from PyFlakes originally. Please correct me if I am wrong.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "honzajavorek",
"id": 1266446,
"duplicate_of": null,
"title": "F401 imported but unused shouldn't appear if the token is mentioned in __all__",
"comments": [
{
"owner": "icordasc",
"content": "That error is entirely correct as best as I can tell. The way I do what you're trying to is:\n\nfrom urlparse import urlparse\n\n__all__ = (urlparse,)\n\nIn other words, I use the function object itself, not a string to represent it.",
"date_created": "2014-01-06T13:48:03Z"
},
{
"owner": "florent.x",
"content": "Actually the issue is that Pyflakes expects a List in \"__all__\" , not a Tuple.\r\nThe documentation allows both Tuple or List, however it is almost always a List.\r\n\r\nProbably I will patch the code to accept Tuple as well.\r\n\r\nPS: Ian, you should re-read the documentation for __all__, it expects a list of names, not a list of objects ;) ",
"date_created": "2014-01-17T09:32:40Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1266446",
"date_created": "2014-01-06T12:11:22Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "pyflakes appears to get confused when a method named 'foo' has default args that refer to a module named 'foo'. Example:\n\n$ cat bad-unused-import.py\nimport foo\n\nclass Thing(object):\n def foo(self, parser=foo.parse_foo):\n pass\n\n$ pyflakes bad-unused-import.py\nbad-unused-import.py:1: 'foo' imported but unused\n\nI'm positive this is valid Python, because 'foo' the method isn't in scope yet when processing those default args. So 'foo.parse_foo' refers to something in the 'foo' module, as intended. So the module 'foo' really is being used here!\n\nThere's an easy workaround: \"import foo as foo_\". But that's yucky. It would be nice if pyflakes accepted this code as it stands.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8.1",
"owner": "gward",
"id": 1270952,
"duplicate_of": null,
"title": "spurious \"imported but unused\" when method name shadows module name",
"comments": [
{
"owner": "florent.x",
"content": "Thank you for this report.\r\n\r\nIt's fixed in trunk\r\n\r\nhttps://github.com/pyflakes/pyflakes/commit/20c7c950a79f24ad53cfc874689e32b903493f36",
"date_created": "2014-03-30T02:55:29Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1270952",
"date_created": "2014-01-20T21:29:48Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "This is on pyflakes==0.7.3 in python 2.6\n\n```\nTraceback (most recent call last):\n File \"/Users/peterbe/virtualenvs/socorro/bin/pyflakes\", line 9, in <module>\n load_entry_point('pyflakes==0.7.3', 'console_scripts', 'pyflakes')()\n File \"/Users/peterbe/virtualenvs/socorro/lib/python2.6/site-packages/pyflakes/api.py\", line 128, in main\n warnings = checkRecursive(args, reporter)\n File \"/Users/peterbe/virtualenvs/socorro/lib/python2.6/site-packages/pyflakes/api.py\", line 119, in checkRecursive\n warnings += checkPath(sourcePath, reporter)\n File \"/Users/peterbe/virtualenvs/socorro/lib/python2.6/site-packages/pyflakes/api.py\", line 86, in checkPath\n return check(codestr, filename, reporter)\n File \"/Users/peterbe/virtualenvs/socorro/lib/python2.6/site-packages/pyflakes/api.py\", line 58, in check\n w = checker.Checker(tree, filename)\n File \"/Users/peterbe/virtualenvs/socorro/lib/python2.6/site-packages/pyflakes/checker.py\", line 253, in __init__\n self.handleChildren(tree)\n File \"/Users/peterbe/virtualenvs/socorro/lib/python2.6/site-packages/pyflakes/checker.py\", line 520, in handleChildren\n self.handleNode(node, tree)\n File \"/Users/peterbe/virtualenvs/socorro/lib/python2.6/site-packages/pyflakes/checker.py\", line 555, in handleNode\n handler(node)\n File \"/Users/peterbe/virtualenvs/socorro/lib/python2.6/site-packages/pyflakes/checker.py\", line 779, in CLASSDEF\n for keywordNode in node.keywords:\nAttributeError: 'ClassDef' object has no attribute 'keywords'\n```\n\nI was going to include a file that it happens on but I noticed it happens on EVERY file. Is it simply a matter of breakage in python 2.6?",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "mail-peterbe",
"id": 1277606,
"duplicate_of": null,
"title": "AttributeError: 'ClassDef' object has no attribute 'keywords'",
"comments": [
{
"owner": "mail-peterbe",
"content": "I tried the same file using the same pyflakes==0.7.3 in a python 2.7 virtualenv and no errors. (Well, no exceptions that is)",
"date_created": "2014-02-07T17:07:47Z"
},
{
"owner": "alejandrosantana",
"content": "I have this same warning, but only if pyflakes find no error in the source code.\n Python 2.7 (no virtualenv), also installed Python 3\n SO: Kubuntu 13.10\n Name: pyflakes\n Version: 0.7.3\n Location: /usr/local/lib/python2.7/dist-packages\n\nThe error message:\n\nTraceback (most recent call last):\n File \"/usr/local/bin/pyflakes\", line 9, in <module>\n load_entry_point('pyflakes==0.7.3', 'console_scripts', 'pyflakes')()\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/api.py\", line 128, in main\n warnings = checkRecursive(args, reporter)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/api.py\", line 119, in checkRecursive\n warnings += checkPath(sourcePath, reporter)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/api.py\", line 86, in checkPath\n return check(codestr, filename, reporter)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/api.py\", line 58, in check\n w = checker.Checker(tree, filename)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/checker.py\", line 253, in __init__\n self.handleChildren(tree)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/checker.py\", line 520, in handleChildren\n self.handleNode(node, tree)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/checker.py\", line 555, in handleNode\n handler(node)\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/checker.py\", line 779, in CLASSDEF\n for keywordNode in node.keywords:\nAttributeError: 'ClassDef' object has no attribute 'keywords'",
"date_created": "2014-02-17T04:11:53Z"
},
{
"owner": "stefan-tjarks",
"content": "Got the same error in one of my virtual envs. Turned out that for some reason pyflakes thinks it is running not PY2.\nI changed\n\ntry:\n builtin_vars = dir(__import__('builtins'))\n PY2 = False\nexcept ImportError:\n builtin_vars = dir(__import__('__builtin__'))\n PY2 = True\n\nwith\n\n builtin_vars = dir(__import__('__builtin__'))\n PY2 = True\n\nin pyflakes/checker.py and that fixed it. Guess some other third party library is messing around with 'builtins' but did not really dig into that.",
"date_created": "2014-03-12T23:18:34Z"
},
{
"owner": "matthew-russell",
"content": "On my machine I get the same error.\nIt's due to the following file being present:\n\n~/.local/lib/python2.7/site-packages/builtins.py\n\nSearches:\n$ find ~/.local/lib/python2.7/site-packages/ -type f -exec grep -Hn builtins.py {} \\;\n/home/matthew/.local/lib/python2.7/site-packages/pies2overrides-2.6.1-py2.7.egg-info/SOURCES.txt:2:builtins.py\n/home/matthew/.local/lib/python2.7/site-packages/pies2overrides-2.6.1-py2.7.egg-info/installed-files.txt:2:../builtins.py\n/home/matthew/.local/lib/python2.7/site-packages/pies2overrides-2.6.1-py2.7.egg-info/installed-files.txt:19:../builtins.pyc\n\n$ find /home/matthew/.local/lib/python2.7/site-packages/ -type f -name requires.txt -exec grep -Hn pies {} \\;\n/home/matthew/.local/lib/python2.7/site-packages/pies-2.6.1-py2.7.egg-info/requires.txt:1:pies2overrides\n/home/matthew/.local/lib/python2.7/site-packages/isort-3.6.2-py2.7.egg-info/requires.txt:1:pies>=2.6.0\n\n$ find /home/matthew/.local/lib/python2.7/site-packages/ -type f -name requires.txt -exec grep -Hn pies {} \\;\n/home/matthew/.local/lib/python2.7/site-packages/pies-2.6.1-py2.7.egg-info/requires.txt:1:pies2overrides\n/home/matthew/.local/lib/python2.7/site-packages/isort-3.6.2-py2.7.egg-info/requires.txt:1:pies>=2.6.0\n\n\nThis has the sole line:\n\nfrom __builtins__ import *\n\nThe offending module on my system is isort.\n\nIn #3 Stefan shows the call site in pyflakes where this is a problem.\nPersonally I think isort is using the above to try and bridge the 2/3 divide,\nbut should probably add a compat module.\n\npyflakes should use:\nPY2 = sys.version.starswith('2') or similar.\n\nWill raise a bug in both projects.\n",
"date_created": "2014-03-15T18:32:51Z"
},
{
"owner": "matthew-russell",
"content": "Should clarify that it is the 'pies' package that has the from __builtins__ import * stuff, not isort.",
"date_created": "2014-03-15T18:51:33Z"
},
{
"owner": "matthew-russell",
"content": "hmm, on relection, I don't think pies can be blamed really since it is a compatibility library after all (should of checked first).\n ",
"date_created": "2014-03-15T19:00:19Z"
},
{
"owner": "florent.x",
"content": "The Python version detection is more robust in trunk.",
"date_created": "2014-03-22T16:28:54Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1277606",
"date_created": "2014-02-07T17:06:06Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Please see:\nhttps://bugs.launchpad.net/pyflakes/+bug/1277606/comments/4\n\nI think pyflakes could use:\n\nPY2 = sys.version.startswith('2')\n\ninstead of the try/except in checker.py ?",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "matthew-russell",
"id": 1292942,
"duplicate_of": null,
"title": "Don't rely on builtins to determine python version?",
"comments": [
{
"owner": "florent.x",
"content": "Fixed in trunk, thank you",
"date_created": "2014-03-22T16:32:39Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1292942",
"date_created": "2014-03-15T18:35:28Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "When doing work for oslo.messaging project, I've found behaviour that seems like a bug. You can find the code that triggered it at: https://github.com/booxter/oslo.messaging/tree/self-config-with-fixture\n\nWhen I run 'tox -e pep8' for the project with my patch applied (HEAD of the branch), I get the following:\n\n[ihrachys@dhcp130-159 oslo.messaging]$ tox -e pep8\nGLOB sdist-make: /home/ihrachys/proj/oslo.messaging/setup.py\npep8 inst-nodeps: /home/ihrachys/proj/oslo.messaging/.tox/dist/oslo.messaging-1.3.0a9.16.g7944d9d.zip\npep8 runtests: commands[0] | flake8\n./tests/test_transport.py:147:1: F811 redefinition of unused 'transport' from line 24\n transport = messaging.get_transport(self.conf, **kwargs)\n^\nERROR: InvocationError: '/home/ihrachys/proj/oslo.messaging/.tox/pep8/bin/flake8'\n__________________________________________________________________ summary __________________________________________________________________\nERROR: pep8: commands failed\n\nIt seems that pyflakes checker parses the file from top to bottom, checking possible violations in sequence. So it locates this new local variable 'transport' definition, and checks thru the list of globals where there is an import with the same name. The problem occurs because transport import is not used in this file BEFORE the variable definition, while it's still used AFTER it, in other classes. I guess the check should be triggered only if the import in question is never used anywhere else in the file, no matter where the usage is located in regards to redefinition.\n\nThe code in question is in checker.py, addBinding():\n...\n if (isinstance(existing, Importation)\n and not existing.used\n and (not isinstance(value, Importation) or\n value.fullName == existing.fullName)\n and reportRedef\n and not self.differentForks(node, existing.source)):\n...",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8.1",
"owner": "ihar-hrachyshka",
"id": 1297161,
"duplicate_of": null,
"title": "F811 incorrectly triggered",
"comments": [
{
"owner": "florent.x",
"content": "Thank you for this report.\r\n\r\nThe patch is commited, and it will be in 0.8.1\r\nhttps://github.com/pyflakes/pyflakes/commit/ffe926c282bf78737f8c34dff111ccbdab6c837b",
"date_created": "2014-03-29T22:40:50Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1297161",
"date_created": "2014-03-25T09:41:46Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "I hit a bug while building a package in an Ubuntu Trusty chroot. One of the tests this package does is run pyflakes3 over its source code to ensure that its clean. A couple of the files have a non-ascii character in its comment block, e.g.:\n\nhttp://bazaar.launchpad.net/~gdebi-developers/gdebi/trunk/view/head:/GDebi/GDebiKDE.py\n\npyflakes opens its files with the default encoding, technically locale.getpreferredencoding() in Python 3. It does not specify an explicit encoding argument to its open() call.\n\nIn Python 3, the preferred encoding is taken from the locale settings, and in a chroot, the default local is POSIX, a.k.a. C, which causes locale.getpreferredencoding() to return ANSI_X3.4-1968, a.k.a. us-ascii. So it makes sense that the f.read() call tracebacks when it tries to decode the non-ascii character in the comment block using the ascii encoding. And this is exactly what happens.\n\nThis is despite the explicit encoding specification in the GDebiKDE.py file:\n\n# -*- coding: utf-8 -*-\n\nWe have a few options to work around this. We could force a UTF-8 encoding (e.g. us_en.UTF-8) in the build environment, which would force locale.getpreferredencoding() to 'utf-8'. Or we could skip the pyflakes3 test if the encoding doesn't have UTF-8.\n\nBut I think the right solution is for pyflakes to open the files with the proper explicit encoding. It should probably open the file in binary mode, read a few lines to see if there's a `coding` declaration, and then if so, re-open the file in text mode with the proper encoding. Alternatively, read the entire file in binary mode and explicitly decode it after grokking if there's any explicit encoding declared.\n\nI vaguely recall some related discussion about this in python-dev, but I could be misremembering that.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8.1",
"owner": "barry",
"id": 1299169,
"duplicate_of": null,
"title": "pyflakes3 ignores file encoding",
"comments": [
{
"owner": "florent.x",
"content": "I confirm the issue. I plan to fix it in the next release (the correct behaviour is already implemented in the pep8 tool).\r\n\r\nIn the meantime, another easy workaround is to install flake8.\r\n\r\n pip install -U flake8\r\n flake8 --select F your_project\r\n\r\nIt should do the right thing.",
"date_created": "2014-03-28T19:45:54Z"
},
{
"owner": "florent.x",
"content": "Steps to reproduce:\n\n$ LANG= python3 -m pyflakes /tmp/GDebiKDE.py \n/tmp/GDebiKDE.py: problem decoding source\n\nor\n\n$ LANG= pyflakes3 /tmp/GDebiKDE.py \n/tmp/GDebiKDE.py: problem decoding source",
"date_created": "2014-03-29T10:05:32Z"
},
{
"owner": "florent.x",
"content": "Fixed in trunk : only read bytes and delegate the decoding to the built-in compile(...)\r\n\r\nhttps://github.com/pyflakes/pyflakes/compare/7b85f86578...12b4d425e3",
"date_created": "2014-03-29T11:16:08Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1299169",
"date_created": "2014-03-28T19:17:50Z"
},
{
"status": "Confirmed",
"security_related": false,
"description": "Hi,\nAs far as I know, bug #872503 was meant to fix the issue of code using locals() not being recognized as using local variables and indeed the code\n\n# No warning\ndef test():\n a = 5\n return locals()\n\ndoes not raise any warnings, but I've noticed that using locals() in the context of a comprehension (except a list comprehension) will incorrectly make pyflakes assume that the locals are not being used.\n\nUsing code as an example,\n\n# No warning\ndef test():\n a = 5\n return [i for i in locals().values()]\n\ndoes not raise a warning but the following generator expression:\n\n# local variable 'a' is assigned to but never used\ndef test():\n a = 5\n return (i for i in locals().values())\n\nset comprehension:\n\n# local variable 'a' is assigned to but never used\ndef test():\n a = 5\n return {i for i in locals().values()}\n\nand dict comprehension:\n\n# local variable 'a' is assigned to but never used\ndef test():\n a = 5\n return {k: v for k, v in locals().items()}\n\nall raise the unused local variable warning, which is pretty inconsistent with the previous behavior.\n\nThis is not a hugely critical bug but it's annoying and it could imply some bugs in the comprehensions elsewhere. Thanks for reading.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "fawio",
"id": 1325966,
"duplicate_of": null,
"title": "inconsistent behavior with locals(), comprehensions and the unused local variable warning",
"comments": [],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1325966",
"date_created": "2014-06-03T12:44:44Z"
},
{
"status": "Confirmed",
"security_related": false,
"description": "Importing modules using fully-qualified paths appears to confuse pyflakes. Example #1:\n\n'''\n$ cat pyflakes-missed-unused-import.py\nimport somepackage.mod1\nimport somepackage.mod2\n\ndef do_something():\n somepackage.mod1.do_something()\n\n$ pyflakes pyflakes-missed-unused-import.py\n'''\n\nExpected output: an \"unused import\" warning about somepackage.mod2.\n\nActual output: no errors or warnings.\n\nExample #2:\n\n'''\n$ cat pyflakes-missed-missing-import.py\nimport somepackage.mod2\n\ndef do_something():\n somepackage.mod1.do_something()\n\n$ pyflakes pyflakes-missed-missing-import.py\n'''\n\nExpected output: a \"missing import\" error about somepackage.mod1 *and* an \"unused import\" warning about somepackage.mod2.\n\nActual output: no errors or warnings.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "gward",
"id": 1421013,
"duplicate_of": null,
"title": "Missing import warnings when importing fully-qualified modules",
"comments": [
{
"owner": "bitglue",
"content": "Indeed, this is an issue. Fixing it will require some substantial rework of Pyflakes' data model, because currently it doesn't know anything about attributes.",
"date_created": "2015-05-27T15:32:55Z"
}
],
"importance": "Low",
"lp_url": "https://bugs.launchpad.net/bugs/1421013",
"date_created": "2015-02-11T23:55:23Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "gettext module provides convenience function gettext.install() that injects a callable _ [single underscore] into builtins, so that internationalized code can be written like this:\n\nprint _(\"text\")\n\npyflakes reports every _ as undefined symbol.\n\nmoreover since it is injected in builtins, all imported modules have that symbol, thus the following works:\n\n# main.py\nimport gettext\nimport somemod\ngettext.install(...)\n\n#somemod.py\nprint _(\"text\")\n\nI'm not sure what sort of heuristic could be used to recognize _() when pyflake checks somemod.py.\nPerhaps a command line argument for extra builtins?",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7.2",
"owner": "dimaqq",
"id": 844592,
"duplicate_of": null,
"title": "Recognize _(\"text\") from gettext.install(...)",
"comments": [
{
"owner": "exarkun",
"content": "Instead of using the injected builtins feature of gettext, import the name. Then both pyflakes and human readers of the code will know what's going on.\r\n\r\n from gettext import gettext as _\r\n",
"date_created": "2011-09-08T11:45:39Z"
},
{
"owner": "dimaqq",
"content": "I'm not the expert on gettext, but it occurs to me there could be a subtle difference.\nAt least:\n\nIn [18]: __builtins__._ == gettext.gettext\nOut[18]: False\n\nIn [19]: __builtins__._\nOut[19]: <bound method GNUTranslations.gettext of <gettext.GNUTranslations instance at 0x1661d40>>\n\nIn [20]: gettext.gettext\nOut[20]: <function gettext at 0x13df938>\n\nI get the same translations from calling either function, and the proposed workaround works for me, but it's not always the case:\n\nFrom gettext doc:\ngettext.install(domain[, localedir[, unicode[, codeset[, names]]]])\nChanged in version 2.4: Added the codeset parameter.\nChanged in version 2.5: Added the names parameter.\n\nThus if someone uses extra parameters of install, result of _() and gettext.gettext() are different:\n\nIn [34]: gettext.install(APP, DIR, unicode=True)\n\nIn [36]: __builtins__._(\"test\")\nOut[36]: u'test'\n\nIn [37]: gettext.gettext(\"test\")\nOut[37]: 'test'\n\nHere difference is unicode vs str, that is _() includes unicode=True passed in install and gettext.gettext doesn't. I suppose similar differences could arise from codeset and names parameters to install.",
"date_created": "2011-09-08T13:00:58Z"
},
{
"owner": "exarkun",
"content": "The difference isn't really relevant to Pyflakes. The example I gave was meant to be a trivial example of how you can apply the solution. If you want a different gettext function to be bound to _, you can have a different gettext function bound to _. If you want unicode, use gettext.ugettext. If you want a particular domain, use the gettext.translation function to get an instance of something for the appropriate domain and then use that object's gettext method. etc.\n",
"date_created": "2011-09-08T22:16:40Z"
},
{
"owner": "kovid",
"content": "There are plenty of situations where large projects may decide to define project wide builtins, in order to save having to explicitly import a frequently used function in every single module. Please consider adding support for a user specified list of builtin names to ignore, either via a command line argument or an environment variable. ",
"date_created": "2011-12-14T10:20:20Z"
},
{
"owner": "kovid",
"content": "And for completeness, here's a wrapper script that uses the env var PYFLAKES_BUILTINS\n\n#!/usr/bin/env python\nimport os, __builtin__\n\nnames = os.environ.get('PYFLAKES_BUILTINS', '')\nnames = [x.strip() for x in names.split(',')]\nfor x in names:\n if not hasattr(__builtin__, x):\n setattr(__builtin__, x, True)\n\ndel names, os, __builtin__\n\nfrom pyflakes.scripts.pyflakes import main\nmain()\n",
"date_created": "2011-12-14T10:47:45Z"
},
{
"owner": "florent.x",
"content": "The version 0.6.1 added a parameter to the Checker constructor.\r\nSee issue 1107587: http://launchpad.net/bugs/1107587\r\n\r\nAn environment variable might be sensible for the command line usage.",
"date_created": "2013-01-29T17:07:00Z"
},
{
"owner": "florent.x",
"content": "Added environment variable PYFLAKES_BUILTINS as suggested. See NEWS.txt",
"date_created": "2013-04-24T12:20:16Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/844592",
"date_created": "2011-09-08T08:18:12Z"
},
{
"status": "New",
"security_related": false,
"description": "It would be nice if pyflakes could detect mistakes like this:\n\n try:\n oldtime = os.path.getmtime(fname)\n except OSError, IOError:\n oldtime = 0\n\nIn the general case, it's obviously difficult to tell whether this is an error or not; but I suspect that handling the exception variable name as a binding would give you a \"redefinition of Foo\" warning in most of the cases where a mistake has been made.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "mithrandi",
"id": 848455,
"duplicate_of": null,
"title": "Detect misuse of except",
"comments": [
{
"owner": "exarkun",
"content": "Sounds reasonable. At least it would be interesting to run such a check against existing codebases to see what comes up. :)\n",
"date_created": "2011-09-13T01:07:12Z"
},
{
"owner": "yatc18ks0-9a-ngeefk4xa",
"content": "Pyflakes 0.5.0 does generate the warning \"local variable 'IOError' is assigned to but never used\", so I believe this has been fixed.",
"date_created": "2011-10-22T14:51:32Z"
},
{
"owner": "mithrandi",
"content": "You only get the unused-local-variable warning if the try/except is in a function. However, it looks like pyflakes does not warn about shadowing builtins, which I thought it did, so my analysis in the description is probably wrong.",
"date_created": "2011-10-23T16:52:38Z"
},
{
"owner": "saperski",
"content": "There is no warning as of pyflakes 0.7.3, marking as fixed",
"date_created": "2013-09-05T23:52:05Z"
},
{
"owner": "saperski",
"content": "er, sorry, misunderstood... should be reopened again",
"date_created": "2013-09-05T23:55:04Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/848455",
"date_created": "2011-09-13T00:47:11Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "An assert of the form:\n\nassert (x, 'blahblah')\n\nis tautological, because a non-empty tuple always has a truth value of True. However, it is common to mistakenly construct an assert statement of this form when attempting to wrap it over multiple lines. Python 2.6+ already issues a SyntaxWarning about this, but it would be nice if Pyflakes detected it too.",
"tags": [],
"duplicates": [
1405778
],
"assignee": null,
"milestone": null,
"owner": "mithrandi",
"id": 848467,
"duplicate_of": null,
"title": "Detect tautological asserts",
"comments": [
{
"owner": "jayvdb",
"content": "Pull request for the specific problem raised here : https://github.com/pyflakes/pyflakes/pull/51\n\nI've also quickly hacked together detection of assertion of a static value. It is just a concept demo, in case anyone thinks it could be useful. It has cross-version issues, and could easily become more complete by adding more call names.\nhttps://github.com/jayvdb/pyflakes/commit/25234773b174f0eb34fca3cd2e734290d7ab3a5e\n",
"date_created": "2015-11-20T14:16:45Z"
},
{
"owner": "jayvdb",
"content": "Expanding on my post, I'm think only `assert False` and `assert True` should be the only static asserts permitted.\n\nWhile CPython is catching only the absolute worst type of assert, pyflakes can and IMO should report other problematic asserts.\n\nafaik, there is no Python parser that does anything sensible with alternative static asserts. So anything other than `assert False` and `assert True` is obfuscated code, either unintentional or intentional, and the cost/benefit weights heavily in favour of reporting it as if it is an unintentional code error. If it was intentional obfuscated code, the coder will be happy it causes an error.\n\nHowever, there could be use cases for embedding 'hidden' structured information in the assert ast, which are stripped in optimize mode. If that is a serious concern, I can package up my code as a flake8 plugin instead.",
"date_created": "2015-11-20T20:57:06Z"
},
{
"owner": "jwilk",
"content": "I used `assert 0` a few times, because that's less typing than `assert False`.\nDebian Code Search says I'm not the only one who's that lazy:\nhttps://codesearch.debian.net/search?q=%28%3Fm%29^\\s*assert\\s%2B0\\s*%28%2C|%24%29+filetype%3Apython\n\nWhat's the use case for `assert True`?\n\nIn general, I think assertions that are always true are probably mistakes; and assertions that are always false are probably intentional.",
"date_created": "2015-11-20T21:23:38Z"
},
{
"owner": "jayvdb",
"content": "Yea, I agree `assert 0` is self-evident enough that it shouldnt be an error.\n\ntbh, I can't think of a use case for `assert True`, and would happily report an error for it also. In its favour, `assert True` is at least quite clear about what it does and doesnt do.",
"date_created": "2015-11-20T21:52:31Z"
},
{
"owner": "bitglue",
"content": "https://github.com/pyflakes/pyflakes/pull/51",
"date_created": "2015-11-24T12:47:00Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/848467",
"date_created": "2011-09-13T01:03:01Z"
},
{
"status": "New",
"security_related": false,
"description": "These can take several forms:\n\n raise \"shouldn't happen\"\n raise 'Cannot determine type of callable: '+repr(callableObject)\n raise \"Can't read input parameters file : %s\" % options.input_file\n\nSome of these will be harder to detect than others.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "mithrandi",
"id": 848470,
"duplicate_of": null,
"title": "Warn about string exceptions",
"comments": [
{
"owner": "bitglue",
"content": "Pyflakes still supports python 2.5, where string exceptions are still allowed. Pyflakes has no way to know what the target python version is, so must take the conservative approach and assume the code might be targeted at python 2.5 and string exceptions are valid.\n\nFor code targeted at later versions, I suggest catching these errors in unit tests.",
"date_created": "2014-09-24T11:58:05Z"
},
{
"owner": "mithrandi",
"content": "Unfortunately the most common occurrences of string exceptions are in exceptional code paths that are never (and perhaps have never) been tested; but perhaps pyflakes is not the right tool for dealing with this problem (although, since pyflakes already has to deal with Python 2 vs Python 3, I could imagine support being added for more precise version targets).",
"date_created": "2014-09-24T12:12:05Z"
},
{
"owner": "florent.x",
"content": "According to the Python documentation:\n\n\u00ab Raising of strings as exceptions, as in the statement raise \"Error occurred\", is deprecated in Python 2.5 and will trigger a warning. The aim is to be able to remove the string-exception feature in a few releases. \u00bb\nhttps://docs.python.org/2.7/whatsnew/2.5.html#pep-352-exceptions-as-new-style-classes\n\nSo we could probably enforce this deprecation in a linter tool which supports Python 2.5.\n\nWith the examples posted in the initial requests, I think that this checker will be easy to implement for \"simple cases\" as a warning in the \"pep8.py\" tool, which does non-AST analysis of the code.",
"date_created": "2014-09-24T12:30:16Z"
},
{
"owner": "adiroiban",
"content": "+1 for fixing this in pep8.py",
"date_created": "2015-02-14T12:04:02Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/848470",
"date_created": "2011-09-13T01:05:39Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "See attached program for a trivial example of a common idiom: \n\n\"my special string %(with_a_variable)s\"%locals()\n\nI wouldn't expect pyflakes to know how to deal with an arbitrary dictionary in the right hand position, but the use of locals() means that certain variables are actually used!",
"tags": [
"formatting",
"string",
"substitution"
],
"duplicates": [
970637
],
"assignee": "florent.x",
"milestone": "0.6.1",
"owner": "ato2g-andrew",
"id": 872503,
"duplicate_of": null,
"title": "Pyflakes does not recognize locals() as a use",
"comments": [
{
"owner": "ato2g-andrew",
"content": "",
"date_created": "2011-10-11T20:44:08Z"
},
{
"owner": "exarkun",
"content": "Pyflakes can't be sure that `locals` refers to the builtin locals function which returns the locals of the scope it is used in. It could have been overridden with another object which behaves differently.\n\nPyflakes could probably track the name and determine if it has been overridden in a sensible way, but there's no way for it to tell if the intended use is for the name to be injected externally somehow.\n",
"date_created": "2011-10-11T21:10:47Z"
},
{
"owner": "ato2g-andrew",
"content": "Is Pyflakes goal to be correct every time it points out an error? Or to not miss errors within predefined categories?\n\nIn the current behavior, Pyflakes flags \"used\" variables as \"unused\". If the user replaces locals() with their own function definition they will not get an error. Assuming that locals() refers to the builtin will produce a \"sound\" error-finder as defined\nhttp://en.wikipedia.org/wiki/Soundness\n\n \n\n\n\n\n",
"date_created": "2011-10-11T21:43:32Z"
},
{
"owner": "exarkun",
"content": "Pyflakes' goal is to be useful. It does not try to fit into any particular formal mathematical framework.\n\nPersonally, I avoid the question of what pyflakes should do in this case by not using locals() to interpolate into strings. I don't find that this constrains my ability to write programs easily.\n\nI would say that injecting `locals` into a scope and expecting Pyflakes to behave correctly in that case is more unreasonable than expecting locals() interpolated into a string literal to mark the keys in the string literal as used locals. So, go ahead and submit a branch implementing this feature.",
"date_created": "2011-10-11T22:30:08Z"
},
{
"owner": "ielectric+",
"content": "I wrote a patch for this: https://github.com/kevinw/pyflakes/commit/947e988b3548d360e46ffc996eb4671fa875ca11",
"date_created": "2013-01-08T11:30:31Z"
},
{
"owner": "jaraco",
"content": "Thanks very much for this change. I also concur with the change.\n\nQuestion - should 'vars()' also be treated the same way as locals()?",
"date_created": "2014-07-16T12:00:33Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/872503",
"date_created": "2011-10-11T20:44:08Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "In the code:\n\ndef foo():\n x, y = 1, 2\n return 3\n\nx and y are not shown as being unused.",
"tags": [],
"duplicates": [
1276273
],
"assignee": null,
"milestone": "0.8.1",
"owner": "yatc18ks0-9a-ngeefk4xa",
"id": 879941,
"duplicate_of": null,
"title": "Unused variables aren't detected with destructuring assignment",
"comments": [
{
"owner": "glyph",
"content": "This is somewhat intentional. 'ignored, ignore, ignored, useful, ignored, ignored = some_dumb_tuple_that_should_have_been_an_object_with_attributes' is an unfortunately common idiom, given the way some Python APIs are designed.",
"date_created": "2012-06-22T21:20:33Z"
},
{
"owner": "exarkun",
"content": "I guess the point here is that *nothing* in the example is used. It is intentional that:\n\n x, y = 1, 2\n return x\n\ngenerates no warnings, but that seems to be a different case.",
"date_created": "2012-06-23T12:07:29Z"
},
{
"owner": "asmeurer",
"content": "As I pointed out in #1276273, the difference is that you are unpacking from a tuple literal. If you have\n\nfor root, dirs, files in os.walk(path):\n ...\n\nand never user \"dirs\", then there's no value in pyflakes telling you that, because os.walk gives you dirs whether you want to use it or not. \n\nBut if you write\n\na, b, c = 1, 2, 3\n\n(which is syntactically equivalent to a, b, c = (1, 2, 3))\n\nand you don't use b, then you might as well have written\n\na, c = 1, 3\n\nNobody made you unpack the second item but yourself. So PyFlakes should warn against it in this case. Of course, if someone write\n\nA = (1, 2, 3)\na, b, c = A\n\nthen there's no way it can know that you didn't mean to use every element of A. But for a tuple *literal* on the rhs of assignment, there's no valid reason to have unused entries, other than maybe you thought 1, 2, 3, was prettier than 1, 3 :)\n\n(and by the way, I disagree that these things should return some object with attributes. It would be even more painful to write\n\nfor walker in os.walk(path):\n root = walker.root\n dirs = walker.dirs\n files = walkter.files\n ...\n\nI contend that this is a very beautiful idiom, and item unpacking in general is a very useful feature of the language)",
"date_created": "2014-03-22T16:38:35Z"
},
{
"owner": "florent.x",
"content": "Thank you for clarifying.\r\n\r\nIt would be a good enhancement, indeed.",
"date_created": "2014-03-22T17:13:44Z"
},
{
"owner": "florent.x",
"content": "I've implemented the proposal by asmeurer.\r\n\r\nhttps://github.com/pyflakes/pyflakes/commit/4417b7730c3e42087d3adb56d13bd4756d05b0bc",
"date_created": "2014-03-30T02:39:58Z"
},
{
"owner": "asmeurer",
"content": "Cool. I always forget about star unpacking. I feel like that feature would get more people to move to Python 3 if they knew about it. ",
"date_created": "2014-04-01T01:15:08Z"
},
{
"owner": "ale-fener",
"content": "Hi all,\n\nI also came across this issue recently, with pyflakes 1.0.0, and I was very surprised that the following code does not generate any warnings:\n\ndef foo():\n a, b = some_function()\n return 1\n\nfollowing the comment #3, I didn't get why there is no value in knowing that any of the unpacked variables are unused, it seems to me that you can always write:\n\nfor root, _, files in os.walk(path):\n\ninstead of \n\nfor root, dirs, files in os.walk(path):\n\nif you are not going to use the 'dirs' variable, so I don't see why you might be forced to define a variable that you never use.\nThanks for the great tool anyway, I am really happy about it in general.\n\n",
"date_created": "2016-05-05T20:05:53Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/879941",
"date_created": "2011-10-22T14:54:32Z"
},
{
"status": "New",
"security_related": false,
"description": "In the code:\n\ndef decorator(func):\n return func\n\n\n@decorator\ndef defined_twice():\n pass\n\n\n@decorator\ndef defined_twice():\n pass\n\nPyflakes gives the error: twice.py:10: redefinition of function 'defined_twice' from line 5\n\nIt ought to be: twice.py:11: redefinition of function 'defined_twice' from line 6",
"tags": [],
"duplicates": [
1459257
],
"assignee": null,
"milestone": null,
"owner": "yatc18ks0-9a-ngeefk4xa",
"id": 879945,
"duplicate_of": null,
"title": "Incorrect line numbers for decorated functions",
"comments": [
{
"owner": "exarkun",
"content": "Why? The Python AST makes the decision that the first line of a function is the first decorator that applies to it. Pyflakes just propagates this information.\n",
"date_created": "2011-10-22T21:00:20Z"
},
{
"owner": "yatc18ks0-9a-ngeefk4xa",
"content": "The Python AST gives the line number where the function definition starts, which includes the decorator. However, the fault isn't on that line and the user cannot fix the issue by changing that line.\n\nGiven a FunctionDef node:\n\nnode.lineno # where the function definition starts\nnode.lineno + len(node.decorator_list) # where the function name is",
"date_created": "2011-10-25T10:40:11Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/879945",
"date_created": "2011-10-22T14:58:03Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "code:\n\n----------------------------------------\ntest = True\nif False:\n del(test)\nassert(test)\n----------------------------------------\n\npyflakes complains:\n[...].py:4: undefined name 'test'\n\n\ni guess this may be too hard for a static analysier, in which case, how about\n\n----------------------------------------\ntest = True\nif False:\n del(test)\nelse:\n assert(test)\n----------------------------------------\n\nwhere the usage is in a different else branch to the del\n\noutput:\n[...].py:5: undefined name 'test'",
"tags": [],
"duplicates": [
901235,
969919,
1212912
],
"assignee": "adiroiban",
"milestone": null,
"owner": "david-szotten",
"id": 885140,
"duplicate_of": null,
"title": "using del in if clause confuses pyflakes",
"comments": [
{
"owner": "exarkun",
"content": "You're welcome to give it a try.\r\n",
"date_created": "2011-11-02T13:03:51Z"
},
{
"owner": "saperski",
"content": "I have a code in https://github.com/kevinw/pyflakes/pull/28 \n(https://github.com/saper/pyflakes/commit/09c52fcfab742b4f67c9d21d18ae389c300b4ea6) to fix another bug https://bugs.launchpad.net/pyflakes/+bug/916264 but there is a code to detect if instructions are on different sides\nof \"if:\" and \"else:\" or \"try:/except:/else:\". I think this approach could be applied to this case as well.\n\nMore info about how it works here: \n\nhttps://code.launchpad.net/~dobey/divmod.org/pyflakes-less-redef/+merge/130183/comments/307409",
"date_created": "2013-01-06T23:14:48Z"
},
{
"owner": "florent.x",
"content": "bug #885140 marked as duplicate of this one",
"date_created": "2014-03-29T17:22:39Z"
},
{
"owner": "florent.x",
"content": "bug #1212912, actually",
"date_created": "2014-03-29T17:23:59Z"
},
{
"owner": "adiroiban",
"content": "Here is my attempt to fix this https://github.com/pyflakes/pyflakes/pull/12\n\nPlease take a look. Thanks!",
"date_created": "2015-02-14T11:18:53Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/885140",
"date_created": "2011-11-02T10:28:43Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "It would be nice if pyflakes would provide an option for ignoring some warnings.\n\nFor example I have this code:\n\ntry:\n from setproctitle import setproctitle\nexcept ImportError:\n setproctitle = lambda t: None # pyflakes:ignore\n\nAnd pyflakes will complain that setproctitle is redefined.\nMaybe this is a bad code and this kind of things should be never ignored, but I just want to know if such a feature is wanted in pyflakes.\n\nHere is a workaround for implementing pyflakes:ignore\n\nclass PocketLintPyFlakesChecker(PyFlakesChecker):\n '''PocketLint checker for pyflakes.\n\n This is here to work around some of the pyflakes problems.\n\n Beside the AST tree, it is also initialized with the plain text content\n of the file.\n '''\n\n def __init__(self, tree, filename='(none)', text=None):\n self.text = text\n if self.text:\n self.text = self.text.split('\\n')\n super(PocketLintPyFlakesChecker, self).__init__(\n tree=tree, filename=filename)\n\n def report(self, messageClass, *args, **kwargs):\n text_lineno = args[0] - 1\n if self.text[text_lineno].find('pyflakes:ignore') >= 0:\n return\n self.messages.append(messageClass(self.filename, *args, **kwargs))",
"tags": [],
"duplicates": [
1287336
],
"assignee": null,
"milestone": null,
"owner": "adiroiban",
"id": 907742,
"duplicate_of": null,
"title": "Add support for ignoring some warnings",
"comments": [
{
"owner": "exarkun",
"content": "I'd rather fix the bugs in pyflakes that lead to spurious warnings.\n",
"date_created": "2011-12-22T12:33:09Z"
},
{
"owner": "bukzor",
"content": "We have some questionable-but-necessary code which uses globals().update(). The of course causes pyflakes to freak out about undefined variables. I'd like to be able to ignore those warnings, instead of ignoring pyflakes altogether.",
"date_created": "2012-03-20T01:43:41Z"
},
{
"owner": "esz-michel",
"content": "@sinzui: Can you link to the changeset? I am curious to see *how* this was implemented. Sorry if the link is already available somewhere, but I could noit find it :\\\n\nI would really like this feature as well, but more fine-grained as proposed. For example, pylint allows you to disable a specific error-code (see http://www.logilab.org/card/pylint_manual#messages-control). Or, the Java @SuppressWarnings annotation also allows you to ignore specific warnings.\n\nI find the proposed solution to simply ignore pyflakes altogether is a bit like a \"except Exception\": You might miss other errors ;)",
"date_created": "2012-04-29T09:34:26Z"
},
{
"owner": "sinzui",
"content": "Adi extended PyFlakesChecker to accept the raw text of the module being checked. The report() method looks of the line number of warning/error and in the text and looks for \"# pyflakes:ignore\". The report returns early if the comment is present.\n https://code.launchpad.net/~adiroiban/pocket-lint/907742/+merge/102882",
"date_created": "2012-04-30T14:25:55Z"
},
{
"owner": "adiroiban",
"content": "Hi,\n\nRight now, pyflakes messages do not have a ID for each message class. In pylint each message class has its own ID.\n\nI agree that this all or nothing filter can lead to other troubles. I will check to see if pyflakes developers would like to accept a patch to pyflakes to add IDs for each message class, and then we can improve the current pocketlint filter.",
"date_created": "2012-04-30T14:55:14Z"
},
{
"owner": "bukzor",
"content": "Alternative solution: use a pylintrc that is only roughly as picky as pyflakes.",
"date_created": "2012-05-21T23:16:32Z"
},
{
"owner": "glyph",
"content": "There's already a bug for automatically detecting the entirely detectable class of error in the example here, isn't there? It would be so much nicer to do that than to encourage users to drop these comment turds into their code.",
"date_created": "2012-06-19T04:53:04Z"
},
{
"owner": "exarkun",
"content": "More than one:\n\n https://bugs.launchpad.net/pyflakes/+bug/885140\n https://bugs.launchpad.net/pyflakes/+bug/800691\n https://bugs.launchpad.net/pyflakes/+bug/916264\n\nProbably others. Fixing these real problems would be a great win for all pyflakes users.\n\n",
"date_created": "2012-06-19T12:38:49Z"
},
{
"owner": "florent.x",
"content": "Issues 800691 and 916264 and many others were fixed with Pyflakes 0.6.1.\r\n\r\nIf you *really* want to use comments to disable some checks, try Flake8.\r\n\r\nBut the recommended path is to open an issue if it looks like a limitation of Pyflakes.",
"date_created": "2013-03-05T18:07:59Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/907742",
"date_created": "2011-12-22T12:17:45Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "Currently pyflakes 0.5 does not detect unused function arguments.\n\nTo reproduce:\n\n$ echo \"def foo(bar): pass\" | pyflakes\n\nThis should warn that bar is never used, but it doesn't.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jendrikseipp",
"id": 949563,
"duplicate_of": null,
"title": "Detect unused function parameters",
"comments": [
{
"owner": "glyph",
"content": "Actually, I don't think that pyflakes should do this. It's perfectly valid to have a function which accepts a bunch of parameters that it doesn't use, either because it's an implementation of an interface (maybe even a no-op implementation!) that doesn't require a parameter that another implementation might, or because it's accepting parameters that it may wish to use in the future.",
"date_created": "2012-03-08T06:06:22Z"
},
{
"owner": "jendrikseipp",
"content": "You're right, those are valid use-cases.\n",
"date_created": "2012-03-08T10:23:28Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/949563",
"date_created": "2012-03-08T01:06:26Z"
},
{
"status": "Triaged",
"security_related": false,
"description": "For example, code like this will break:\n\n >>> \"%(foo)\" % {\"foo\": \"bar\"}\n Traceback (most recent call last):\n File \"<stdin>\", line 1, in <module>\n ValueError: incomplete format\n\nIt'd be awesome if Pyflakes told me about that kind of issue.",
"tags": [],
"duplicates": [
1361849
],
"assignee": null,
"milestone": null,
"owner": "jkakar",
"id": 950369,
"duplicate_of": null,
"title": "Detect broken string templates that will raise ValueError when interpolated",
"comments": [
{
"owner": "jkakar",
"content": "I poked through the code and determined that implementing this kind of\ncheck will be a pretty big pain in the neck. We'd need to parse the\nstring to determine what kind of interpolation is required and then\nverify that with the arguments to be interpolated. ie, we'd need to\nimplement our own string interpolation engine. Ew.\n",
"date_created": "2012-03-08T23:21:10Z"
},
{
"owner": "exarkun",
"content": "A patch to implement this was sent to the mailing list, https://lists.launchpad.net/divmod-dev/msg00193.html",
"date_created": "2012-03-15T19:50:49Z"
},
{
"owner": "jwilk",
"content": "Implementing your own string interpolation engine may sound scary at first, but in fact it should be quite easy. For example, pylint has a template parser that is just ~60 lines of code:\nhttps://bitbucket.org/logilab/pylint/src/36355f1fe1fd/checkers/utils.py?at=default#cl-277\n\nI took a different approach in lintian4python, which resulted in even shorted code:\nhttps://bitbucket.org/jwilk/lintian4python/src/5e552f08d8f5/helpers/python/code-analysis?at=default#cl-292\n",
"date_created": "2013-12-09T13:35:27Z"
},
{
"owner": "asmeurer",
"content": "Too bad they're both GPL, as you otherwise could literally just reuse that code. ",
"date_created": "2013-12-09T18:09:56Z"
},
{
"owner": "jwilk",
"content": "The relevant part of lintian4python is under the same license as pyflakes.",
"date_created": "2013-12-10T07:11:36Z"
},
{
"owner": "asmeurer",
"content": "Rather than rewriting Python's string interpolation, would it be possible to just take the string and interpolate it with some dummy objects that have sufficient __int__, __float__, __str__, etc. defined on them, and see if any errors are raised (basically, reuse Python's own engine)?",
"date_created": "2015-05-28T18:29:31Z"
},
{
"owner": "jwilk",
"content": "Absolutely. That's what I did in lintian4python.",
"date_created": "2015-05-28T18:39:10Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/950369",
"date_created": "2012-03-08T22:38:18Z"
},
{
"status": "New",
"security_related": false,
"description": "Hello,\nas reported on Debian at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653890:\n\n\"\"\"\nIt would be great if pyflakes could detect files that are python scripts\nbut are not named *.py. It would have to read the first two bytes of\neach file to check for scripts and then read the rest of the line to\ndetermine if it is a python script. It would need to process stuff like:\n\n#!/usr/bin/python\n#!/usr/local/bin/python\n#!/usr/bin/env python\n#!/usr/bin/python2.6\n#!/usr/bin/python3.2\n\"\"\"\n\nRegards,\nSandro",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "morph-debian",
"id": 970465,
"duplicate_of": null,
"title": "Please also check python scripts that are not named *.py",
"comments": [
{
"owner": "saperski",
"content": "I believe that pyflakes checks any file, regardless whatever the file name is. It even accepts input on stdin. Is this somehow debian specific?",
"date_created": "2013-01-06T23:17:02Z"
},
{
"owner": "morph-debian",
"content": "On Mon, Jan 7, 2013 at 12:17 AM, Marcin Cie\u015blak\n<email address hidden> wrote:\n> I believe that pyflakes checks any file, regardless whatever the file\n> name is. It even accepts input on stdin. Is this somehow debian\n> specific?\n\nhttp://bazaar.launchpad.net/~divmod-dev/pyflakes/trunk/view/head:/pyflakes/scripts/pyflakes.py#L91\n",
"date_created": "2013-01-08T10:46:38Z"
},
{
"owner": "icordasc",
"content": "Personally I'm -1 on this. Theoretically there could be a directory with hundreds of files with only a handful of python files (whether they bear the .py suffix or not). Having to check every file for All variations of `#!/usr/bin/python(version)` seems extraordinary and impractical. One reason not to do this is the following:\n\nLet's assume you have pyflakes installed under 2.6 (or even 2.5) while having files with a header that specifies python 3000 (any version you choose). It will fail upon compilation before it is even capable of doing any checks. That would be useless. On the other hand if you installed under python 3, there are object attributes that are no longer valid. I believe `iteritems` is a popular dictionary method that no longer exists on dictionaries in python 3.",
"date_created": "2013-02-02T19:00:41Z"
},
{
"owner": "myint",
"content": "Ian, I'm not sure how any of that follows from what Sandro is requesting. I think he is just asking for pyflake's \"os.walk()\" to look for files other than ones that end with \"*.py\". So instead of only checking \"filename.endswith('.py')\", also look for files by reading the first few bytes for the Unix shebang. And then check it against something like the regular expression \"^#!.*\\bpython[23]?\\b\\s*$\"",
"date_created": "2015-04-06T02:57:17Z"
},
{
"owner": "bitglue",
"content": "This sounds like a worthwhile feature, as long as it can be demonstrated that it does not significantly impact performance.",
"date_created": "2015-05-27T16:02:56Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/970465",
"date_created": "2012-03-31T23:34:02Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "pytest sues __tracebackhide__ to hide frames in tracebacks,\n\nwould be nice if that was honored",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7",
"owner": "ronny-pfannschmidt-deactivatedaccount",
"id": 1105525,
"duplicate_of": null,
"title": "ignore special locals of test frameworks",
"comments": [
{
"owner": "florent.x",
"content": "This seems fixed in 0.6.1 thanks to http://launchpad.net/bugs/1107587.",
"date_created": "2013-01-29T17:10:55Z"
},
{
"owner": "ronny-pfannschmidt-deactivatedaccount",
"content": "not at all\n\n__tracebackhide__ is a local one defines inside a function\n\nthe patch is about globals magically appearing",
"date_created": "2013-01-29T18:21:13Z"
},
{
"owner": "florent.x",
"content": "This use case is documented there http://pytest.org/latest/example/simple.html#writing-well-integrated-assertion-helpers",
"date_created": "2013-03-30T18:55:00Z"
},
{
"owner": "florent.x",
"content": "The merge-proposal is on GitHub, because auto-mirroring is broken since last Saturday.\r\n\r\nhttps://github.com/pyflakes/pyflakes/pull/5",
"date_created": "2013-04-02T21:22:57Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1105525",
"date_created": "2013-01-25T23:16:05Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "execnet supports passing whole modules tor execution to a remote\n\nif its on a remote, then __name__ is '__channelexec__' and a global named channel can be used",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "ronny-pfannschmidt-deactivatedaccount",
"id": 1105526,
"duplicate_of": null,
"title": "support for execnet remote executable modules",
"comments": [
{
"owner": "florent.x",
"content": "The use case explained in the documentation:\nhttp://codespeak.net/execnet/basics.html#remote-exec-execute-source-code-remotely\n\nThis is covered (at least partially) with the optional argument \"builtins\" for the Checker constructor.",
"date_created": "2013-03-30T18:44:11Z"
},
{
"owner": "bitglue",
"content": "What might the solution to this look like? How would Pyflakes know that execnet is in use? Is there a way to accommodate this use case that does not compromise the more usual case of checking ordinary Python programs?",
"date_created": "2015-05-27T16:10:01Z"
},
{
"owner": "bitglue",
"content": "Closing this for lack of activity. This seems like a special case that would best be handled by constructing your own Checker object as florent.x describes.",
"date_created": "2015-11-17T15:26:30Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1105526",
"date_created": "2013-01-25T23:17:18Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "This commonly used pattern reports an UndefinedName with pyflakes 0.5\n\n try:\n socket_map\n except NameError:\n socket_map = {}",
"tags": [],
"duplicates": [],
"assignee": "florent.x",
"milestone": "0.7",
"owner": "florent.x",
"id": 1106930,
"duplicate_of": null,
"title": "with a NameError exception handler, an UndefinedName should not be raised",
"comments": [
{
"owner": "florent.x",
"content": "Ready for review.",
"date_created": "2013-03-30T16:18:29Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1106930",
"date_created": "2013-01-27T14:18:07Z"
},
{
"status": "New",
"security_related": false,
"description": "Given that pyflakes now has an API, it might be worthwhile to add documentation somewhere and since you're already hosting the source on GitHub, ReadTheDocs is an option.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "icordasc",
"id": 1113692,
"duplicate_of": null,
"title": "[Feature] Add hosted docs",
"comments": [
{
"owner": "florent.x",
"content": "It would be nice, indeed.\n\n\nThe legacy documentation has just an overview:\nhttp://divmod.readthedocs.org/en/latest/products/pyflakes.html\n\nWith a pending pull request:\nhttps://github.com/MostAwesomeDude/divmod-docs/pull/8",
"date_created": "2013-02-08T12:35:16Z"
},
{
"owner": "icordasc",
"content": "I'd be interested in helping set up docs on ReadTheDocs. I can send a pull request soon.",
"date_created": "2013-02-25T18:45:59Z"
},
{
"owner": "icordasc",
"content": "Heh. Sorry for lying. It wasn't intentional. I should have free time in the up-coming week or two.",
"date_created": "2013-05-11T17:32:43Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1113692",
"date_created": "2013-02-02T19:03:16Z"
},
{
"status": "New",
"security_related": false,
"description": "this would allow to do propper support for framework specific extra checks/bindings outside of pyflakes\n\nfor example, instead of the execnet support, i could pass in a mixin that overrides the check\nor instead of the ErrorReturn check, that could also be a mixin\n\nsame goes for supporting __tracebackhide__",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "ronny-pfannschmidt-deactivatedaccount",
"id": 1114708,
"duplicate_of": null,
"title": "allow to specify checker mixins",
"comments": [
{
"owner": "nejucomo",
"content": "I would like to argue against this kind of feature.\n\nPlugins would make it less clear what it means when a codebase does or does not pass pyflakes. Furthermore, plugins may not uphold the Design Principles. https://github.com/pyflakes/pyflakes#design-principles\n\nIf a codebase needs framework specific checks, why not run pyflakes *and* a different tool on that codebase? Finally, other tools like pylint are highly customizeable and already have plugin APIs, so if you really want one tool that performs many codebase-specific or user-specific tests, maybe that tool is more appropriate.\n",
"date_created": "2015-06-07T13:25:47Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1114708",
"date_created": "2013-02-03T23:59:53Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "A lot of Zope packages use the following style for their unit tests:\n\n import doctest\n\n from somepackage import something\n\n def doctest_something_does_it_right():\n \"\"\"\n\n >>> something('the ultimate answer')\n 42\n\n \"\"\"\n\n def test_suite():\n return doctest.DocTestSuite()\n\nSince pyflakes doesn't pay attention to doctests in docstrings, it tends to produce huge amount of false positives (\"unused name 'something') and it misses possible issues in the doctest code.\n\nThere's an old patch by Ignas Mikalaj\u016bnas that adds doctest support to pyflakes. I've been using it for a long time in my fork (lp:~mgedmin/pyflakes/pyflakes-mg). Florent Xicluna recently rebased it on top of the latest pyflakes in https://code.launchpad.net/~pyflakes-dev/pyflakes/0.6-doctest-support",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7",
"owner": "mgedmin",
"id": 1118173,
"duplicate_of": null,
"title": "Pay attention to doctests",
"comments": [
{
"owner": "florent.x",
"content": "The merge proposal was held back because it would have created conflict with the resolution of bug 1159514\n\nNow the merge proposal for adding column information is merged in trunk.\nhttps://code.launchpad.net/~pyflakes-dev/pyflakes/0.6-col-offset/+merge/156231\n\nThe branch related to the doctest-support needs update.",
"date_created": "2013-04-04T07:33:55Z"
},
{
"owner": "florent.x",
"content": "Merged for 0.7",
"date_created": "2013-04-16T17:51:57Z"
},
{
"owner": "mgedmin",
"content": "Thanks!",
"date_created": "2013-04-17T05:16:11Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1118173",
"date_created": "2013-02-07T09:37:37Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Please add a --version option so that I can check which version of Pyflakes I've got installed.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7",
"owner": "mgedmin",
"id": 1143978,
"duplicate_of": null,
"title": "Please add a --version option",
"comments": [
{
"owner": "gbrandl",
"content": "--help would also be nice.",
"date_created": "2013-03-29T11:11:58Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1143978",
"date_created": "2013-03-04T09:32:13Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Consider this Python code:\n\nimport os\nimport os.path\nimport re\nre.search(\"a\", \"abd\")\n\n...for this code pyflakes will say:\n$ pyflakes .\n./aaa.py:2: 'os' imported but unused\n\nInstead of if the above I would like it to say:\n$ pyflakes .\n./aaa.py:1: 'os' imported but unused\n./aaa.py:2: 'os.path' imported but unused",
"tags": [],
"duplicates": [],
"assignee": "jayvdb",
"milestone": null,
"owner": "mnemo",
"id": 1153355,
"duplicate_of": null,
"title": "import os + import os.path both unused generates only a single slightly confusing warning",
"comments": [
{
"owner": "mnemo",
"content": "Bug found in 0.5.0-1ubuntu1",
"date_created": "2013-03-10T20:17:28Z"
},
{
"owner": "jayvdb",
"content": "fwiw, as of v1.2.0, the error message is less confusing as the name in the error message now matches what appears on the line of the source code:\n\n./aaa.py:2: 'os.path' imported but unused\n\nThis was done with\n\nhttps://github.com/pyflakes/pyflakes/commit/aec68a7847d8dbd1371242f42f9302103a68178f\n\nIt had a few bugs (lp:1560134 and lp:1578051), which have fixes yet to be released.\n\nIt still does not detect that both are unused, which turns out to be a spectacularly difficult problem to solve in pyflakes, but we're getting closer.",
"date_created": "2016-05-04T13:36:28Z"
},
{
"owner": "jayvdb",
"content": "Whoops, I set this to fix released, when it isnt. It should go back to New.",
"date_created": "2016-05-07T16:04:40Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1153355",
"date_created": "2013-03-10T20:17:14Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "In relation to this bug on Flake8: https://bitbucket.org/tarek/flake8/issue/90/column-missing-for-undefined-identifiers it would be useful if Pyflakes could report the column number by default or allow an option to be set through the API to enable reporting of the number.",
"tags": [],
"duplicates": [],
"assignee": "florent.x",
"milestone": "0.7",
"owner": "icordasc",
"id": 1159514,
"duplicate_of": null,
"title": "Support reporting the column number",
"comments": [
{
"owner": "florent.x",
"content": "maybe this feature was implemented in a fork of Pyflakes.",
"date_created": "2013-03-29T09:41:15Z"
},
{
"owner": "ronny-pfannschmidt-deactivatedaccount",
"content": "i recall this was implemented in kevins fork and basically amounts to pass the full position information to the reporting instead of just line numbers",
"date_created": "2013-03-29T10:46:00Z"
},
{
"owner": "florent.x",
"content": "I retrieved the code from Kevin's repository.\r\nPatch is attached.",
"date_created": "2013-03-30T16:17:22Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1159514",
"date_created": "2013-03-24T20:19:37Z"
},
{
"status": "New",
"security_related": false,
"description": "Pyflakes will generate a spurious \"imported but unused\" warning for the following code:\n\nimport selenium as se\nimport selenium.webdriver\n\nse.webdriver.Firefox(\"foo\")\n\nNote that Pyflakes will, correctly, *not* generate such a warning for the following:\n\nimport selenium\nimport selenium.webdriver\n\nse = selenium\n\nse.webdriver.Firefox(\"foo\")",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "bcs26",
"id": 1162031,
"duplicate_of": null,
"title": "\"import as\" can cause spurious \"imported but unused\" warnings",
"comments": [
{
"owner": "florent.x",
"content": "The \"imported but unused\" is not triggered on \"import ... as ...\".\r\nActually, it is triggered by the second import line, not the first one.\r\n\r\nI agree this is slightly confusing because of issue #1153355.\r\nBut it is not a bug.",
"date_created": "2013-03-29T21:29:32Z"
},
{
"owner": "bcs26",
"content": "Agreed that the warning targets the second \"import\". The warning itself, however, does seem to be caused by the presence of \"import as\". The following (effectively identical) code, for example, correctly does not trigger a warning:\n\n\nimport selenium\nimport selenium.webdriver\n\nselenium.webdriver.Firefox(\"foo\")\n\n\nNot sure I understand the comment about it not being a bug: an \"unused\" warning is generated, but both import lines are in fact essential (the code will raise an error if either is removed).",
"date_created": "2013-03-29T21:49:13Z"
},
{
"owner": "florent.x",
"content": "In the \"import as\" example, the name \"selenium\" is assigned in the global namespace but it is not used in the module. Only \"se\" is effectively used.\nIn the other example, the \"selenium\" name is assigned and is effectively used.\n\nThere are different ways to work around this and avoid putting an unused name in the globals. For example:\n\n from selenium import webdriver\n webdriver.Firefox(\"foo\")\n\n\nOr another example:\n\n import selenium as se\n __import__('selenium.webdriver')\n se.webdriver.Firefox(\"foo\")\n\n\nOr you keep the code as-is, and you just ignore this pyflakes message.",
"date_created": "2013-03-29T22:27:15Z"
},
{
"owner": "bcs26",
"content": "Ok, it honestly sounds like we just disagree on this.\n\nIf you'd like, I'm happy to call this a feature request: it would be helpful if pyflakes did not generate a warning for this code, since the only alternative is adding code solely to suppress the warning.\n\nThat said, while the *name* may be unused, the import operation is obviously essential. Using __import__(\"...\") to avoid introducing the name seems a bit silly, especially because pyflakes does not in general warn about unused top-level names---so, in this case, it is going out of its way to warn about reasonable code.\n\n(As a perhaps-interesting aside, using \"del selenium\" to remove the name generates a different warning.)",
"date_created": "2013-03-29T23:12:46Z"
},
{
"owner": "florent.x",
"content": "I keep the issue open, since you don't like the alternative examples which were proposed:\r\n\r\n import selenium\r\n import selenium.webdriver\r\n se = selenium\r\n se.webdriver.Firefox(\"foo\")\r\n\r\n(or)\r\n\r\n from selenium import webdriver\r\n webdriver.Firefox(\"foo\")\r\n\r\n\r\nFor the other remark, regarding the unassignment of globally imported objects, I opened bug 1162161 and attached a patch to it.",
"date_created": "2013-03-30T16:13:44Z"
},
{
"owner": "bcs26",
"content": "Sounds fair. Appreciated the discussion.\n\n\nOn Sat, Mar 30, 2013 at 9:13 AM, Florent <email address hidden> wrote:\n\n> I keep the issue open, since you don't like the alternative examples\n> which were proposed:\n>\n> import selenium\n> import selenium.webdriver\n> se = selenium\n> se.webdriver.Firefox(\"foo\")\n>\n> (or)\n>\n> from selenium import webdriver\n> webdriver.Firefox(\"foo\")\n>\n>\n> For the other remark, regarding the unassignment of globally imported\n> objects, I opened bug 1162161 and attached a patch to it.\n>\n> ** Changed in: pyflakes\n> Status: Incomplete => New\n>\n> --\n> You received this bug notification because you are subscribed to the bug\n> report.\n> https://bugs.launchpad.net/bugs/1162031\n>\n> Title:\n> \"import as\" can cause spurious \"imported but unused\" warnings\n>\n> To manage notifications about this bug go to:\n> https://bugs.launchpad.net/pyflakes/+bug/1162031/+subscriptions\n>\n",
"date_created": "2013-03-30T16:59:28Z"
},
{
"owner": "jayvdb",
"content": "It is possible, but not easy, for pyflakes to detect that `import selenium.webdriver` is altering `se`. But even if pyflakes detected this, IMO it should still emit an error for it. Instead of \"imported but unused\", it should report \"imported submodule a.b only used via c.b.\"\n\nIMO the two options provided in comment #5 are the correct \"flake free\" code, and IMO this is the most desirable:\n\n from selenium import webdriver\n webdriver.Firefox(\"foo\")\n\nIf a more descriptive prefix is desirable, that could be:\n\n from selenium import webdriver as selenium_webdriver\n selenium_webdriver.Firefox(\"foo\")\n",
"date_created": "2015-11-25T21:59:27Z"
},
{
"owner": "bcs26",
"content": "Both of those alternatives are totally reasonable... but at least IMO they don't feel super great.\n\nFor many larger packages (e.g. numpy) an \"import numpy as np\" style is extremely common, but you still need to import various submodules. If you apply the pattern above, you end up with \"import numpy.modulea as np_modulea\", \"import numpy.random.moduleb as np_random_moduleb\", etc. That obviously *works* but ends up creating two independent styles of usage. Not to mention the repetitive boilerplate in the actual imports.\n\nUltimately it feels like working around an implementation limitation on the linter side. Fine if that's what it takes, better if it's unnecessary!",
"date_created": "2015-11-26T20:36:05Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1162031",
"date_created": "2013-03-29T21:00:41Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "This case where we import a module for its side-effects gives a warning.\n\nimport fu\ndel fu\n\n\nor the one of bug 1162031\n\nimport selenium as se\nimport selenium.webdriver\ndel selenium\n\nse.webdriver.Firefox(\"foo\")\n\n\nNote that this case is covered in the test suite, so it might be intentional:\nhttp://bazaar.launchpad.net/~pyflakes-dev/pyflakes/master/view/72/pyflakes/test/test_imports.py#L23",
"tags": [],
"duplicates": [],
"assignee": "florent.x",
"milestone": "0.7",
"owner": "florent.x",
"id": 1162161,
"duplicate_of": null,
"title": "import fu; del fu complains about RedefinedWhileUnused",
"comments": [
{
"owner": "florent.x",
"content": "See merge-proposal here: https://github.com/pyflakes/pyflakes/pull/4\r\n\r\n(unfortunately the mirroring GitHub --> Pyflakes is broken)",
"date_created": "2013-04-02T21:26:15Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1162161",
"date_created": "2013-03-30T09:52:33Z"
},
{
"status": "New",
"security_related": false,
"description": "test.py:\n\nimport sys\n\nimport sys\n\ndef func():\n \"\"\"\n A docstring\n >>> import sys\n >>> sys.path\n \"\"\"\n\n return 1\n\nThe pyflakes output is\n\ntest.py:1: 'sys' imported but unused\ntest.py:6: redefinition of unused 'sys' from line 1\n\nThe line 6 \"redefinition of unused 'sys' from line 1\" is incorrect, because the doctest scope is separate from the module scope. \n\nI can't figure out how to reproduce it with a small file, but in this file: https://github.com/sympy/sympy/blob/master/sympy/physics/mechanics/functions.py, the output is\n\nsympy/physics/mechanics/functions.py:160: redefinition of unused 'diff' from line 27\nsympy/physics/mechanics/functions.py:200: redefinition of unused 'dynamicsymbols' from line 19\nsympy/physics/mechanics/functions.py:261: redefinition of unused 'dynamicsymbols' from line 19\nsympy/physics/mechanics/functions.py:458: redefinition of unused 'Point' from line 26\nsympy/physics/mechanics/functions.py:508: redefinition of unused 'Point' from line 26\n\nThat is, it complains about the imports in the doctests, but not the imports themselves (because they actually are used in the file).",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1178807,
"duplicate_of": null,
"title": "Add option to select scope for doctests",
"comments": [
{
"owner": "asmeurer",
"content": "I think it's because it's pushing a function scope for doctests, but really, it should be using a completely new module scope. Doctests are run like they a from-scratch Python interpreter. ",
"date_created": "2013-05-11T21:34:25Z"
},
{
"owner": "florent.x",
"content": "IIRC the imports at module level are available when running the doctests.\nThis could explain the warning.\n\nI don't use doctests enough to confirm it, though.",
"date_created": "2013-06-15T12:41:56Z"
},
{
"owner": "asmeurer",
"content": "Ah OK. So apparently Python's doctest module does work this way, but SymPy's doctester does not. Would it be possible to add an option to make doctests operate in their own module scope? This is IMHO the correct way to write doctests, because then users can just copy and paste the output and it will work (and that's why SymPy's doctester works this way). ",
"date_created": "2013-06-15T17:00:15Z"
},
{
"owner": "jayvdb",
"content": "This was fixed on Mar 30, 2014 by ffe926c282 (https://github.com/pyflakes/pyflakes/commit/ffe926c282).\n\nReproduced and confirmed fixed using https://github.com/sympy/sympy/commit/96dcc6a635\nSympy master has the same underlying problem, but the names are different.",
"date_created": "2015-11-17T05:51:27Z"
},
{
"owner": "asmeurer",
"content": "The real issue here was a feature request to add an option to use module scopes for doctests (see comment #3). ",
"date_created": "2015-11-17T17:11:14Z"
},
{
"owner": "jayvdb",
"content": "I'd like to explore whether it is necessary to run doctests as a top level scope.\n\nI've been working towards:\n1. processing the doctest scope so it can use the module scope (sloppy use of doctest, but very common)\n2. ensuring that the doctest scope does not report errors if it does not use the module scope (good use of doctest)\n3. reporting errors when the module scope relies on the doctest scope (very very bad use of doctest)\n\nThe doctest scope currently can re-import names also imported in the module scope, without error. I believe that is very very close to the request in #3, that doctest have their own 'module scope'.\ne.g. test_importInDoctestAndAfter : https://github.com/pyflakes/pyflakes/blob/master/pyflakes/test/test_doctests.py#L217\n\nNote that `test_importBeforeAndInDoctest` above `test_importInDoctestAndAfter` is a bit misleading, being marked as 'todo'. The code sample in that test does not report any errors, as it is effectively equivalent to `test_importInDoctestAndAfter`.\n\nIMO, broadly speaking, doctests shouldnt re-use names existing in the module scope, with imports being the obvious exception. If there is a case were re-importing in the doctest scope causes an error, IMO that needs to be fixed.\nAre there other situations where doctest re-using names from the module scope is preferable or even necessary?\n\nOn the structural problems mentioned in #1, a recent checkin (https://github.com/pyflakes/pyflakes/commit/93aa3c435505b8541b151c3e4b24c0ec4333f0bb) changed it so that a doctest is a module scope instead of a function scope. This is still not perfect, as the doctest scope should reside in the module scope, but it is currently deeply nested and resides with the object's scope where the docstring exists. That means currently it could inherit variables from any scope where the docstring resides; clearly a source of bugs, and this fix has been included in two of my pull requests. Maybe I should pull it out into a separate pull request with dedicated tests.\n\nThe other outstanding problem I am aware of is that a module level import which is only used in doctests is not reported as an error. I have a fix for that (https://github.com/jayvdb/pyflakes/commit/a8ccb1cef8ec005b07ea347823c4987d995d29c8), but it is waiting on a few other patches to be merged.\n\nThe unclear case that I am aware of is 'from x import foo' in module scope being shadowed by a 'from y import foo' in doctest scope. I suspect we'll need to declare that problem as unsolvable by pyflakes, as doctests should show recommended importation for clients, whereas the module level imports of the same names are sometimes different (more complex) due to internal mess/structure being hidden from the end-user.",
"date_created": "2015-11-22T00:22:28Z"
},
{
"owner": "jayvdb",
"content": "doctest scope level pull request: https://github.com/pyflakes/pyflakes/pull/52",
"date_created": "2015-11-22T01:49:24Z"
},
{
"owner": "asmeurer",
"content": "For my use-case, even imports should be required for doctests. Doctests should be considered for all intents and purposes to be completely independent modules. The idea is that a user should be able to run the code in a doctest in their own Python session and completely reproduce the output. ",
"date_created": "2015-11-22T08:22:40Z"
},
{
"owner": "mgedmin",
"content": "Consider this:\n\n def parse_color(color):\n \"\"\"Parse a color string and return (r, g, b) values from 0.0 to 1.0.\n\n Example:\n\n >>> parse_color('#fff')\n (1.0, 1.0, 1.0)\n\n \"\"\"\n\nAre you saying the name 'parse_color' shouldn't be automatically available in the doctest and instead there should be an explicit import? That feels to me like insisting on unnecessary boilerplate.\n\n(BTW Launchpad's issue tracker is *terribly inconvenient* would you PLEASE migrate to GitHub issues?)",
"date_created": "2015-11-22T09:21:00Z"
},
{
"owner": "jayvdb",
"content": "A stricter scope for doctest is easy to construct. The problem will be that we may need to create a few pyflakes options in order to accommodate various opinions of 'strict' ;-) pyflakes doesnt seem to like providing end-users with options -- only PYFLAKES_BUILTINS and PYFLAKES_DOCTEST exist. :/\n\nI expect most people would expect that a strict doctest scope would include only what is exported using __all__, if __all__ was defined (and sympy appears to do that systematically). That would typically eliminate imports, requiring re-imports in the doctest to access any other modules.\n\nThat would mean a doctest is not quite a completely independent module; instead each doctest essentially has an implicit \"from <current module> import *' at the beginning.\n\n@asmeurer, would that be 'close enough' for your needs?\n\nIf that still isnt good enough, then I think we need to design user selection of at least three alternatives:\n1. cpython doctest mode (default)\n2. __all__ exported names only\n3. empty scope\n\nThe obvious approach is some command line argument.\n\nIf the module includes a footer of `if __name__ == \"__main__\": import doctest; doctest.testmod()` , we could detect the list of desired globals by identifying `doctest.testmod(globs=[(name, globals()[name]) for name in __all__])` and `doctest.testmod(globs=None)` as a means of enabling option 2 or 3 respectively. The detection logic could also support extracting a custom list of valid names using a literal dict, i.e. doctest.testmod(globs={'a': 1, 'b': b}).\n\nA little more difficult approach, which probably needs assistance from pep8/flake8, is to export the \"inside doctest\" status to flake8 plugins, so that people wanting a stricter rules within doctests only can create flake8 plugins to achieve their own objectives.",
"date_created": "2015-11-22T12:03:30Z"
},
{
"owner": "jayvdb",
"content": "* would include only what is exported using __all__, if __all__ was defined, plus the name of the function/class the docstring is attached to if it isnt in __all__\n\n(and +1 for moving issues to github ;-)",
"date_created": "2015-11-22T12:24:18Z"
},
{
"owner": "asmeurer",
"content": "@mgedmin yes, for my use-case yes, we do use that kind of boilerplate (here are some examples http://docs.sympy.org/latest/modules/simplify/simplify.html). I agree that not everyone wants this, though, which is why I suggested making it an option. The different levels of scoping that @jayvdb suggests may also be useful, although I would be hesitant to implement them unless an actual doctest runner uses them. \n\n(and I'm also very +1 to moving to GitHub FWIW)",
"date_created": "2015-11-22T19:15:26Z"
},
{
"owner": "jayvdb",
"content": "I think all doctest runners supports custom globals. The following fails:\n\n`\n_m = 1\n\ndef doctest_stuff(self):\n '''\n >>> _m\n 1\n '''\n return 1\n\nif __name__ == \"__main__\":\n import doctest\n doctest.testmod(globs={})\n`\n\nThe problem is that pyflakes and other tools are assuming doctests are run with the default `doctest.testmod` arguments.\n\nI've raised a bug for the list of desired globals to be more easily specified in a way other tools can detect.\n\nhttp://bugs.python.org/issue25699",
"date_created": "2015-11-22T20:52:29Z"
},
{
"owner": "jayvdb",
"content": "It looks like http://bugs.python.org/issue25699 wont be accepted, so pyflakes will likely need to build this in the module.\nIn which case, we need to decide how to allow users to configure pyflakes. Only using env vars is not very user friendly.\n\n(and I'm also very +1 to moving to GitHub FWIW)",
"date_created": "2016-10-03T00:25:21Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1178807",
"date_created": "2013-05-10T19:58:57Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "__init__.py files are full of unused import warnings, because all they are are imports. But this is one instance where it is correct to import something and not \"use\" it.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1178905,
"duplicate_of": null,
"title": "Don't report unused imports in __init__.py",
"comments": [
{
"owner": "asmeurer",
"content": "I see. It is trying to do this, but it only works if the module uses __all__. Isn't it more correct to just ignore all undefined names at the module level scope in an __init__.py file?",
"date_created": "2013-05-11T04:45:06Z"
},
{
"owner": "icordasc",
"content": "@asmeurer no it shouldn't. There are people who write actually classes and functions in __init__.py. Those people are expecting these errors. There is probably no really good way to ignore some and not others.",
"date_created": "2013-05-11T13:26:22Z"
},
{
"owner": "asmeurer",
"content": "But even if you do that, all imported names are going to be used for import purposes. And there will be so many false positives that no one will ever notice a mistake from pyflakes anyway. ",
"date_created": "2013-05-11T16:58:22Z"
},
{
"owner": "icordasc",
"content": "With the same exact example above you can not be certain of that. I could write something that imports a module, refactor and completely forget to remove the import were I to not have pyflakes reporting for it. Why should pyflakes just assume that I'm leaving it there for someone else to import into their library?\n\nIn short, the best way to really do this is to use __all__. It's the only reliable way to avoid the unused import warnings since it clearly shows the intent of the module author. If you're using submodules instead and don't wish to have to do:\n\n from sub_module import (exported, names)\n # etc.\n\n __all__ = [exported, names, ...]\n\nThen do\n\n import sub_module1\n import sub_module2\n # etc.\n import sub_modulen\n\n __all__ = []\n\n for i in range(1, n + 1):\n __all__.extend(globals()['sub_module%d' % i].__all__)\n\nObviously that's a bit contrived, but you get the point. You can be guaranteed it will execute only once and it won't cause you other troubles with pyflakes.",
"date_created": "2013-05-11T17:15:12Z"
},
{
"owner": "asmeurer",
"content": "> Why should pyflakes just assume that I'm leaving it there for someone else to import into their library?\n\nBecause you're writing it in __init__.py. That's exactly what that file is for. Besides, writing extensive code in __init__.py is (IMO) bad style, and you shouldn't be surprised if pyflakes misses errors because of it. \n\nBy the way, what is the general stance for pyflakes aboud false positives vs. false negatives?",
"date_created": "2013-05-11T17:25:10Z"
},
{
"owner": "icordasc",
"content": "It's bad style in my opinion too, but is far more common than I like.\n\nYou're still going to have push back from plenty of people though that there's no checking on __init__.py and they should feel surprised that pyflakes missed errors in it.",
"date_created": "2013-05-11T17:37:54Z"
},
{
"owner": "florent.x",
"content": "IMHO, the \"__all__\" declaration is the only safe way to prevent this warning. I agree with Ian.\n\nhttp://docs.python.org/3.4/tutorial/modules.html#importing-from-a-package\n\nIf you need more flexibility, Flake8 \"# noqa\" should help.",
"date_created": "2013-06-15T12:38:18Z"
},
{
"owner": "asmeurer",
"content": "Today's update to PEP 8 says, \"Wildcard imports (from <module> import *) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools. There is one defensible use case for a wildcard import, which is to republish an internal interface as part of a public API (for example, overwriting a pure Python implementation of an interface with the definitions from an optional accelerator module and exactly which definitions will be overwritten isn't known in advance).\n\n\"When republishing names this way, the guidelines below regarding public and internal interfaces still apply.\"\n\nIs that argument enough to change this behavior?",
"date_created": "2013-08-01T15:55:36Z"
},
{
"owner": "exarkun",
"content": "No. Be explicit about the names you want to export. Define an `__all__` on your package.\n",
"date_created": "2013-11-03T13:47:45Z"
},
{
"owner": "asmeurer",
"content": "It seems like __all__ is unnecessary complexity for most packages, and may make the import time unnecessarily slower (I haven't timed it, though, so I could be wrong about the speed). ",
"date_created": "2013-11-03T20:19:35Z"
},
{
"owner": "bjodah",
"content": "I completely agree with @asmeurer on this. It has always been and still is my biggest concern with pyflakes.",
"date_created": "2015-11-03T13:54:30Z"
},
{
"owner": "pierre-sassoulas",
"content": "Maybe flake could give a different more explicit warning message and not F401, when there is unused import in an __init__ file. Something like \"x imported but unused, declare with __all__ if you want to explicitly export this name\".",
"date_created": "2016-10-27T14:57:24Z"
},
{
"owner": "alevis",
"content": "Still an inconvenience. ",
"date_created": "2017-01-29T01:05:21Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1178905",
"date_created": "2013-05-11T04:27:16Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "The dependency on unittest2 causes problems when trying to run the tests for Python 3 at package build time in Debian and Ubuntu. We don't have a python3-unittest2 package available. IIUC, upstream unittest2 doesn't support Python 3 anyway; that's available in a separate package called: https://pypi.python.org/pypi/unittest2py3k but that's not available in Debian.\n\nIs the dependency on unittest2py3k really necessary for Python 3? Is it possible to conditionally import unittest2 only when running in Python 2?",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.7.3",
"owner": "barry",
"id": 1183953,
"duplicate_of": null,
"title": "Tests depend on unittest2",
"comments": [
{
"owner": "barry",
"content": "Oh, and related: LP: #1097061\n\n(but I agree with the above that a dependency on Twisted for testing is suboptimal)\n",
"date_created": "2013-05-24T18:01:53Z"
},
{
"owner": "florent.x",
"content": "Well, I have nothing against removing this dependency, but I fail to integrate \"unittest\" from Python 3.3 and \"setuptools\" ...\n\nThis is the problematic line in \"setup.py\":\n\n 'test_suite': 'unittest2.collector.collector'\n\nAny idea ?\nThanks.",
"date_created": "2013-06-15T12:29:25Z"
},
{
"owner": "barry",
"content": "On Jun 15, 2013, at 12:29 PM, Florent wrote:\n\n>Well, I have nothing against removing this dependency, but I fail to\n>integrate \"unittest\" from Python 3.3 and \"setuptools\" ...\n>\n>This is the problematic line in \"setup.py\":\n>\n> 'test_suite': 'unittest2.collector.collector'\n>\n>Any idea ?\n\nSince all your tests live in the pyflakes.test subpackage, it should be enough\nto just do this:\n\ntry:\n from setuptools import setup\nexcept ImportError:\n from distutils.core import setup\n extra = {'scripts': [\"bin/pyflakes\"]}\nelse:\n if sys.version_info < (3,):\n extra = {'tests_require': ['unittest2'],\n 'test_suite': 'unittest2.collector'}\n else:\n ## extra = {'tests_require': ['unittest2py3k'],\n ## 'test_suite': 'unittest2.collector.collector'}\n extra = {'test_suite': 'pyflakes.test'}\n extra['entry_points'] = {\n 'console_scripts': ['pyflakes = pyflakes.api:main'],\n }\n\nAfter I changed all the imports from 'unittest2' to 'unittest', it all just\nworked:\n\n...\n----------------------------------------------------------------------\nRan 544 tests in 0.467s\n\nOK (skipped=33)\n",
"date_created": "2013-06-18T21:48:18Z"
},
{
"owner": "florent.x",
"content": "Thank you for this hint, Barry.\r\n\r\nI dropped the test dependency for Python >= 2.7 (in revision 101).",
"date_created": "2013-06-18T23:00:22Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1183953",
"date_created": "2013-05-24T18:01:12Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "running with pypy\n\n----------------------------------------------------------------------\nRan 544 tests in 2.363s\n\nFAILED (failures=11, skipped=33)\n\nDo we care?",
"tags": [
"tests"
],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "johneed",
"id": 1186139,
"duplicate_of": null,
"title": "pypy support?",
"comments": [
{
"owner": "johneed",
"content": "",
"date_created": "2013-05-31T06:25:35Z"
},
{
"owner": "florent.x",
"content": "Contribution is welcome on the topic of Pypy support.",
"date_created": "2013-06-15T12:19:28Z"
},
{
"owner": "jayvdb",
"content": "Pull request submitted: https://github.com/pyflakes/pyflakes/pull/50",
"date_created": "2015-11-19T08:01:54Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1186139",
"date_created": "2013-05-31T06:25:35Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "A commons source of silly bugs is to call some method or function that doesn't need parameters, say, data_update(), without the empty parens, so that, e.g,\nprint(data_update)\n<method data.update at 0x7f4c315e1830>\nIt would be nice to have a t least the option to raise a warning when a method is called without parens, since as far as I know referencing the memory address of a method is not done often.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "lorenzo233",
"id": 1188565,
"duplicate_of": null,
"title": "Warning for methods called without parens?",
"comments": [
{
"owner": "asmeurer",
"content": "I'm not a pyflakes developer, but this will probably be rejected. Pyflakes is only for actual logical errors. Warnings like this fit projects like pylint better. \n\nAnd anyway, I disagree that no one ever uses functions without calling them. I pass closures around all the time. ",
"date_created": "2013-06-07T15:00:01Z"
},
{
"owner": "florent.x",
"content": "I agree that it does not match with Pyflakes tool, because it will give plenty of False positive.\r\n\r\nIf you need this feature, you should probably write a plugin for Flake8 instead.",
"date_created": "2013-06-15T12:16:35Z"
},
{
"owner": "exarkun",
"content": "This is what unit tests are for.\n",
"date_created": "2013-11-03T13:48:34Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1188565",
"date_created": "2013-06-07T10:48:08Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "The following example:\n\n```\ndef test(a, b):\n yield a\n return b\n```\n\npasses pyflakes, even though it is invalid syntax in Python 2.\n\nMigrated from here: https://bitbucket.org/tarek/flake8/issue/112/return-with-argument-inside-generator-not",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "attilaolah",
"id": 1198132,
"duplicate_of": null,
"title": "Return with argument inside generator",
"comments": [
{
"owner": "attilaolah",
"content": "Attached a [pull request](https://bitbucket.org/tarek/flake8/issue/112/return-with-argument-inside-generator-not).",
"date_created": "2013-07-05T12:11:15Z"
},
{
"owner": "florent.x",
"content": "This is merged in trunk\r\nhttps://github.com/pyflakes/pyflakes/pull/11",
"date_created": "2014-03-22T14:11:53Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1198132",
"date_created": "2013-07-05T10:32:52Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "It would be really great to be able to ignore/filter doctest errors. E.g.::\n\n---\n\ndef something(f):\n \"\"\"\n >>> a + 1\n \"\"\"\n return f + 1\n\n\n---\n\nAnd you could choose to ignore the error about 'a' not being defined.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "jtratner",
"id": 1223150,
"duplicate_of": null,
"title": "Disable doctest checking unless an option is passed",
"comments": [
{
"owner": "exarkun",
"content": "I'd love for this regression to be fixed. It is dumping a lot of spurious warnings into pyflakes output for my project.",
"date_created": "2013-10-30T22:46:48Z"
},
{
"owner": "jtratner",
"content": "It turns out there's an environment variable you can set PYFLAKES_NODOCTEST that magically turns this off, would be nice if it were documented.",
"date_created": "2013-10-30T22:58:40Z"
},
{
"owner": "glyph",
"content": "\"Don't check doctests\" should really be the default behavior. Checking doctests by default in this manner is a regression, since it causes false positives.\n\nIf you have doctests and you want them checked, you know it, and you can easily pass an additional option. Many examples in code that use a >>> prefix are not doctests and should not be treated as such.\n\n(Honestly I think it's weird that this feature got added at all: Pyflakes' whole raison d'\u00eatre is to be simple and fast and err on the side of checking only things that are clearly invalid; if you want to lint every possible insane thing, pychecker and pylint are already endlessly configurable to do things like this, aren't they?)",
"date_created": "2013-10-30T23:25:16Z"
},
{
"owner": "glyph",
"content": "Changed the subject since apparently PYFLAKES_NODOCTEST is already an option, but I'd still like it if it were the default.",
"date_created": "2013-10-30T23:26:48Z"
},
{
"owner": "mgedmin",
"content": "To satisfy your curiosity: there are large codebases out there (mostly from the Zope project) that have large numbers of doctests, and not checking them causes large numbers of false positives for names imported at the top of the module and used in multiple doctests, e.g. ::\n\n from zope.foo import bar\n\n def doctest_bar_does_x():\n \"\"\"\n >>> bar('x')\n 42\n \"\"\"\n\n def doctest_bar_does_y():\n \"\"\"\n >>> bar('y')\n -42\n \"\"\"\n\nIt never occurred to me that people would write invalid code in doctests.\n\n*shrug*\n\nI'm not against flipping the default setting of the option, provided that I can enable it by specifying something in setup.cfg to indicate that this project uses doctests and would like to verify their correctness.",
"date_created": "2014-01-21T11:02:09Z"
},
{
"owner": "jtratner",
"content": "Should your example cause an error or not? I'm unclear on how namespacing\nworks in doctests.\n",
"date_created": "2014-01-21T15:26:21Z"
},
{
"owner": "asmeurer",
"content": "I think the default (python -m doctest) uses the module namespace in the doctest, but this is bad form IMHO, because doctests, as examples to the user, should be self-contained. For the SymPy doctest runner we changed the behavior to make doctests independently scoped (https://github.com/sympy/sympy/blob/master/sympy/utilities/runtests.py#L1205). An option to change the scoping would be nice. I think there's a separate issue open for this, though. ",
"date_created": "2014-01-22T01:15:19Z"
},
{
"owner": "exarkun",
"content": "See https://github.com/pyflakes/pyflakes/pull/25",
"date_created": "2014-02-17T15:41:56Z"
},
{
"owner": "florent.x",
"content": "This pull request is now merged in the trunk.\r\n\r\nThank you.",
"date_created": "2014-03-22T16:10:58Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1223150",
"date_created": "2013-09-10T03:14:23Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "__all__ = ['a']\n__all__ += ['b']\n__all__ += ['c']\n\n\u2192 'a' imported but unused",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "spaceone",
"id": 1241878,
"duplicate_of": null,
"title": "__all__ += []",
"comments": [
{
"owner": "florent.x",
"content": "Thank you, this is fixed in trunk",
"date_created": "2014-03-22T15:12:46Z"
},
{
"owner": "spaceone",
"content": "I thank you!",
"date_created": "2014-03-22T15:23:09Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1241878",
"date_created": "2013-10-18T23:53:15Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "See https://github.com/purcell/flymake-python-pyflakes/issues/11#issuecomment-28181238. It would be useful for some tools if syntax errors also had a column number, like\n\ntest.py:6:12: invalid syntax",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "asmeurer",
"id": 1250684,
"duplicate_of": null,
"title": "Give column information for syntax errors",
"comments": [
{
"owner": "asmeurer",
"content": "Fixed at https://github.com/pyflakes/pyflakes/pull/15",
"date_created": "2013-11-13T01:34:25Z"
},
{
"owner": "florent.x",
"content": "Merged, thank you.",
"date_created": "2014-03-22T16:12:23Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1250684",
"date_created": "2013-11-13T01:24:06Z"
},
{
"status": "New",
"security_related": false,
"description": "Is there a reason pyflakes doesn't warn on \"dead code\", i.e., code that cannot possibly be run because it comes after a return or a raise in the same block, like\n\ndef f():\n return\n g() # cannot be reached\n\nI think return, raise, break, and continue are all such statements. \n\nIn a similar vein (should this be a separate issue?), what about unnecessary pass, like\n\nif x:\n pass\n f()\n\nInline non-string literals or bare variable names might also fit into this category, although the latter can be a useful way to squash incorrect \"unused variable\" warnings.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1274566,
"duplicate_of": null,
"title": "\"Dead code\" after a return",
"comments": [
{
"owner": "jayvdb",
"content": "Also assignments preceding a return/raise, but not used in that branch.\n\ndef foo(a):\n if a:\n x = 10\n return a\n else:\n x = 20\n\n return x",
"date_created": "2015-12-22T11:34:50Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1274566",
"date_created": "2014-01-30T16:07:03Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "I'm attempting to subclass the Pyflakes Checker class to add some custom checks.\n\nIn Checker.handleNode, it sets \"node.level = self.nodeDepth\" to track the depth of the node in the tree. For ast.ImportFrom nodes, this assignment overwrites the \"level\" attribute already present on the ImportFrom node, which tracks the level of a relative import, i.e.:\n\n from zero import foo\n ImportFrom(module='zero', ..., level=0)\n\n from .one import foo\n ImportFrom(module='one', ..., level=1)\n\n from ..two import foo\n ImportFrom(module='two', ..., level=2)\n\nCan you please rename the Pyflakes attribute to \"depth\" or something else unique so that it doesn't overwrite this information on the ImportFrom nodes?\n\nI'm monkey-patching it locally to work around this.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8",
"owner": "launchpad-matt-good",
"id": 1277280,
"duplicate_of": null,
"title": "Overwrites \"level\" attribute on ImportFrom nodes",
"comments": [
{
"owner": "florent.x",
"content": "Thank you, this is fixed in trunk.",
"date_created": "2014-03-22T16:26:16Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1277280",
"date_created": "2014-02-06T23:12:34Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Would be nice if pyflakes handled Control+C gracefully, like it does for Control+D.\n\n$ pyflakes\nControl+D\n$\n\n$ pyflakes\nControl+C\nTraceback (most recent call last):\n File \"/usr/local/bin/pyflakes\", line 9, in <module>\n load_entry_point('pyflakes==0.7.3', 'console_scripts', 'pyflakes')()\n File \"/usr/local/lib/python2.7/dist-packages/pyflakes/api.py\", line 130, in main\n warnings = check(sys.stdin.read(), '<stdin>', reporter)\n\nA little snippet like this would do the trick:\n\nexcept KeyboardInterrupt:\n pass",
"tags": [
"hotkey",
"interrupt",
"signal",
"ui"
],
"duplicates": [],
"assignee": null,
"milestone": "0.8.2",
"owner": "andrew-pennebaker",
"id": 1285290,
"duplicate_of": null,
"title": "Treat Control+C as Control+D",
"comments": [
{
"owner": "florent.x",
"content": "This is under control with this changeset:\r\nhttps://github.com/pyflakes/pyflakes/commit/c3b1fc2b749cffa4d43e3e71d968a5e37a30b6f2\r\n\r\nThank you",
"date_created": "2014-04-26T14:16:51Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1285290",
"date_created": "2014-02-26T18:16:57Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "$cat test.py\ndef test():\n break\n$pyflakes test.py\n$python test.py\n File \"test.py\", line 2\n break\nSyntaxError: 'break' outside loop",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1293654,
"duplicate_of": null,
"title": "break outside of loop not caught",
"comments": [
{
"owner": "asmeurer",
"content": "Same with continue",
"date_created": "2014-07-24T17:07:18Z"
},
{
"owner": "asmeurer",
"content": "Same with return or yield outside a function. \n\nIt seems the problem is that ast.parse (or compile with ast.PyCF_ONLY_AST) ignores these errors. Apparently the fact that continue and break have to be inside a loop or that return and yield have to be inside a function are not specified in the grammar (would that make it context-sensitive?). This is clear if you look at the grammar definition at https://docs.python.org/2/library/ast.html#abstract-grammar or even the official one at http://hg.python.org/cpython/file/96ea15ee8525/Grammar/Grammar.\n\nIs there a function that can be used to try to compile an ast object further, in order to get these syntax errors, or is the only fix to also call compile without ast.PyCF_ONLY_AST on the source code?",
"date_created": "2014-07-24T21:06:37Z"
},
{
"owner": "asmeurer",
"content": "I have a fix at https://github.com/pyflakes/pyflakes/pull/8. 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.",
"date_created": "2014-07-25T16:43:28Z"
},
{
"owner": "asmeurer",
"content": "https://github.com/pyflakes/pyflakes/pull/20 was merged.",
"date_created": "2015-11-17T17:01:42Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1293654",
"date_created": "2014-03-17T16:23:22Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "from __future__ import * should be a syntax error.\n\n$pyflakes test.py\ntest.py:1: 'from __future__ import *' used; unable to detect undefined names\n$python test.py\n File \"test.py\", line 1\n from __future__ import *\nSyntaxError: future feature * is not defined",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1294878,
"duplicate_of": null,
"title": "from __future__ import *",
"comments": [
{
"owner": "jwilk",
"content": "It's a regression; pyflakes 0.4 caught this error correctly:\n\n$ pyflakes test.py \ntest.py:1: future feature * is not defined\nfrom __future__ import *\n\nIn lintian4python I catch this kind of bugs by compile()ing the AST tree.",
"date_created": "2014-03-31T18:27:59Z"
},
{
"owner": "florent.x",
"content": "This is most probably related to this change:\n\n 0.5.0: Convert pyflakes to use newer _ast infrastructure rather than compiler.\n\n\nWe could detect it differently now, of course.",
"date_created": "2014-03-31T19:35:09Z"
},
{
"owner": "asmeurer",
"content": "This is the second (admittedly esoteric) syntax error I've found that Pyflakes didn't catch (the other was https://bugs.launchpad.net/pyflakes/+bug/1293654). ",
"date_created": "2014-03-31T19:59:32Z"
},
{
"owner": "jayvdb",
"content": "It is a trivial one liner to detect '*'.\nBut how do we feel about importing __future__ and ensuring that only valid items are imported? We dont import other packages, even std lib packages, but __future__ is primarily a syntax issue.\n\nThe most common mistake I've seen is 'print_statement' being used instead of 'print_function', but other typos/thinkos/etc also happen.\nhttps://bitbucket.org/logilab/astroid/commits/973613a18cccd896c10d6c7081dc818e5581f467",
"date_created": "2015-11-17T11:32:20Z"
},
{
"owner": "bitglue",
"content": "I've personally never needed such a feature since any error with __future__ (like syntax errors) is easily caught by just trying to import the module. But __future__ imports can be validated in a way which is fast, and does not have side effects, then I see no harm.\n\nIt might be a little tricky to know what things are valid to import, since that changes over time.\n\nI guess we could just have pyflakes look at __future__.all_future_names to get all the valid things for the version of python running pyflakes. There's some opportunity for user mistake there, similar to how people periodically report bugs about pyflakes missing python 3 features when they are running it with python 2. But maybe that won't be a big deal -- I guess the only way to know is to try it and see.",
"date_created": "2015-11-17T15:16:09Z"
},
{
"owner": "asmeurer",
"content": "\"from __future__ import invalid_name\" is also raised as a SyntaxError, so I think pyflakes should catch it (IMHO pyflakes should always warn about SyntaxErrors). It's curious that this didn't come up when I did https://github.com/pyflakes/pyflakes/pull/20. I guess these errors must be in a different file in the CPython source from the one I was looking at. ",
"date_created": "2015-11-17T17:07:15Z"
},
{
"owner": "jayvdb",
"content": "Proposed fix: https://github.com/pyflakes/pyflakes/commit/76dbf3c6d18764e8f15b420b519ad8700771d73b\n\n(part of https://github.com/pyflakes/pyflakes/pull/47 , sitting on top of pending PR 43 https://github.com/pyflakes/pyflakes/pull/43)",
"date_created": "2015-11-18T03:41:30Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1294878",
"date_created": "2014-03-19T22:33:11Z"
},
{
"status": "New",
"security_related": false,
"description": "Consider this test code:\n\ndef foo():\n bar = 1\n if 0:\n del bar\n else:\n del bar\n\npyflakes reports test.py:6: undefined name 'bar', that is 2nd `del bar` is considered in error.\n\nunderstandably it is impossible to analyse all code paths in general case, so how about tagging `bar` as `uncertain if label is present` and allowing to `del` it?",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "dimaqq",
"id": 1308508,
"duplicate_of": null,
"title": "False positive undefined name after del in branch",
"comments": [
{
"owner": "ramalho",
"content": "Here is another false positive, for a not-so-subtle case:\n\nUsing flake8, which uses PyFlakes, I get the report:\n\nboard.py:14:19: F821 undefined name 'StandardError'\n\nHowever, StandardError is a built-in exception in Python 2 (but not in Python 3).",
"date_created": "2014-04-19T20:15:55Z"
},
{
"owner": "florent.x",
"content": "I agree with the initial bug reported : probably we could do better in this case.\r\n\r\n\r\n\r\nThe issue reported by @ramalho is not related to the initial report, and it's not an issue at all:\r\n\r\n $ python3 -m pyflakes <<< StandardError\r\n <stdin>:1: undefined name 'StandardError'\r\n $ python2 -m pyflakes <<< StandardError\r\n $ ",
"date_created": "2014-04-26T09:31:26Z"
},
{
"owner": "blueyed",
"content": "I came across a similar issue like in comment #1, where flake8/pyflakes on python3 reports \"F821: undefined name 'unicode'\" , but the code path is not triggered for Python3:\n\n if sys.version_info < (3, 0):\n def __unicode__(self):\n return self.url\n\n def __add__(self, other):\n return unicode(self) + other\n else:\n def __str__(self):\n return self.url\n\n def __add__(self, other):\n return str(self) + other\n",
"date_created": "2014-07-31T15:15:43Z"
},
{
"owner": "jayvdb",
"content": "This bug is about `del` (and the cases in https://bugs.launchpad.net/pyflakes/+bug/1431099 appear to be the same problem)\n",
"date_created": "2015-11-20T21:07:06Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1308508",
"date_created": "2014-04-16T12:22:15Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "It would be nice if pyflakes source code could pass the pyflakes checker itself.\n\nIn this way any warning produced by new code is sure coming from that code.\n\nI will send a pull request\n\nThanks!",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": "0.8.2",
"owner": "adiroiban",
"id": 1311145,
"duplicate_of": null,
"title": "Have a source code clean of pyflakes warnings",
"comments": [
{
"owner": "florent.x",
"content": "Merged, thanks.",
"date_created": "2014-04-26T09:25:32Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1311145",
"date_created": "2014-04-22T14:22:17Z"
},
{
"status": "New",
"security_related": false,
"description": "Tahoe-LAFS, a large Python codebase implementing a distributed filesystem, uses a script called \"check-miscaptures\" ( https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/misc/coding_tools/check-miscaptures.py) to catch a class of errors resulting in unexpected behaviour when capturing variables in loops.\n\nAn example of incorrect code that it would catch is:\n\n a = [None]*10\n for i in range(0, 10):\n a[i] = lambda x: x+i\n\n # The programmer expected a[x](y) to be equivalent to x+y\n\n print a[2](2) # not 4, but 11\n\nThis happens because all of the a[i] capture the same mutable variable i, which is 9 after the loop when the lambda is called.\n\nFor this example, the output of check-miscaptures is:\n\n Checking miscapture.py...\n miscapture.py:3 <lambda> captures 'i' assigned at line 2\n 1 suspiciously captured variables in 1 out of 1 file(s).\n\nChanging the loop body to \"a[i] = lambda x, i=i: x+i\" fixes the problem, and check-miscaptures will not report a warning for the fixed code (it rarely gives false positives, and when it does they are easy to suppress).\n\nThe same problem can happen with named functions rather than lambdas, and with other kinds of loop or list comprehensions. More realistic examples are common in programs that define lots of callback functions, for example when using asynchronous libraries such as Twisted.\n\nThis ticket is to integrate the checking done by this script into pyflakes.",
"tags": [
"enhancement"
],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "daira",
"id": 1357096,
"duplicate_of": null,
"title": "contribute checking for \"miscaptured\" variables in loops",
"comments": [],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1357096",
"date_created": "2014-08-14T21:49:25Z"
},
{
"status": "Triaged",
"security_related": false,
"description": "This code may be worth a warning:\n\nfoo = 1\n\nfor foo in (2,3,4):\n pass\n\nIt's easy to accidentally step on a variable in a for loop, where usually one only uses the loop variable within the loop.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "wsanchez",
"id": 1408774,
"duplicate_of": null,
"title": "Warn about defining a loop variable that steps on an outer variable.",
"comments": [
{
"owner": "bitglue",
"content": "Indeed. The problem is I haven't been able to think of a way to do that which doesn't also catch legitimate use cases.\n\nThis was discussed recently on the code-quality mailing list. Archive here: https://mail.python.org/pipermail/code-quality/2014-December/000450.html\n\nCan you think of some logic that would catch the problem in your example, but not also apply to at least some of the use cases enumerated in that thread, thus generating false positives?",
"date_created": "2015-01-08T21:37:30Z"
},
{
"owner": "asmeurer",
"content": "I don't know if any code uses this idiom, but a possible use-case of setting the loop variable before the loop (without using it) is if the loop is empty and you want to use the loop variable after the loop like\n\ni = None\nfor i in list_that_could_be_empty:\n do_stuff()\n\ndo_something_with(i)\n\nIf you don't set i above the loop and the loop ends up being empty you'll get a NameError.\n\nBeyond that, I don't see a reason why setting a loop variable shouldn't be included in the \"unused variable redefined\" warnings. ",
"date_created": "2015-01-08T21:56:10Z"
},
{
"owner": "bitglue",
"content": "Pyflakes doesn't do that for simple variables. There's a test for what you propose:\n\nhttps://github.com/pyflakes/pyflakes/blob/1c9a81913bf29977489eb132e9f0103f6b07f62c/pyflakes/test/test_other.py#L343\n\nIt's skipped with the comment \"Too hard to make this warn but other cases stay silent\". I tried digging through the history to find where that's introduced. It's here:\n\nhttps://github.com/pyflakes/pyflakes/commit/3ef443aab87c436868746e7e855fb360eda8eaf8#diff-d18f55ece21d21fb172322f7db700d6aR164\n\nWhich, I think, is just an import from prehistory. So, it's a little hard to get the exact context that led to that decision, but it's been that way for a long time.\n\nThe reason, I suspect, is that this is pretty common:\n\nfoo = 'something'\nif condition:\n foo = 'something else'\n\nNow the problem becomes that pyflakes can't understand if \"condition\" is true or not. Currently, pyflakes just processes all conditional paths as if they were all taken. That means if you use a variable only sometimes, python counts it as used. So the code above, to pyflakes, might as well be:\n\nfoo = 'something'\nfoo = 'something else'\n\nThe example you pose, with \"for foo in maybe_empty_list\", is just another flavor of that, and while it isn't a common case, it is a case sometimes, and a valid one, and pyflakes assumes you know better, and if you really care about the correctness of your code you will write a unit test.\n\nSometimes people propose fancier logic than just taking all paths, but I think if you go down this road, you either end up with incomplete logic that's wrong sometimes, or you become a python interpreter. I'm certainly open to ideas though.",
"date_created": "2015-01-08T22:25:27Z"
},
{
"owner": "wsanchez",
"content": "Yeah I recognize that there are legit cases where you want tho do this intentionally, and I can't think of a reliable way to distinguish the two, or even recommend a way for developers to make the two distinguishable by making the intentional case explicitly so.\n\nThis request may be an overreach\u2026\n\nI just found myself making this mistake more than once in the same place because a for loop looks/feels like it has it's own little scope when of course it doesn't and thought maybe it could be caught somehow.\n",
"date_created": "2015-01-09T01:31:52Z"
},
{
"owner": "asmeurer",
"content": "Seeing this reminded me that I've actually used the idiom I mentioned above myself in real code: https://github.com/conda/conda/blob/7a15c907a305e4d0c16e80d819b9790cc5319778/conda/resolve.py#L501-L505.\n\nIn a sense, one could just as easily ask that pyflakes warn about the unused i\n\ni = 1\nfor i in something:\n ...\n\nas warning about a potentially undefined i in\n\nfor i in something:\n ...\nsomething_else(i)\n\nsince i will not be defined if something is empty.\n\nThat being said, if a variable is explicitly assigned to (not implicitly, like two consecutive loops), overridden by a loop, and not used again after the loop, I think a warning would be valid. ",
"date_created": "2015-06-15T22:02:15Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1408774",
"date_created": "2015-01-08T19:47:32Z"
},
{
"status": "New",
"security_related": false,
"description": "When locals() is encountered, unused variable detection is repressed.\nUse of locals() should cause a warning to occur, indicating that unused variable can not be detected.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jayvdb",
"id": 1507216,
"duplicate_of": null,
"title": "warn on locals()",
"comments": [
{
"owner": "icordasc",
"content": "I believe we used to do this but we stopped because a great deal of people complained.",
"date_created": "2015-10-19T14:00:19Z"
},
{
"owner": "bitglue",
"content": "I suppose another way to handle it would be to count any usage of locals() as having used all local variables. No warning.\n\nIt would make the decision easier to have references to real code in the wild for which this is a problem.",
"date_created": "2015-10-19T16:45:42Z"
},
{
"owner": "jayvdb",
"content": "> count any usage of locals() as having used all local variables. No warning.\n\nI believe this is the current behaviour...?\n\nIt was introduced in http://bazaar.launchpad.net/~pyflakes-dev/pyflakes/master/revision/64 , Jan 2013, by Domen Ko\u017ear\n\nThat was a very necessary improvement, as it removed false positives.\n\nHowever the use of locals() can be seen as a source of problems, as it prevents most tools from performing simple checks of code quality. That should be a separate warning IMO. Ideally in pyflakes as the analysis is already being done. If not, someone else needs to do it.\n\nThe python-hacking rule H501 covers some of this territory.\nhttps://github.com/openstack-dev/hacking/blob/master/hacking/checks/dictlist.py",
"date_created": "2015-10-19T20:15:28Z"
},
{
"owner": "icordasc",
"content": "As a core reviewer on hacking, that rule exists because the larger OpenStack community decided they wanted to enforce it. Hacking may be used by other projects, but is fundamentally a tool for enforcing OpenStack's community style guide for Python code.",
"date_created": "2015-10-19T20:24:12Z"
},
{
"owner": "bitglue",
"content": "Well, pyflakes as a matter of principle does not opine on matters of style. There are certainly uses of locals() which are valid, useful, and not horrible to read, like:\n\n \"%(local)s %(variable)s %(names)s\" % locals()\n\nThe closest precedent for complaining about locals() might be that pyflakes complains about \"import *\", but I would say that's not quite the same. locals() has no side effects and depends only on the local scope. \"import *\" has side effects that are not only implicit, but dependent on other files.",
"date_created": "2015-10-19T20:38:57Z"
},
{
"owner": "asmeurer",
"content": "It's also not uncommon to pass locals() to eval() or exec() (granted, those both break pyflakes anyway, but I don't think pyflakes should be bugging people just because they use eval). ",
"date_created": "2015-10-19T20:49:46Z"
},
{
"owner": "jayvdb",
"content": "> The closest precedent for complaining about locals() might be that\n> pyflakes complains about \"import *\"\n\nThis, and the pep257 warning regarding `__all__` being mutable, was the reason I raised this issue.\nThe pyflakes rule regarding unused variable is currently being silently repressed when locals() is used.\n\nBoth mean that static analysis in not possible by the tool with its current design/limitations.\n\nI can appreciate the scope is different, module vs function, but then pyflakes is making a decision on the importance of a rule based on the scope. When a module is mostly a large main(), the scope is irrelevant.",
"date_created": "2015-10-19T21:40:49Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1507216",
"date_created": "2015-10-17T22:10:09Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "The following script gives the pyflakes warning \"'Axes3D' imported but unused\". However, the import is necessary.\n\nfrom https://de.wikipedia.org/wiki/Matplotlib:\n```\nimport matplotlib.pyplot as plt\nimport numpy as np\nfrom matplotlib import cm\nfrom mpl_toolkits.mplot3d import Axes3D\nfig = plt.figure()\nax = fig.gca(projection='3d')\nX = np.arange(-5, 5, 0.25)\nY = np.arange(-5, 5, 0.25)\nX, Y = np.meshgrid(X, Y)\nR = np.sqrt(X**2 + Y**2)\nZ = np.sin(R)\nsurf = ax.plot_surface(X, Y, Z, rstride=1, cstride=1, cmap=cm.coolwarm)\nplt.show()\n```\n\nAs a workaround, I have added the line\n> assert Axes3D # suppress \"unused import\" warning\nafter the import, since \"# NOQA\" does not work (https://github.com/kevinw/pyflakes/issues/31).",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "robert-pollak",
"id": 1512632,
"duplicate_of": null,
"title": "False positive when importing Axes3D",
"comments": [
{
"owner": "bitglue",
"content": "Why is it necessary? Do you want it to be available in your module's namespace? Then you can reference it in __all__ to suppress the warning. Or do you just need to import it for some side effect? That's not a great design, but if you can't change that, then you should be able to `del Axes3D` to avoid the warning.\n\nDo either of these solutions work?",
"date_created": "2015-11-03T13:05:27Z"
},
{
"owner": "robert-pollak",
"content": "The import has the side effect to make the `projection='3d'` available.\nThe script works even when I `del Axes3D` directly after its import - so this suggestion does the job, thank you.",
"date_created": "2015-11-05T15:08:17Z"
}
],
"importance": "Wishlist",
"lp_url": "https://bugs.launchpad.net/bugs/1512632",
"date_created": "2015-11-03T09:37:52Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Binary package hint: pyflakes\n\nJust editing some file\n\nProblemType: Crash\nDistroRelease: Ubuntu 11.04\nPackage: pyflakes 0.4.0-1\nProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2\nUname: Linux 2.6.38-8-generic x86_64\nArchitecture: amd64\nDate: Wed Apr 20 22:17:49 2011\nExecutablePath: /usr/bin/pyflakes\nInstallationMedia: Ubuntu 11.04 \"Natty Narwhal\" - Beta amd64 (20110413)\nInterpreterPath: /usr/bin/python2.7\nPackageArchitecture: all\nProcCmdline: /usr/bin/python /usr/bin/pyflakes models_mongo_flymake.py\nProcEnviron:\n SHELL=/bin/bash\n LANG=ru_UA.UTF-8\n PATH=(custom, user)\n LANGUAGE=ru_UA:en\nPythonArgs: ['/usr/bin/pyflakes', 'models_mongo_flymake.py']\nSourcePackage: pyflakes\nTitle: pyflakes crashed with AttributeError in handleNode(): 'Checker' object has no attribute 'SET'\nUpgradeStatus: No upgrade log present (probably fresh install)\nUserGroups: adm admin cdrom dialout lpadmin plugdev sambashare",
"tags": [
"amd64",
"apport-crash",
"natty",
"running-unity"
],
"duplicates": [],
"assignee": "mithrandi",
"milestone": null,
"owner": "barry",
"id": 767570,
"duplicate_of": null,
"title": "pyflakes crashed with AttributeError in handleNode(): 'Checker' object has no attribute 'SET'",
"comments": [
{
"owner": "k-bx",
"content": "",
"date_created": "2011-04-20T19:51:37Z"
},
{
"owner": "barry",
"content": "I've not seen this before and can't reproduce it. Visual code inspection of the latest pyflakes doesn't match the traceback, and I can see where the SET attribute is getting created. I see no related bugs in the upstream tracker. Do you have a reproducible code example that illustrates this failure?",
"date_created": "2011-08-19T15:12:28Z"
},
{
"owner": "jimbaker",
"content": "I believe this comes up in the assignment of class variables in the Check class in checker.py. SET is not there, at least as of 0.4, and this may be related to the fact that PyFlakes does not support the AST for Python 2.7, as seen in constructs like dict comprehensions (with the DICTCOMP attribute), which raised the same AttributeError.\n\nYou can reproduce this error readily by running pyflakes on Ensemble source on trunk r321. Short discussion with respect to Ensemble in bug 829734.",
"date_created": "2011-08-19T23:34:25Z"
},
{
"owner": "exarkun",
"content": "I think this was fixed in r2667 (<http://bazaar.launchpad.net/~divmod-dev/divmod.org/trunk/revision/2667>) (which has not yet been released, and presumably isn't present in the Ubuntu package either). \r\n",
"date_created": "2011-08-20T20:53:05Z"
},
{
"owner": "barry",
"content": "Thanks for the reference JP. That revision can't be cleanly cherry picked into the 0.4.0 we have in Ubuntu. I suppose we have a few options, depending on what you want to do with upstream. I see 0.4.0 is pretty old - any chance you might release a new upstream version soon? If not, then we'd have to probably package up current bzr trunk, or work out the patch failure (in checker.py). Suggestions?",
"date_created": "2011-08-22T08:16:40Z"
},
{
"owner": "exarkun",
"content": "I think a new release is a great idea. I'll see if I can find someone to take care of it.",
"date_created": "2011-08-23T11:03:06Z"
},
{
"owner": "mithrandi",
"content": "This fix was included in pyflakes 0.5.0.",
"date_created": "2011-09-13T00:27:30Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/767570",
"date_created": "2011-08-19T15:26:27Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "The latest version available at https://launchpad.net/pyflakes/+download is 0.2.1.\nHowever, according to http://pypi.python.org/pypi/pyflakes, the latest version is 0.4.0.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jwilk",
"id": 783717,
"duplicate_of": null,
"title": "0.4.0 not available for download",
"comments": [
{
"owner": "glyph",
"content": "Yes, please download it from the python.org link.",
"date_created": "2011-05-16T22:21:37Z"
},
{
"owner": "glyph",
"content": "All downloads have now been removed from launchpad so there should be no further confusion.",
"date_created": "2011-05-16T22:22:30Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/783717",
"date_created": "2011-05-16T22:15:08Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "Would you guys be interested in moving to github? There is quite a lot of development there for pyflakes and it would make more sense to continue there (github is a much better place than launchpad for collaboration, IMHO).\n\nhttps://github.com/kevinw/pyflakes/pulls\ne.g.\nhttps://github.com/kevinw/pyflakes/pull/22\nhttps://github.com/kevinw/pyflakes/pull/23\n\nWhat do you think?",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "pinto-s",
"id": 954470,
"duplicate_of": null,
"title": "moving to github",
"comments": [
{
"owner": "glyph",
"content": "Moving to github would involve migration a portion of the lp:divmod.org source tree, ideally without losing history, and then somehow reconciling all the branches there, as well as somehow moving all the branches that exist _here_, both of the old mis-imported pyflakes bzr mirror of the now-defunct SVN repository and the proper branches of the lp:divmod.org repository for pyflakes features.\n\nThis is a lot of work and there aren't a lot of people who can dedicate time to working on Divmod stuff. For the time being I think it would be a better use of time to educate the github contributors about the relative equivalence between github pull requests and launchpad merge proposals; the tools are really not all that different.\n\nIf the people interested in contributing code can't even be bothered to learn to type \"bzr lp-submit\" then I suspect the code involved can't be of high enough quality to bother doing all the migration work for :).",
"date_created": "2012-03-26T00:18:19Z"
},
{
"owner": "exarkun",
"content": "There doesn't appear to be sufficient interest in this at the current time. To anyone who is interested in this, please feel free to re-open this issue! For now, I'm closing it to make the list of open bugs reflect the issues which people are actively interested in.",
"date_created": "2012-10-19T13:19:53Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/954470",
"date_created": "2012-03-13T21:23:37Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "\nThis is the code in question\n\ntry:\n if logger.isEnabledFor(logging.DEBUG): \n logger.debug(\"Writing buffer of %d byts\" % len(buf))\n pylibg15.write_pixmap(buf)\nexcept IOError as (errno, strerror): #<- Crashes on this line\n Slogger.error(\"Failed to send buffer. %d: %s\" % ( errno, strerror ) )\n traceback.print_exc(file=sys.stderr)\n self.disconnect()\n\nThis is the traceback.\n\nTraceback (most recent call last):\n File \"/usr/local/bin/pydbgr\", line 9, in <module>\n load_entry_point('pydbgr==0.1.5', 'console_scripts', 'pydbgr')()\n File \"/usr/local/lib/python2.7/dist-packages/pydbgr-0.1.5-py2.7.egg/pydbgr/cli.py\", line 337, in main\n normal_termination = dbg.run_script(mainpyfile)\n File \"/usr/local/lib/python2.7/dist-packages/pydbgr-0.1.5-py2.7.egg/pydbgr/debugger.py\", line 207, in run_script\n execfile(self.mainpyfile, globals_, locals_)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/run.py\", line 234, in <module>\n main()\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/run.py\", line 82, in main\n warnings += check_file(path, complexity)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/run.py\", line 27, in check_file\n warnings += pyflakes.checkPath(path)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 656, in checkPath\n return check(open(filename, 'U').read() + '\\n', filename)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 707, in check\n w = Checker(tree, filename)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 192, in __init__\n self._runDeferred(self._deferredFunctions)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 228, in _runDeferred\n handler()\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 571, in runFunction\n self.handleNode(stmt, node)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 299, in handleNode\n handler(node)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 277, in handleChildren\n self.handleNode(node, tree)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 299, in handleNode\n handler(node)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 277, in handleChildren\n self.handleNode(node, tree)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 299, in handleNode\n handler(node)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 277, in handleChildren\n self.handleNode(node, tree)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 299, in handleNode\n handler(node)\n File \"/usr/local/lib/python2.7/dist-packages/flake8-1.5-py2.7.egg/flake8/pyflakes.py\", line 340, in EXCEPTHANDLER\n name = node.name.id\nAttributeError: 'Tuple' object has no attribute 'id'\n\nI agree that this particular piece of code is VERY poor and only kind of works. But it's not my code, and pyflakes should handle it since it technically is valid syntax.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "psychicsurgeon",
"id": 1072171,
"duplicate_of": null,
"title": "pyflakes crashes on syntactically correct python syntax",
"comments": [
{
"owner": "florent.x",
"content": "With the trunk version I cannot reproduce the issue.",
"date_created": "2013-01-25T16:39:10Z"
},
{
"owner": "icordasc",
"content": "I can not reproduce this either.",
"date_created": "2013-02-02T18:56:02Z"
},
{
"owner": "florent.x",
"content": "released with 0.6.1",
"date_created": "2013-03-01T13:54:59Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1072171",
"date_created": "2012-10-27T18:55:28Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "pyflakes 0.5.0 fails in pyflakes.test.test_script.CheckTests.test_missingTrailingNewline on RHEL 6 / Python 2.6.6:\n\n===============================================================================\n[FAIL]: pyflakes.test.test_script.CheckTests.test_missingTrailingNewline\n\nTraceback (most recent call last):\n File \"/home/david/rpmbuild/BUILD/pyflakes-0.5.0/pyflakes/test/test_script.py\", line 38, in test_missingTrailingNewline\n self.assertFalse(checkPath(fName))\ntwisted.trial.unittest.FailTest: None\n-------------------------------------------------------------------------------\n\npyflakes was installed using pypi/pip:\n# pip-python install pyflakes\nDownloading/unpacking pyflakes\n Downloading pyflakes-0.5.0.tar.gz\n Running setup.py egg_info for package pyflakes\nInstalling collected packages: pyflakes\n Running setup.py install for pyflakes\n changing mode of build/scripts-2.6/pyflakes from 644 to 755\n changing mode of /usr/bin/pyflakes to 755\nSuccessfully installed pyflakes\nCleaning up...\n\nIf you need any more information, please ask for it.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "dejv",
"id": 1096481,
"duplicate_of": null,
"title": "\"trial pyflakes/test\" fails at test_missingTrailingNewline",
"comments": [
{
"owner": "dejv",
"content": "This doesn't apply to pyflakes/test from pip - those _do_ pass. What doesn't pass is pyflakes from backported fedora package - a downstream issue.",
"date_created": "2013-01-06T12:27:47Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1096481",
"date_created": "2013-01-05T23:47:46Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Passing a file including null bytes crashes pyflakes:\n\n$ printf '\\0' | pyflakes\nTraceback (most recent call last):\n File \"/usr/bin/pyflakes\", line 5, in <module>\n main(sys.argv[1:])\n File \"/usr/lib/python2.7/dist-packages/pyflakes/scripts/pyflakes.py\", line 94, in main\n warnings += check(sys.stdin.read(), '<stdin>')\n File \"/usr/lib/python2.7/dist-packages/pyflakes/scripts/pyflakes.py\", line 28, in check\n tree = compile(codeString, filename, \"exec\", _ast.PyCF_ONLY_AST)\nTypeError: compile() expected string without null bytes\n\nProblemType: Crash\nDistroRelease: Ubuntu 13.04\nPackage: pyflakes 0.5.0-2ubuntu1\nProcVersionSignature: Ubuntu 3.8.0-1.5-generic 3.8.0-rc4\nUname: Linux 3.8.0-1-generic x86_64\nNonfreeKernelModules: openafs\nApportVersion: 2.8-0ubuntu2\nArchitecture: amd64\nDate: Thu Jan 24 16:11:36 2013\nEcryptfsInUse: Yes\nExecutablePath: /usr/bin/pyflakes\nInstallationDate: Installed on 2010-12-05 (781 days ago)\nInstallationMedia: Ubuntu 11.04 \"Natty Narwhal\" - Alpha amd64 (20101202)\nInterpreterPath: /usr/bin/python2.7\nMarkForUpload: True\nPackageArchitecture: all\nProcCmdline: /usr/bin/python /usr/bin/pyflakes\nPythonArgs: ['/usr/bin/pyflakes']\nSourcePackage: pyflakes\nTitle: pyflakes crashed with TypeError in check(): compile() expected string without null bytes\nUpgradeStatus: Upgraded to raring on 2012-11-15 (70 days ago)\nUserGroups: adm admin cdrom dialout fuse libvirtd lpadmin plugdev sambashare sudo wireshark",
"tags": [
"amd64",
"apport-crash",
"raring"
],
"duplicates": [],
"assignee": null,
"milestone": "0.7.3",
"owner": "xnox",
"id": 1104455,
"duplicate_of": null,
"title": "pyflakes crashed with TypeError in check(): compile() expected string without null bytes",
"comments": [
{
"owner": "andersk",
"content": "",
"date_created": "2013-01-24T21:13:05Z"
},
{
"owner": "florent.x",
"content": "It seems it is no longer an issue with Pyflakes 0.7.3\r\n\r\n\r\n$ pyflakes --version\r\n0.7.3\r\n$ printf '\\0' | pyflakes\r\n<stdin>: problem decoding source",
"date_created": "2014-03-22T15:17:27Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1104455",
"date_created": "2013-08-04T21:44:46Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "sometimes people use return instead of raise, Errors dont tend to be something one will return, warn them",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "ronny-pfannschmidt-deactivatedaccount",
"id": 1105528,
"duplicate_of": null,
"title": "warn when returning Exceptions instead of Raising them",
"comments": [
{
"owner": "icordasc",
"content": "@ronny, might this be better suited in a different tool? Exceptions are objects and as such can be returned. Should we really attempt to guess the user's intention and bug them about using return instead of raise?",
"date_created": "2013-02-02T18:46:26Z"
},
{
"owner": "ronny-pfannschmidt-deactivatedaccount",
"content": "i think it would still make for a nice opt-in",
"date_created": "2013-02-03T23:58:10Z"
},
{
"owner": "exarkun",
"content": "The goal of pyflakes is to only report code problems that are definitely spurious or introduce bugs.\n\nThere's no way to know whether a particular object is supposed to be returned or raised. Just like there's no way to know if a particular statement should be \"if foo:\" or \"if not foo:\".\n",
"date_created": "2013-11-03T13:51:44Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1105528",
"date_created": "2013-01-25T23:18:25Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "In debian we would like to ship co-installable python2 and python3 versions of pyflakes.\nThis brings the question of what to do with the scripts.\nCurrently we only have:\n/usr/bin/pyflakes with default python2.X interpreter.\n\nWhat should we do:\na) /usr/bin/py3flakes\nb) /usr/bin/pyflakes3\nc) ship __main__.py in pyflakes module and make people use similar to unittest, e.g. python3.x -m pyflakes . (thus avoiding shipping scripts all together)\n\nPlease let us know your thoughts on this.\n\nRegards,\n\nDmitrijs.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "xnox",
"id": 1132892,
"duplicate_of": null,
"title": "default name for co-installed python2 & python3 pyflakes",
"comments": [
{
"owner": "xnox",
"content": "I believe in debian we are settling for py3flakes, because of other similar python helper commands that use \"py\" as python2 prefix, and \"py3\" as python3 prefix.",
"date_created": "2013-02-25T18:22:54Z"
},
{
"owner": "icordasc",
"content": "This can be done like so: https://bitbucket.org/tarek/flake8/issue/85/set-up-version-specific-installations\n\nIt would create two binaries, `pyflakes` and `pyflakes-3.2` (for example). Would this be satisfactory for debian?",
"date_created": "2013-02-25T18:50:52Z"
},
{
"owner": "morph-debian",
"content": "@xnox \"in Debian\" it's actually good to ask the opinion of the people who has their name next to the package - which you fail to do all the time. How about talk to package uploaders first?",
"date_created": "2013-02-25T19:07:17Z"
},
{
"owner": "xnox",
"content": "@Sandro Tosi\nThe specific naming has been discussed extensively with the debian python team DDs on #debian-python.\nPlease, lets continue that discussion in the team's communication.",
"date_created": "2013-02-25T19:54:05Z"
},
{
"owner": "xnox",
"content": "@ Ian\nyes and no, we also want to avoid gaining an explicit dependency on each python3.X package at build-time, when later python3.X+1 can become default thus requiring an useless no-change upload to fix up the dependencies.\n\nThis is more for the name of the script that will have /usr/bin/python3 shebang and that should be stable (e.g. point to default python3 version regardless of which exact version that symlink points to)",
"date_created": "2013-02-25T19:58:11Z"
},
{
"owner": "morph-debian",
"content": "I am a dd, and I'm one (for the time being) of the maintainer of pyflakes, and I was not involved *at all* in those discussion, and I bet nor of the other maintainers. sure keep discussing it whatever you want, that doesn't change the fact you're not involving any of the real people doing maintenance work on the package - well done",
"date_created": "2013-02-25T20:22:51Z"
},
{
"owner": "dobey",
"content": "Why would both versions need to be installed? It would seem fine to me to just ship the version that uses python3 only, once python3 support in pyflakes is stable, and one that uses python2 prior to that.\n\nI don't see any reason to ship two conflicting versions of the script.",
"date_created": "2013-02-25T20:32:27Z"
},
{
"owner": "dobey",
"content": "Nevermind. Florent just pointed out the fact that the AST parsing will give inconsistent results if parsing code written for Python 2 is done inside a pyflakes running under python3.\n",
"date_created": "2013-02-25T20:50:04Z"
},
{
"owner": "dobey",
"content": "Given all this, I think one of the following would be the best choice, for creating consistency across projects which need to install multiple scripts for different Python versions, and to clarify that it's for Python 3 instead of Python 2:\n\n1) pyflakes-py3\n2) py3-pyflakes\n\nGoing with the former would probably be better, as prefixing everything with py3- could create an undesirable amount of scripts showing up when trying to tab complete a command.",
"date_created": "2013-02-25T20:54:40Z"
},
{
"owner": "xnox",
"content": "We have many packages in the archive that build-depend on pyflakes and run it at build-time.\nRecent pyflakes behaves differently depending on whether it's invoked with python3 vs python2 interpreter and thus if /usr/bin/pyflakes shebang is suddently changes to python3 many packages will start failing their python2 portion of the builds.\nSure enough we can demand as a policy to invoke pyflakes as pythonX.Y /usr/bin/pyflakes when run during builds, but it's a new not strictly needed change. Many people want a py3 default script to manually invoke from command line using a sensible/easy tab completion.",
"date_created": "2013-02-25T21:05:15Z"
},
{
"owner": "xnox",
"content": "@dobey\nBTW we already have:\n- py3clean py3compile py3_compilefiles py3versions\n- py.test-3 pygettext3 pydoc3\n\nA mixture of everything! *sigh*",
"date_created": "2013-02-25T21:33:53Z"
},
{
"owner": "icordasc",
"content": "So in spite of the squabble here, the typical way that python developers manage this is as I described. How Debian and Ubuntu manages this, I believe, belongs in a separate discussion that is not here. That is more of a packaging issue than a pyflakes issue with all due respect.",
"date_created": "2013-02-25T22:30:28Z"
},
{
"owner": "florent.x",
"content": "Pursue the debate on <email address hidden> if needed. Thanks.",
"date_created": "2013-04-23T09:14:43Z"
},
{
"owner": "barry",
"content": "FWIW, I don't like the pyfoo/py3foo varieties because it makes it harder to locate(1).\n\nI just started a thread on python-dev for a general recommendation on the subject, perhaps leading to an informational PEP. Also, I just committed to Debian svn naming it pyflakes3. Yay for consistency.",
"date_created": "2013-05-24T20:10:05Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1132892",
"date_created": "2013-02-25T17:02:38Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "======================================================================\nFAIL: test_invalidEscape (pyflakes.test.test_api.CheckTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File \"/home/tdlk/personal-src/python/python-apps/packages/pyflakes/build-area/pyflakes-0.6.1/pyflakes/test/test_api.py\", line 414, in test_invalidEscape\n sourcePath, [decoding_error])\n File \"/home/tdlk/personal-src/python/python-apps/packages/pyflakes/build-area/pyflakes-0.6.1/pyflakes/test/test_api.py\", line 263, in assertHasErrors\n (count, err.getvalue()), (len(errorList), ''.join(errorList)))\nAssertionError: Tuples differ: (1, \"/tmp/tmpuzz1ow:1: (unicod... != (1, \"/tmp/tmpuzz1ow:1: (unicod...\n\nFirst differing element 1:\n/tmp/tmpuzz1ow:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-1: truncated \\xXX escape\nfoo = '\\xyz'\n ^\n\n/tmp/tmpuzz1ow:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \\xXX escape\nfoo = '\\xyz'\n ^\n\n\n (1,\n- \"/tmp/tmpuzz1ow:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-1: truncated \\\\xXX escape\\nfoo = '\\\\xyz'\\n ^\\n\")\n? ^\n\n+ \"/tmp/tmpuzz1ow:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \\\\xXX escape\\nfoo = '\\\\xyz'\\n ^\\n\")\n? ^\n\n\n----------------------------------------------------------------------\nRan 221 tests in 0.314s\n\nFAILED (failures=1, skipped=8)\n\n\nWhen run as:\npython3.3 -m unittest discover",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "xnox",
"id": 1132910,
"duplicate_of": null,
"title": "py3flakes test suite failure",
"comments": [
{
"owner": "florent.x",
"content": "Thanks for the report.\n\nIt's weird that this failure was not seen on the Travis builder https://travis-ci.org/pyflakes/pyflakes/builds/4454384\nThe difference is that it uses the unittest2/unittest2py3k packages to use the same features for older versions of Python.\n\nI just did the \"python -m unittest discover\" in a checkout of the repository, with Python 3.3, and no failure.\n",
"date_created": "2013-02-25T18:33:22Z"
},
{
"owner": "xnox",
"content": "Ok, I may have not given the full-details here then.\nAs I also have a patch applied to use python3.3's unittest instead of unittest2py3k, on ubuntu python3.3 is the default now and 3.3 or better will be the default in jessie. Hence I see no reason why unittest2py3k is needed in ubuntu/debian distributions. (I understand why it's useful from upstream point of view to use unittest2py3k as one gets all pythons support across the board).",
"date_created": "2013-02-25T20:04:25Z"
},
{
"owner": "xnox",
"content": "I will experiment further to see, if the test failure was self induced.",
"date_created": "2013-02-25T20:05:13Z"
},
{
"owner": "florent.x",
"content": "worksForMe.\r\n\r\nPlease re-open if you have more details.",
"date_created": "2013-03-30T16:27:00Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1132910",
"date_created": "2013-02-25T18:03:27Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Current pylfakes 0.6.1 doesn\u2019t recognize Python 3.3\u2019s \"yield from\" syntax:\n\n# test.py\ndef spam():\n yield from range(10)\n\n\nstefan@nboffis28:/tmp/test\u263f$ pyflakes test.py \ntest.py:2: invalid syntax\n yield from range(10)\n ^",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "sscherfke",
"id": 1134476,
"duplicate_of": null,
"title": "Support for \"yield from\"",
"comments": [
{
"owner": "florent.x",
"content": "This works as designed.\r\n\r\nIf you need to check code compatible with 3.3 only, you need to install pyflakes in Python3.3 (in a virtualenv).",
"date_created": "2013-02-27T16:20:17Z"
},
{
"owner": "sscherfke",
"content": "Thanks, that works.",
"date_created": "2013-02-28T08:49:51Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1134476",
"date_created": "2013-02-27T15:45:41Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "\nThe \"redefinition of unused variable\" is not always reported.\n\n\nThis code reports the error:\n\n def moo():\n pass\n \n moo = 42\n\n\n\nBut this one does not:\n\n moo = 42\n \n def moo():\n pass",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "florent.x",
"id": 1147472,
"duplicate_of": null,
"title": "redefinition not always detected",
"comments": [
{
"owner": "florent.x",
"content": "It seems to be a deliberate choice.\r\n\r\nIf we change it, it breaks a few test cases.\r\n\r\n - test_import.test_ignoreNonImportRedefinitions\r\n a = 1; a = 2\r\n\r\n - test_other.test_doubleAssignmentConditionally\r\n x = 10\r\n if True: x = 20\r\n\r\n - test_other.test_redefinedInListComp\r\n a = 1\r\n [1 for a, b in [(1, 2)]]",
"date_created": "2013-03-06T22:28:56Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1147472",
"date_created": "2013-03-05T18:44:14Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "The following fails in pyflakes with \"undefined name '_foo'\" even though it is always defined before use:\n\ndef _init_globals():\n global _foo, _bar, _snafu\n _foo = 42\n _bar = \"string\"\n _snafu = 3.14\n_init_globals()\n\n# lots of other stuff\n\ndef reset():\n # reset other stuff\n _init_globals()",
"tags": [
"wishlist"
],
"duplicates": [
1195691
],
"assignee": null,
"milestone": null,
"owner": "gregcouch",
"id": 1158585,
"duplicate_of": null,
"title": "please support reinitialization idiom",
"comments": [
{
"owner": "ronny-pfannschmidt-deactivatedaccount",
"content": "this pattern pretty much abuses a module as object,\n\nim -10 on supporting it\n\nbecause\n a) it needs much deeper analysis and\n b) its quite ugly to reason about",
"date_created": "2013-03-22T07:54:25Z"
},
{
"owner": "gregcouch",
"content": "Your abuse is my eliminating redundant code. And modules are excellent\nsingleton objects.\n\nI don't know the pyflakes code, but seems that the fix would not be\ndifficult. Pyflakes is already tracking assignment to variables, and the\nfact that the variables are globals should be accessible. Since pyflakes\ndoesn't run the code, there still could be false positives, but there would\nbe fewer.\n\nAnother way to fix the problem is with an annotation in a comment. That\nwould be a much bigger project, but I'm sure your considering doing that to\nsuppress other false positives and extend pyflakes usefulness.\n\n Good luck,\n\n Greg\n\nOn Fri, Mar 22, 2013 at 12:54 AM, ronny <email address hidden> wrote:\n\n> this pattern pretty much abuses a module as object,\n>\n> im -10 on supporting it\n>\n> because\n> a) it needs much deeper analysis and\n> b) its quite ugly to reason about\n>\n> --\n> You received this bug notification because you are subscribed to the bug\n> report.\n> https://bugs.launchpad.net/bugs/1158585\n>\n> Title:\n> please support reinitialization idiom\n>\n> Status in Pyflakes:\n> New\n>\n> Bug description:\n> The following fails in pyflakes with \"undefined name '_foo'\" even\n> though it is always defined before use:\n>\n> def _init_globals():\n> global _foo, _bar, _snafu\n> _foo = 42\n> _bar = \"string\"\n> _snafu = 3.14\n> _init_globals()\n>\n> # lots of other stuff\n>\n> def reset():\n> # reset other stuff\n> _init_globals()\n>\n> To manage notifications about this bug go to:\n> https://bugs.launchpad.net/pyflakes/+bug/1158585/+subscriptions\n>\n",
"date_created": "2013-03-26T05:27:26Z"
},
{
"owner": "ronny-pfannschmidt-deactivatedaccount",
"content": "function analysis must happen after analysis of the global scope, so its already too late\n\nannotation comments are not usable when using the normal python ast (and not desirable, if the tool allows to be configured for messy, people will)\n\nas far as i can tell your hard to test and hard to reason about convenience pattern would need something like propper abstract interpretation to be handled sanely\n\nso imho it goes far out of the scope of pyflakes (which is a simple ast checker)",
"date_created": "2013-03-26T06:53:49Z"
},
{
"owner": "florent.x",
"content": "FWIW, this is probably not worse than the initial proposal (and it is readable, and it makes pyflakes happy).\n\n_foo = 42\n_bar = \"string\"\n_snafu = 3.14\n\n__globals = [(k, v) for (k, v) in globals().items() if k in ('_foo', '_bar', '_snafu')]\n\n# lots of other stuff\n\ndef reset():\n\u00a0\u00a0\u00a0\u00a0\u00a0# reset other stuff\n g = globals()\n for (k, v) in __globals:\n g[k] = v",
"date_created": "2013-03-30T17:02:00Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1158585",
"date_created": "2013-03-22T00:32:24Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Pyflakes doesn't know anything about new Python 3.3 exceptions, and report W802 about them. There are a bunch of new exception base classes.\n\nSee http://docs.python.org/3.3/library/exceptions.html#os-exceptions for an exhaustive list. The offending code (which is not, really):\n\n try:\n os.unlink(self.filename)\n\n except FileNotFoundError:\n LOGGER.warning(_('Our lockfile %s disappeared!'), self.filename)",
"tags": [],
"duplicates": [
1170939,
1200434,
1217296,
1267401,
1269743,
1318497
],
"assignee": null,
"milestone": null,
"owner": "olive",
"id": 1169552,
"duplicate_of": null,
"title": "FileNotFoundError and other new Python 3.3 exceptions are not supported",
"comments": [
{
"owner": "florent.x",
"content": "Hello,\r\n\r\nif you run Pyflakes with Python 3.3, you don't get these errors.\r\n\r\nUsually you need to run Pyflakes with the same version of Python which is supported by your application.\r\nIf not, the result might be inaccurate.",
"date_created": "2013-04-16T17:10:35Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1169552",
"date_created": "2013-04-16T12:49:42Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Heat's pyflakes-bypass.py monkey patches pyflakes checker.report() method:\n\n https://github.com/openstack/heat/blob/feb98c5/tools/pyflakes-bypass.py\n\nWith pyflakes 0.7, this has stopped working:\n\n File \"tools/pyflakes-bypass.py\", line 6, in report_with_bypass\n text_lineno = args[0] - 1\n TypeError: unsupported operand type(s) for -: 'Name' and 'int'\n\nThis is the pyflakes change which caused it:\n\n http://bazaar.launchpad.net/~pyflakes-dev/pyflakes/master/revision/86#pyflakes/checker.py\n\nIt works fine with pyflakes 0.6.1",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "markmc",
"id": 1171420,
"duplicate_of": null,
"title": "Unit tests fail with pyflakes 0.7",
"comments": [
{
"owner": "markmc",
"content": "Adding to the pyflakes project in case this was unintentional\n\nA valid response is \"WontFix, monkey patching checker.report() isn't part of our public API\"\n\nIf that's the case, heat should probably stop monkey patching it :)",
"date_created": "2013-04-22T11:26:16Z"
},
{
"owner": "hudson-openstack",
"content": "Fix proposed to branch: master\nReview: https://review.openstack.org/27256",
"date_created": "2013-04-22T11:30:02Z"
},
{
"owner": "zaneb",
"content": "This is definitely not broken in PyFlakes, and a more defensive monkey-patch would not have had any issue.",
"date_created": "2013-04-22T12:52:56Z"
},
{
"owner": "hudson-openstack",
"content": "Fix proposed to branch: master\nReview: https://review.openstack.org/27274",
"date_created": "2013-04-22T16:41:04Z"
},
{
"owner": "hudson-openstack",
"content": "Fix proposed to branch: master\nReview: https://review.openstack.org/27284",
"date_created": "2013-04-22T18:05:44Z"
},
{
"owner": "hudson-openstack",
"content": "Reviewed: https://review.openstack.org/27274\nCommitted: http://github.com/openstack/heat/commit/78f0da46f21f2dcba2c69e782ad61be061012835\nSubmitter: Jenkins\nBranch: master\n\ncommit 78f0da46f21f2dcba2c69e782ad61be061012835\nAuthor: Zane Bitter <email address hidden>\nDate: Mon Apr 22 18:24:56 2013 +0200\n\n Fix pyflakes-bypass for PyFlakes 0.7\n \n Don't make assumptions about argument types, get the line number from the\n message object.\n \n Fixes bug #1171420\n \n Change-Id: Id0b1b254a1561941dea8ab5bb23aea1f936e7f0b\n",
"date_created": "2013-04-23T10:31:04Z"
},
{
"owner": "hudson-openstack",
"content": "Reviewed: https://review.openstack.org/27284\nCommitted: http://github.com/openstack/heat/commit/7ce9a214f0d090fcbb59d59524b152b72fe6fce2\nSubmitter: Jenkins\nBranch: master\n\ncommit 7ce9a214f0d090fcbb59d59524b152b72fe6fce2\nAuthor: Clint Byrum <email address hidden>\nDate: Mon Apr 22 11:03:18 2013 -0700\n\n Remove pyflakes_bypass\n \n There are valid pythonic ways to address all of the complaints that\n pyflakes made in the past.\n \n Fixes bug #1171420\n \n Change-Id: Idf145185ebb4df237fff887365fa0c48d3603025\n",
"date_created": "2013-04-30T09:00:09Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1171420",
"date_created": "2013-04-22T11:25:04Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "I'd like to use pyflakes across some things that I work on but some of the checks really are more style related rather than actual syntax errors. eg, \"imported but unused\" won't cause problems.\n\nWould there be interest in being able to filter the list of reported problems at runtime? I'll work on it if there's interest; it should be pretty straight-forward to add and keep the default behavior the same of reporting all problems",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "katzj",
"id": 1192697,
"duplicate_of": null,
"title": "Support for enabling/disabling checks",
"comments": [
{
"owner": "asmeurer",
"content": "You could filter out warnings and errors. This separation is already done in the current code (e.g., unused variable is a warning, undefined variable is an error). ",
"date_created": "2013-06-20T02:56:49Z"
},
{
"owner": "florent.x",
"content": "Hello Jeremy,\r\n\r\nyou should have a look to Flake8, it is a small wrapper utility around Pyflakes and some other linting tools, and it does exactly what you describes.\r\nhttp://flake8.readthedocs.org/en/latest/\r\nhttp://flake8.readthedocs.org/en/latest/warnings.html\r\n\r\nWe don't have a plan to add this feature to Pyflakes itself.",
"date_created": "2013-06-20T07:07:21Z"
},
{
"owner": "katzj",
"content": "That's actually how I ended up thinking about pushing it into pyflakes itself -- while flake8 can filter in or out all pyflakes messages, it doesn't actually filter specific ones right now. And I can continue the monkey patching there but it seems like something that would be useful in the pyflakes command line tool itself.",
"date_created": "2013-06-20T14:52:21Z"
},
{
"owner": "adiroiban",
"content": "In flake8 documentation I read that flake8 patches pyflakes to add unique codes.\n\nWhy not add support for unique codes in pyflakes and why you prefer to path it in flake8?\n",
"date_created": "2013-10-09T14:34:01Z"
},
{
"owner": "jayvdb",
"content": "flake8 has distinct codes for pyflakes errors and warnings\nhttps://flake8.readthedocs.org/en/latest/warnings.html\n\ne.g. F401 is \"module imported but unused\", so it can be excluded.\n\nAlso I have created a flake8 plugin which allows per-file and per-line control of the codes reported : https://pypi.python.org/pypi/flake8-putty\n\nI recommend this should be Wont Fixed.",
"date_created": "2015-12-17T06:10:58Z"
},
{
"owner": "bitglue",
"content": "I'm afraid the lack of a way to disable checks is an intentional design decision. As others have said, flake8 does add this functionality.\n\nAlso, if you are not aware, listing names in __all__ will count them as used. That covers the most common use case where people are importing names (frequently in __init__.py) only to include them in the namespace for other modules to import.",
"date_created": "2015-12-19T02:41:03Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1192697",
"date_created": "2013-06-19T20:12:56Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "When an import is done in a try block and it is redefined in the except clause, pyflakes generates an error claiming a redefinition of an unused variable. This shouldn't be an error because the redefinition occurs when the import fails.\n\nThe following code:\n\ntry:\n import cPickle as pickle\nexcept ImportError:\n import pickle\n\ngenerates the following error:\ntwisted/mail/relaymanager.py:21: redefinition of unused 'pickle' from line 19",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "staceysern",
"id": 1247578,
"duplicate_of": null,
"title": "Erroneous redefinition error for import in try/except",
"comments": [
{
"owner": "florent.x",
"content": "Hello,\r\n\r\nI cannot reproduce this issue with Pyflakes 0.7.3.\r\n\r\n== sample.py ==\r\n\r\ntry:\r\n import cPickle as pickle\r\nexcept ImportError:\r\n import pickle\r\n\r\n\r\ndata = pickle.dumps(None)\r\n",
"date_created": "2014-01-17T03:23:44Z"
},
{
"owner": "staceysern",
"content": "In Twisted, this code generated an error on a branch that has since been merged into trunk (http://buildbot.twistedmatrix.com/builders/pyflakes/builds/1366/steps/pyflakes/logs/new%20pyflakes%20errors). The current trunk branch with that same code does not generate the error.\n",
"date_created": "2014-01-28T01:01:34Z"
},
{
"owner": "florent.x",
"content": "I guess the buildbot was using an ancient version of Pyflakes on this branch, while the trunk is using the latest version.\r\n\r\nThe module does not trigger this error:\r\nhttps://github.com/twisted/twisted/blob/relay-doc-6739/twisted/mail/relaymanager.py",
"date_created": "2014-01-28T07:35:26Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1247578",
"date_created": "2013-11-03T12:59:21Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "In Twisted code, pyflakes warns of the following redefinition:\n\n self._download('NLST ', chainDeferred=d)\n def checkDownload(download):\n filenames = download[:2].split('\\r\\n')\n filenames.sort()\n self.assertEqual(['bar', 'foo'], filenames)\n d.addCallback(checkDownload)\n\ntwisted/test/test_ftp.py:796: redefinition of function 'checkDownload' from line 790\n\nso clearly it's used before it's redefined elsewhere.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "cc-4",
"id": 1248170,
"duplicate_of": null,
"title": " redefinition errors should be suppressed if a function is used before being redefined ",
"comments": [
{
"owner": "florent.x",
"content": "Hi,\r\n\r\nplease could you provide a concrete (small) case to reproduce the issue.\r\n\r\nThank you.\r\n\r\n\r\n== works_for_me.py ==\r\n\r\ndef main():\r\n d = 123\r\n def foo(bar):\r\n pass\r\n\r\n d.add_callback(foo)\r\n def foo(bar):\r\n pass\r\n",
"date_created": "2014-01-17T09:46:36Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1248170",
"date_created": "2013-11-05T13:02:33Z"
},
{
"status": "Incomplete",
"security_related": false,
"description": "import foo.bar.baz\nbaz.blah()\n\nfoo/bar/__init__.py:1: 'foo' imported but unused\nfoo/bar/__init__.py:2: undefined name 'baz'",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "spaceone",
"id": 1270169,
"duplicate_of": null,
"title": "package imports \u2192 undefined name",
"comments": [
{
"owner": "florent.x",
"content": "hello,\r\n\r\nyour import looks weird, btw. I believe it's wrong.\r\n\r\nIMHO it should read:\r\n\r\nfrom foo.bar import baz\r\nbaz.blah()\r\n",
"date_created": "2014-01-19T17:05:02Z"
},
{
"owner": "spaceone",
"content": "That does not work because you are in foo/bar/__init__.py.\nMy example is fully valid python2 (and the only way i know to do this).\n\nTo setup a testennvironment run these command (linux):\n\nmkdir -p foo/bar/baz;\ntouch foo/{,bar/,bar/baz/}__init__.py\n\necho \"def test(): print 'TEST OK'\" > foo/bar/baz/__init__.py\necho \"import foo.bar.baz; baz.test()\" > foo/bar/__init__.py\n\nthen run it:\n$ python2\n>>> import foo\n>>> import foo.bar\nTEST OK\n>>>\n\nThere is no other way to do this.\nChanging the line to import foo.bar.baz as baz ends in this error:\nAttributeError: 'module' object has no attribute 'bar'",
"date_created": "2014-01-19T21:55:37Z"
},
{
"owner": "asmeurer",
"content": "But the problem is that if you do `import foo.bar.baz`, then the name `baz` is not defined. You have to access it as `foo.bar.baz`. ",
"date_created": "2014-01-19T22:07:55Z"
},
{
"owner": "spaceone",
"content": "No, thats wrong. You can access baz because you are in bar's context. It is appended to the local scope. (you cann see this in the example i wrote).",
"date_created": "2014-01-19T22:17:31Z"
},
{
"owner": "florent.x",
"content": "Even if your syntax is valid, I still believe it is not the recommended way to do it.\nIt is counter-intuitive, at least:\n\n>>> import foo.bar\n>>> 'bar' in dir()\nFalse\n>>> import foo.bar.baz\n>>> 'bar' in dir()\nFalse\n\n\nThe example you give in comment #2 should be changed to one of these syntaxes:\n\n== foo/bar/__init__.py (proposition A) ==\n\nfrom foo.bar import baz\nbaz.test()\n\n\n== foo/bar/__init__.py (proposition B) ==\n\nfrom . import baz\nbaz.test()\n\n\nBoth propositions A and B are valid in Python 2/3 and they are the \"right way to do it\"\u2122.",
"date_created": "2014-01-19T22:17:53Z"
},
{
"owner": "spaceone",
"content": "And you cannot use foo.bar.baz because this does not exists because the module is not yet appended to foo.bar;\n\n$ cat foo/bar/__init__.py \nimport foo.bar.baz\n\nbaz.test()\nfoo.bar.baz.test()\n\n$ python\n>>> import foo\nTEST OK\nTraceback (most recent call last):\n File \"<stdin>\", line 1, in <module>\n File \"./foo/__init__.py\", line 1, in <module>\n import foo.bar\n File \"./foo/bar/__init__.py\", line 4, in <module>\n foo.bar.baz.test()\nAttributeError: 'module' object has no attribute 'bar'\n\nWith the first line i can access the function, the other one not!",
"date_created": "2014-01-19T22:20:34Z"
},
{
"owner": "bitglue",
"content": "I can't decide if this is a legitimate thing to do, or something that just happens to work due to some bug or implementation detail in cPython.\n\nThe language specification <https://docs.python.org/2/reference/simple_stmts.html#the-import-statement> doesn't seem to be much help. It talks a lot about how the import statement finds the thing to import, but then step 2, binding it to some local variables, there's pretty much no detail. I don't see anywhere in that specification to *what* local variables anything is bound in the case of your example.\n\nThe official language tutorial <https://docs.python.org/2/tutorial/modules.html#packages>, while perhaps not normative, does give this example:\n\n'''\nUsers of the package can import individual modules from the package, for example:\n\nimport sound.effects.echo\n\nThis loads the submodule sound.effects.echo. It must be referenced with its full name.\n\nsound.effects.echo.echofilter(input, output, delay=0.7, atten=4)\n\nAn alternative way of importing the submodule is:\n\nfrom sound.effects import echo\n\nThis also loads the submodule echo, and makes it available without its package prefix, so it can be used as follows:\n\necho.echofilter(input, output, delay=0.7, atten=4)\n'''\n\nPhrased in the terms of your example, it doesn't say anything about how one might do \"import foo.bar.baz\" and end up with \"baz\" defined. But as your test environment demonstrates, and I've been able to reproduce, it does.\n\nCan you cite any normative references that provide additional clarity?",
"date_created": "2015-06-10T02:24:22Z"
},
{
"owner": "asmeurer",
"content": "Dave Beazley mentioned this in his modules tutorial (https://www.youtube.com/watch?v=0oTh1CXRaQ0, see around 32:00 or so; I recommend watching the whole thing if you can find the time). The gist of it is that because echo is a sub-module/package of sound.effects, you can type sound.effects.echo. The way that Python implements this is by literally putting \"echo\" in the namespace of sound.effects (i.e., its __init__.py). That's why import foo.bar.baz pulls in the name \"baz\" **in foo/baz/__init__.py**.\n\nDave doesn't touch on this any more than that once in his tutorial as I recall, so you may want to look for some more references on how the import system works if it's still unclear. ",
"date_created": "2015-07-03T04:13:32Z"
},
{
"owner": "icordasc",
"content": "So this also works on 3.4 (which makes me assume it has worked on prior 3.x versions) but I haven't tested 3.5. Further if you toss a \n\n print(globals())\n\nInto foo/bar/__init__.py, you'll see very clearly that `baz` is defined as the submodule.\n\nWhile I don't think this is conventional python or even common to see, it makes sense to support. For what it's worth, I would expect something more akin to\n\n from . import baz\n\nInside foo/bar/__init__.py instead of\n\n import foo.bar.baz\n\nThat said, I know many people follow the Google Styleguide and have linters that enforce that meaning they have to use the latter.",
"date_created": "2015-07-03T13:54:17Z"
},
{
"owner": "spaceone",
"content": "The use of \n from . import baz\ninstead of\n import foo.bar.baz\n\nis not practicable/considerable:\nIt is not possible to use the \"if __name__ == '__main__'\" -feature then to call that script also directly. It breaks with:\n\"ValueError: Attempted relative import in non-package\"\n\n@asmeurer\nyes, i watched the whole tutorial",
"date_created": "2015-10-08T09:53:24Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1270169",
"date_created": "2014-01-17T14:35:53Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "I'm using pyflakes 0.7.3 and it does not handle the print function in Python 2 code with print_function imported from __future__. But that would really be useful for code that is written in both Python 2(.7) & Python 3",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "juliank",
"id": 1293225,
"duplicate_of": null,
"title": "Please handle from __future__ import print_function",
"comments": [
{
"owner": "florent.x",
"content": "If your code is compatible with Python 3, the best choice is to run Pyflakes with Python 3 too.",
"date_created": "2014-03-22T16:35:37Z"
},
{
"owner": "juliank",
"content": "Sorry, it seems to work. We just had some script in the tree which is Python-3-only and thus does not have a future import, which caused this to fail with pyflakes (2).\r\n",
"date_created": "2014-03-22T17:12:08Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1293225",
"date_created": "2014-03-16T20:48:21Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Twisted has a py files which is generated using an external tool. This generated file is not pyflakes compatible.\n\nAlso in twisitedchecker project there are some functional tests which are broken on purpose and should be excluded from pyflakes check.\n\nEach project could copy the pyflakes/api.py file and modify checkRecursive method but this will lead to a lot of code duplication.\n\nI already have the code used for twistedchecker and will send a pull request.\n\nThanks!",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "adiroiban",
"id": 1311129,
"duplicate_of": null,
"title": "Except files based on regex",
"comments": [
{
"owner": "adiroiban",
"content": "Code is here https://github.com/pyflakes/pyflakes/pull/1\n\nThanks!",
"date_created": "2014-04-22T14:19:26Z"
},
{
"owner": "adiroiban",
"content": "People can use flake8",
"date_created": "2014-04-26T13:03:02Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1311129",
"date_created": "2014-04-22T13:57:20Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "This bug can reproduced by checking this (valid) code:\n\nNAMES = [\"test\", \"bug\"]\n{some_var: lambda self: getattr(self, some_var) for some_var in NAMES}\n\nThis will raise an \"undefined name: some_var\" exception",
"tags": [],
"duplicates": [],
"assignee": "icordasc",
"milestone": null,
"owner": "mattegli",
"id": 1324942,
"duplicate_of": null,
"title": "dict comprehension with lambda function raises undefined name exception",
"comments": [
{
"owner": "cf-natali",
"content": "The patch attached fixes that.",
"date_created": "2014-07-22T07:52:41Z"
},
{
"owner": "icordasc",
"content": "@cf-natali that patch looks good. Can you send a PR to https://github.com/pyflakes/pyflakes and maybe add a test that demonstrates this fixes the bug here: https://github.com/pyflakes/pyflakes/tree/master/pyflakes/test?",
"date_created": "2014-07-22T12:39:07Z"
},
{
"owner": "cf-natali",
"content": "Here's a patch with test.\nAs for the pull request, I'd rather avoid setting up a repo just for this, so it would be great if you could push it yourself!\n\nCheers,\n\nCharles",
"date_created": "2014-07-23T05:30:35Z"
},
{
"owner": "icordasc",
"content": "Charles,\n\nI committed your changes on your behalf and submitted them here: https://github.com/pyflakes/pyflakes/pull/7\n\nThank you for the patch and the help!\n\nCheers,\nIan",
"date_created": "2014-07-23T15:14:52Z"
},
{
"owner": "bitglue",
"content": "Merged: https://github.com/pyflakes/pyflakes/pull/7",
"date_created": "2014-09-23T15:47:58Z"
},
{
"owner": "u5u9tu",
"content": "I'd really appreciate it if you could ship a version with this fix to pypi. Is there anything blocking a release?",
"date_created": "2015-03-17T14:56:59Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1324942",
"date_created": "2014-05-30T13:57:10Z"
},
{
"status": "New",
"security_related": false,
"description": "Would it be possible to ignore variables named \"_\" from \"Unused Variable\" checks?\n\nI'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).\n\nWould 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.\n\nBest regards,\n~arlias",
"tags": [
"wishlist"
],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "archardlias",
"id": 1328169,
"duplicate_of": null,
"title": "Ignore \"_\" vars in \"Unused Variable\" check",
"comments": [
{
"owner": "florent.x",
"content": "A good practice is to provide a snippet with some details. A minimum is probably:\n * software version\n * actual behavor\n * expected behavior\n\n\nOr I will just triage the issue as works-for-me, since I don't have any alert with this snippet:\n\n\n def get_extension(fname):\n (__, __, ext) = fname.partition('.')\n return ext",
"date_created": "2014-06-09T16:42:57Z"
},
{
"owner": "florent.x",
"content": "I would like to nuance the statement about \"_\" being a variable to be ignored.\n\nIn lot of places you also find \"_\" as the gettext shortcut for i18n of textual content.\nSo I changed my habits 2 years ago, and now I use two underscores for ignored variables.\n\nAnd I only use it when I need to unpack a tuple and I don't want all the parts, like the example posted in my previous message.\n",
"date_created": "2014-06-09T16:47:46Z"
},
{
"owner": "archardlias",
"content": "Right! had forgotten about internationalization. I don' really see both cases collide though. At least not visually. As a matter of reassignment it does though. Aliasing in that case is up to the user in that case though. Depending on local conventions.\n\n============================================\n# CASE 1\ndef myfunc():\n return 1, 2\n\na, _ = myfunc()\n\n# CASE 2\ndef myfunc():\n return 'something'\n\n_ = myfunc() # Func returns something I dont care\n # about in this particular case.\n\n# CASE 3\n# Catching the first elements with a, b, *remainder = (...) is fine. But in\n# this case we have to define a placeholder to access the first and third\n# element ignoring the second. Checker then tells us that that the second\n# element is unused in code block to follow.\ndef myfunc():\n return (1, 2, 3)\n\na, _, b = myfunc()\n\n# Could be also used for unpacking of tuples, but thats a case where it\n# would be probably better to stick to slicing.\n\n\ndef myfunc():\n # mentioned usecase\n import internationalization as _\n print(_(\"internationalized string\"))\n\n # naming alternative\n import internationalization as tl\n print(tl('internationalized string'))\n\n _ = myfunc()\n\n\ndef func_causing_problems():\n _ = myfunc()\n\n # ...\n return 123\n\n==============================================================================\n>>>\nundertest.py:3:1: E302 expected 2 blank lines, found 1\nundertest.py:9:1: E302 expected 2 blank lines, found 1\nundertest.py:20:1: E302 expected 2 blank lines, found 1\nundertest.py:42:5: F841 local variable '_' is assigned to but never used\n\n1) global scope: OK\n2) local scope: <F841>\n\nflake8 version: 2.1.0-2\npyflakes version: 0.8.1-1\nAll from debian jessie/sid.",
"date_created": "2014-06-09T21:24:45Z"
},
{
"owner": "asmeurer",
"content": "pyflakes already doesn't warn about unused variables from unpacking. For a single value, why don't you just write\n\nfunc()\n\ninstead of \n\n_ = func()\n\nEvery function returns a value, but if you don't care about it, then don't assign it to anything. _ = func() is just confusing, and much less readable. ",
"date_created": "2014-06-14T20:21:19Z"
},
{
"owner": "archardlias",
"content": "True, in any case you get a \"None\". But what of being explicit about ignoring a non \"None\" return? \n\nIs this case; \n log.debug(\"Postumous Call at Signal {0}\".format(self._signal))\n ret = self.__call_signal(*args, **kwargs)\n _ = self.__call_slots(ret)\n return ret\nless readable than:\n log.debug(\"Postumous Call at Signal {0}\".format(self._signal))\n ret = self.__call_signal(*args, **kwargs)\n self.__call_slots(ret)\n return ret\n?\n\nI argue, it is less a question whether one or the other style is more correct or readable, than a matter of consistently ignoring assignments on \"_\", regardless of context. The individual use case is up to local conventions. Some might choose the classical, call without assignment way of formatting code, others might use the \"ignorable placeholder\" approach (as seen more in functional programming). \n\nOn a personal note, I do think that it \"can\" be more readable as well as \"can be\" more documenting \"at times\" to be explicit about ignoring a return value.\n\nOn a different note; testing unpacking ignore of \n_, b = callable()\ndoes not check the further usage of \"b\", ignoring everything in the assignment all together (not only \"_\").\n\nThankful for your patience,\nbest regards,\n~arlias\n",
"date_created": "2014-06-16T16:13:16Z"
},
{
"owner": "archardlias",
"content": "Ughh... try to picture the above code example with aligned \"=\". ",
"date_created": "2014-06-16T16:14:44Z"
},
{
"owner": "asmeurer",
"content": "Assigning to _ for no reason is way less readable. It's not only confusing (\"wait, does it somehow matter if this is assigned to a variable?\"), but in my opinion the best way to not hide that a function just performs side-effects and doesn't return anything is to *not* assign it to something. \n\nAnd aligned = are not PEP 8, so you're not going to get me on that argument. ",
"date_created": "2014-06-16T16:43:39Z"
},
{
"owner": "archardlias",
"content": "True, this is like \"_\" unpacking no PEP8. I'm just asking for the feasibility of \"_\" to be acknowledged as the relative unwritten convention for \"ignored assignment\". Whether it benefits someone in its local conventions or not is up to them. Now it has to obviously not intrude against PEP8 or other conventions that might conflict with it, which at the moment I see internationalization and the case of aliasing gettext(). Both of them do not conflict with the check itself though. They conflict if sharing the approach between different use cases in the same code base, which is again purely a issue of local conventions (outside of PEP8, so no deal breaker conflict there).\n\nAs for \"=\" alignment; never intended to pass it as PEP8, on the contrary let mi state it clearly; it is not... I just rigorously use it to ease vertical reading of the code. It does not pose part or relevance on the original matter. Had just problems between what I expected to be displayed and what actually got displayed in the comment.\n\nNow to my stance at this point; \nEven though the view on this unofficial convention is split, this is one of the two or more faces to it. It does not conflict but it requires your effort to support. If it is not worth it in your eyes or if you think it is actually a bad thing, it is fine by me. It is certainly difficult to set a convention objectively, since it is inherently subjective in nature. It is like agreeing on taste of design or beauty... again, difficult and requires the tolerance to walk away. Which I'm more than willing to do. No more nagging ;).\nOn that note, please close this feature request if you consider it to be a \"not to become\". \n\nThank you for your efforts and ongoing work on pyflakes (which has been and will continue to be an incredibly useful tool for me). Also thank you for already supporting \"_\" in unpacking and iterations/list/dict comprehensions. And also for your time in this discussion.\n\nBest wishes,\n~arlias\n",
"date_created": "2014-06-16T20:41:45Z"
},
{
"owner": "krader",
"content": "It is a common idiom at my company to assign to the underscore var as a way to explicitly indicate a variable is unused. For example, you might have a method that overrides a base class method but which contains vars your implementation doesn't need:\n\n def MethodX(self, needed_var, unneeded_var):\n _ = unneeded_var\n ...\n\nThis makes it clear to the reader that the variable is being deliberately ignored and silences pylint. It would be nice if pep8 also recognized this convention. I'd like to propose a one line change that achieves this result:\n\ndiff --git a/pyflakes/checker.py b/pyflakes/checker.py\nindex 7055832..5bbc6b5 100644\n--- a/pyflakes/checker.py\n+++ b/pyflakes/checker.py\n@@ -211,7 +211,7 @@ class FunctionScope(Scope):\n @ivar globals: Names declared 'global' in this function.\n \"\"\"\n usesLocals = False\n- alwaysUsed = set(['__tracebackhide__',\n+ alwaysUsed = set(['_', '__tracebackhide__',\n '__traceback_info__', '__traceback_supplement__'])\n\n def __init__(self):\n",
"date_created": "2014-07-21T01:17:24Z"
},
{
"owner": "florent.x",
"content": "I don't see the added value of \"_ = unneeded_var\" compared with a comment\r\n\r\n # Argument \"unneeded_var\" not used here\r\n\r\n\r\nAnd if you use Flake8 you can easily configure it to ignore \"_\" if it matches your preferences.",
"date_created": "2014-07-26T11:13:11Z"
},
{
"owner": "fvisin",
"content": "Consider if you have 30K lines of company code that adopt that convention. You wouldn't want to replace all of the instances with a comment + the edited line, would you? It is a common convention in python, I don't see what's the harm of adding one line to fix this problem for those who have it.",
"date_created": "2015-10-18T23:03:16Z"
},
{
"owner": "bitglue",
"content": "I don't think it's that common, but if we get a lot of comments to the contrary here, we can reevaluate.",
"date_created": "2015-10-19T11:13:56Z"
},
{
"owner": "icordasc",
"content": "I have to agree with Florent and Phil. We've had 3 people complain over the course of ~16 months. That's certainly 3 more than any of us would like, but it's also 3 out of approximately 7.2 million downloads (which do not correspond to users) of pyflakes and almost 6 million downloads of Flake8 (which accounts for some percentage of pyflakes downloads which I won't attempt to estimate).",
"date_created": "2015-10-19T14:22:25Z"
},
{
"owner": "archardlias",
"content": "Still, it is not a change that is in direct or indirect violation of PEP8 (its well within the unspecified realm). \nSecondly, I cannot think of a use-case that conflicts with this change. \nThird, there are people who use this, specially in partial unpacking that would benefit from it. It is even handled this way within list comprehensions. Why not stay consistent outside of them.\n\nAnd finally the amount of people does not necessarily reflect the \"necessity\" of a change. I'd say that is a stance of denial, instead of a stance that is willing to evaluate the possibility to cater to a necessity without conflicting with anyone else. Is there a conflict between this and some other use-case or specification?",
"date_created": "2015-10-19T19:34:36Z"
},
{
"owner": "asmeurer",
"content": "One would have to concede that adding this probably wouldn't introduce any new false negatives (at least I've never used or seen _ as a variable except in unpacking and as the previous output in the interactive shell). It does seem odd, though, at least to my eyes. I'm sure PEP 8 doesn't even mention it because it's a relatively obscure thing. I can't speak for Guido, but I have a feeling that if it did say something about this it would recommend against it. I'm curious if this practice of assigning a function to an unused variable instead of just calling is common in other languages, or where in particular it comes from. \n\nI also don't agree with Ian's argument. Three people taking the time to comment on an issue tracker request actually corresponds to a lot of real users, in my experience. You can go through can count the number of people who have commented on other, more important pyflakes issues, and you would see similar numbers. \n\nWith that being said, I'm still -0.5 to this (if my opinion counts for anything, which it probably doesn't, since I'm not actually a core pyflakes developer). ",
"date_created": "2015-10-19T19:54:54Z"
},
{
"owner": "bitglue",
"content": "> Is there a conflict between this and some other use-case or specification?\n\nIt's work to implement and maintain, and that's a reason to not do it.\n\nAlso, I can't rule out the possibility that people are assigning to _, and would want to know if that's unused. I would say that's an uncommon use case, but then so is this. And this isn't an entirely hypothetical guess: _ is a common common identifier for gettext-like functions.\n\n> I'd say that is a stance of denial\n\nIt's not denial, it's laziness and skepticism. Please remember that this is an open source project made for your benefit entirely for free. Your success in getting this change implemented will depend more on how much work you put into it than how vehemently you argue for it.\n\nYou can do two things to help.\n\nFirstly, research. What is the relative frequency of _ being used as an \"intentionally unused\" identifier (as you are), versus using _ as an ordinary identifier that just happens to be an underscore (gettext)? You'll need to provide real links to real code, preferably projects used by a lot of people and regarded as canonical sources. If you can demonstrate that a lot of people have your problem, and that addressing your problem won't create a lot of problems for other people, that will certainly make the case a lot stronger.\n\nSecondly, you can submit a patch implementing the change you seek and with tests. That will significantly lower the barrier to implementing this change.\n\nIf you do both of those things, I guarantee this change will be in the next release.",
"date_created": "2015-10-19T20:17:54Z"
},
{
"owner": "archardlias",
"content": "@asmeurer\nFirst time I saw heavy use of it was in Haskell, which heavily relies on currying (python: functools.partial) to build functional inheritance (don't take my word on that last term, just trying to name a concept there). You basically use it to denote unused unpacks. One pivot point of the argument here is some of the nicer properties of functional programming have reached Python... hence the discussion.\n\n@Phil\n* PEP8 does not touch the topic of unused code at all. Flake does though, fortunately (F841).\n* Unfortunately you're right on that. Assignment to _ is not to be ruled off. But you could argue that its an semantically information-less var name, hence highly probable of being discarded. As for gettext; since a callable it should not pose any false negatives.\n* You're absolutely right. Then again the chance of a contribution being accepted around something that touches the outside of a clear rule set, depends a lot on consensus and can end up in a huge waste of time because of \"personal opinion\" and the requirement of research to overcome that, with no guarantees in the end. Quite frankly the balance of this issue in this last regard vs the benefit does not make it worth the effort for me. I guess that even in this regard the \"invisible hand\" holds true over the evolution of a open source project. Lazyness way to go ;). \n\nRegardless of any of this, thanks a lot for this project and the time you pour into it, I'm very well aware of what it means effort-wise and value-wise and extremely grateful for it.",
"date_created": "2015-10-19T23:17:38Z"
},
{
"owner": "simon80",
"content": "I don't have real links to real code, used by a lot of people, but both Pylint[1] and Eclipse[2] already treat underscore and underscore-prefixed identifiers on local variables as implying that the variable is knowingly unused.\n\nIn this case, we can also say confidently that addressing this problem won't create problems for other people: the risk is limited only to false negatives on the unused variable check, and then only for codebases that name local variables with an underscore prefix for some reason other than to ignore unused variable warnings, in spite of existing conventions on that.\n\nIt's still totally fair for you to ask for a patch instead of implementing it for free, but I think the likelihood of someone submitting a patch would be much higher if you were to confirm that such a patch (with tests) would be accepted.\n\n[1] http://programmers.stackexchange.com/a/139662\n[2] http://stackoverflow.com/q/11486148",
"date_created": "2016-06-13T20:19:49Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1328169",
"date_created": "2014-06-09T16:19:54Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "This line:\n\nprint(x, end=\" \")\n\nCauses a pyflakes error:\n/tmp/test.py:1:13: invalid syntax\nprint(x, end=\" \")\n\nBut looks valid to me, it works, and comes from the python docs:\nhttps://docs.python.org/3.0/whatsnew/3.0.html\n\nI'm using version 0.8.1-1 on Ubuntu Utopic.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "elopio",
"id": 1331267,
"duplicate_of": null,
"title": "print with keyword arg is marked as syntax error",
"comments": [
{
"owner": "icordasc",
"content": "Are you sure the version of pyflakes that you're running was installed on python 3?",
"date_created": "2014-06-18T01:24:08Z"
},
{
"owner": "elopio",
"content": "Hum, using pyflakes3 I don't get the error. I'm calling pyflakes though flake8, so I need to find why it's not selecting the right one.\n\nThanks the answer.",
"date_created": "2014-06-18T02:03:49Z"
},
{
"owner": "icordasc",
"content": "It's the same reason. Flake8 has to be installed independently on Python 2 and Python 3. Your copy of Flake8 was installed on Python 2 clearly.",
"date_created": "2014-06-18T12:43:52Z"
},
{
"owner": "elopio",
"content": "Yes, and I have the two installed also. The thing with flake8 is that I can't find a binary that runs the py3 version.",
"date_created": "2014-06-18T12:59:40Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1331267",
"date_created": "2014-06-18T01:13:23Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "I think pyflake should warn about included pdb line.\n\nSorry, I report it as *bug* but i can't see *improvement*.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "tymoteusz-jankowski",
"id": 1342595,
"duplicate_of": null,
"title": "pyflakes doesn't detect \"pdb\"",
"comments": [
{
"owner": "icordasc",
"content": "If you're using flake8, there's an extension which adds this as a warning/error -- flake8-debugger (https://github.com/JBKahn/flake8-debugger).\n\nThat said, having pdb (or set_trace) should not always be an error unless you think so, in which case you should use flake8 with that extension.",
"date_created": "2014-07-16T12:34:27Z"
},
{
"owner": "tymoteusz-jankowski",
"content": "Thanks, your reference solves my issue. :)",
"date_created": "2014-07-16T12:49:16Z"
},
{
"owner": "florent.x",
"content": "I agree the extension fits the need.",
"date_created": "2014-07-26T09:29:19Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1342595",
"date_created": "2014-07-16T08:45:14Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "The code below :\n\n```\n#!python\n\nfrom .module1 import class1\nfrom .module2 import class2\n__all__ = [\"class1\", \"class2\"]\n```\n\ndoes not raise F401 when running Pyflakes which is a good thing !\n\nHowever this code :\n\n```\n#!python\n\nif import_module1 and import_module2:\n\u00a0\u00a0\u00a0\u00a0from .module1 import class1\n\u00a0\u00a0\u00a0\u00a0from .module2 import class2\n\u00a0\u00a0\u00a0\u00a0__all__ = [\"class1\", \"class2\"]\nelse:\n\u00a0\u00a0\u00a0\u00a0__all__ = []\n```\n\nraises F401.\n\nI maybe wrong but I don't think we want Pyflakes to raise an error here.\n\nCan you confirm that ?",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "hadim",
"id": 1354806,
"duplicate_of": null,
"title": "F401: True negative detected",
"comments": [
{
"owner": "florent.x",
"content": "Pyflakes only supports simple cases for the __all__ variable.\n\nTo silence the checker, you can rewrite your code.\nI guess that the following code passes.\n\n\n__all__ = []\n\nif import_module1 and import_module2:\n from .module1 import class1\n from .module2 import class2\n __all__ += [\"class1\", \"class2\"]",
"date_created": "2014-09-20T11:13:04Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1354806",
"date_created": "2014-08-10T09:10:36Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Pyflakes has 2 test failures with Python 3.1.\nI attach patch.\n\n======================================================================\nFAIL: test_invalidEscape (pyflakes.test.test_api.CheckTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File \"/tmp/pyflakes/pyflakes/test/test_api.py\", line 414, in test_invalidEscape\n sourcePath, [decoding_error])\n File \"/tmp/pyflakes/pyflakes/test/test_api.py\", line 251, in assertHasErrors\n (count, err.getvalue()), (len(errorList), ''.join(errorList)))\nAssertionError: Tuples differ: (1, \"/tmp/tmpXKbN2V:1: (unicod... != (1, \"/tmp/tmpXKbN2V:1:7: (unic...\n\nFirst differing element 1:\n/tmp/tmpXKbN2V:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \\xXX escape\nfoo = '\\xyz'\n\n/tmp/tmpXKbN2V:1:7: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \\xXX escape\nfoo = '\\xyz'\n\n\n (1,\n- \"/tmp/tmpXKbN2V:1: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \\\\xXX escape\\nfoo = '\\\\xyz'\\n\")\n+ \"/tmp/tmpXKbN2V:1:7: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \\\\xXX escape\\nfoo = '\\\\xyz'\\n\")\n? ++\n\n\n======================================================================\nFAIL: test_missingTrailingNewline (pyflakes.test.test_api.CheckTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File \"/tmp/pyflakes/pyflakes/test/test_api.py\", line 278, in test_missingTrailingNewline\n self.assertHasErrors(fName, [])\n File \"/tmp/pyflakes/pyflakes/test/test_api.py\", line 251, in assertHasErrors\n (count, err.getvalue()), (len(errorList), ''.join(errorList)))\nAssertionError: Tuples differ: (1, '/tmp/tmpMlY7ZO:3:2: inval... != (0, '')\n\nFirst differing element 0:\n1\n0\n\n- (1, '/tmp/tmpMlY7ZO:3:2: invalid syntax\\n\\t\\n\\t^\\n')\n+ (0, '')\n\n----------------------------------------------------------------------\nRan 417 tests in 1.035s\n\nFAILED (failures=2, skipped=14)",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "arfrever-fta",
"id": 1358899,
"duplicate_of": null,
"title": "Test failures with Python 3.1",
"comments": [
{
"owner": "arfrever-fta",
"content": "",
"date_created": "2014-08-19T19:41:37Z"
},
{
"owner": "icordasc",
"content": "Python 3.1 was not widely used and has already reached it's end of life. I'm personally uncertain of the value to merging the patch regardless of it's relatively small size. It feels like this is something we could easily lose track of.",
"date_created": "2014-08-19T20:02:38Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1358899",
"date_created": "2014-08-19T19:41:37Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "I am getting SyntaxErrors on some code lines and I don't get why. I suspect a pyflakes bug :-)\n\nThe error I get is: example.py:369:30: E901 SyntaxError: invalid syntax\n\nThe line it trips over is:\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0data = yield from client_reader.read(mesg.MAX_MESG_SEND_LENGTH)\n\nSimiliar: example.py:348:39: E901 SyntaxError: invalid syntax\nOn:\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if not (yield from self._retry_message()):\n\nThanks,",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "q-dbuntu-1",
"id": 1362613,
"duplicate_of": null,
"title": "flake8 gives invalid syntax on yield from",
"comments": [
{
"owner": "icordasc",
"content": "Please provide the output of\n\n flake8 --version\n\nThe yield from syntax is specific to Python 3. If flake8 is installed on Python 2 it will not work.",
"date_created": "2014-08-28T14:12:45Z"
},
{
"owner": "q-dbuntu-1",
"content": "Installed with \n\n$ sudo apt-get install python3-flake8\n\nSo I assumed Python 3 compatible. But version shows something else:\n\n$ flake8 --version\n2.1.0 (pep8: 1.4.6, pyflakes: 0.8.1, mccabe: 0.2.1) CPython 2.7.6 on Linux\n\nInstalling it with pip3 gave me the proper version:\n2.2.3 (pep8: 1.5.7, pyflakes: 0.8.1, mccabe: 0.2.1) CPython 3.4.0 on Linux\n\nSorry for the noise",
"date_created": "2014-08-28T15:06:44Z"
},
{
"owner": "q-dbuntu-1",
"content": "Although it remains strange that it tripped over only two occurrences of yield from while there are a lot more...",
"date_created": "2014-08-28T15:07:30Z"
},
{
"owner": "icordasc",
"content": "Installing it system-wide may not have overridden the default binding for `flake8`. It may have been named some other binary in the event that you already had Flake8 installed under Python 2.",
"date_created": "2014-08-28T15:28:15Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1362613",
"date_created": "2014-08-28T13:32:21Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Similar to #1362613 but now it gives invalid syntax on the abc module:\n\nError: example.py:108:30: E901 SyntaxError: invalid syntax\n\nLine:\nclass MesgStoreSet(metaclass=abc.ABCMeta):",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "q-dbuntu-1",
"id": 1362617,
"duplicate_of": null,
"title": "flake8 gives invalid syntax on abc",
"comments": [
{
"owner": "icordasc",
"content": "Again, like #1362613, this likely depends on what version of Python you used to install Flake8",
"date_created": "2014-08-28T14:13:26Z"
},
{
"owner": "icordasc",
"content": "This is likely fixed with #1362613.",
"date_created": "2014-08-28T15:29:27Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1362617",
"date_created": "2014-08-28T13:37:00Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "When concatenating two tuples and setting the value to __all__ it doesn't detect all values.\n\nfoo = ('bar', 'snafu')\n__all__ = ('hello_world') + foo\n\nIn this case all values in the second tuple ('hello_world' in this case) are not detected and it complains about unused imports.\n\nThe real life example:\n\nThe report https://integration.wikimedia.org/ci/job/pywikibot-core-tox-flake8/1377/console is due to this change: https://gerrit.wikimedia.org/r/#/c/155159/6/pywikibot/__init__.py\n\nThere is a workaround (in patch set 8), but that doesn't work with pep257.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "commodorefabianus",
"id": 1364183,
"duplicate_of": null,
"title": "pyflakes is unable to detect concatenation of __all__ ",
"comments": [
{
"owner": "icordasc",
"content": "> In this case all values in the second tuple ('hello_world' in this case) are not detected and it complains about unused imports.\n\nTo be clear, PyFlakes is not executing your dynamic import from textlib and evaluating the tuple textlib_methods to check their usage. PyFlakes does *not* count textlib_methods as part of __all__. Your for-loop is not executed so those dynamic imports are not counted against you.\n\nTo help others too, who like me didn't initially understand this report entirely, there are imports in the tuple being concatenated to that are being reported as unused.\n\nCurrently PyFlakes takes an all or nothing approach to checking __all__ because if it isn't a bare tuple it can not reliably check all of the imports. It could half-way check this instance when it sees a tuple literal in an expression. \n\nI suspect, however, that a simple work around would be to do\n\n__all__ = ('my', 'tuple', 'of', 'imported', 'names')\n__all__ += textlib_methods\n\nI haven't tested this, but I suspect PyFlakes would determine that __all__ uses the imports it otherwise complains about and then moves on.",
"date_created": "2014-09-11T19:20:24Z"
},
{
"owner": "commodorefabianus",
"content": "Okay this seems to work (but unfortunately not applicable because pep257 doesn't like that).\n\nAlso thank you for that explanation. That makes sense.\n",
"date_created": "2014-09-12T12:23:24Z"
},
{
"owner": "florent.x",
"content": "Indeed, Pyflakes does static analysis and cannot parse \"__all__\" declarations which refer to other iterables.\r\n\r\n\r\nThe simple cases which are supported are:\r\n\r\n __all__ = [\"foo\", \"bar\"]\r\n \r\n if condition:\r\n __all__ += [\"baz\"]\r\n",
"date_created": "2014-09-20T10:22:27Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1364183",
"date_created": "2014-09-02T00:04:33Z"
},
{
"status": "Confirmed",
"security_related": false,
"description": "With pyflakes-0.8.1 and python-2.7.8, the following test program gets the expected complaint:\n\nimport foo\nfoo()\ndef bar():\n\u00a0\u00a0\u00a0\u00a0a = 0\n\u00a0\u00a0\u00a0\u00a0#a = [1 for foo in []]\n\u00a0\u00a0\u00a0\u00a0for foo in []:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pass\n\u00a0\u00a0\u00a0\u00a0del a\n\npyflakes t.py\nt.py:6: import 'foo' from line 1 shadowed by loop variable\n\nBut if you uncomment the list comprehension, the pyflakes complaints go away.\n\nI think the presence of the list comprehension should actually *increase* the number of complaints: \"foo\" is being shadowed in both the list comprehension and the for-loop.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "warner",
"id": 1373143,
"duplicate_of": null,
"title": "shadowed variables not noticed after list comprehension",
"comments": [
{
"owner": "warner",
"content": "",
"date_created": "2014-09-23T21:49:13Z"
},
{
"owner": "icordasc",
"content": "You mention this happens on 2.7. The 2.x branch has an issue with list comprehension bindings being leaked to the outer scope. So you can do this on 2.7\n\n[i for i in range(10)]\nprint(i + 1)\n\nAnd you'll see 10.\n\nI agree that uncommenting the list comprehension shouldn't cause the error to stop but I suspect what I mentioned is what's causing it. It appears, to pyflakes, that the variable is being defined locally in some way that does not appear to shadow the global binding.\n\nI think I agree that there should also be (ideally) two errors/warnings: 1 for using `foo` in the list comprehension and 1 for using it afterwards.",
"date_created": "2014-09-23T22:12:54Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1373143",
"date_created": "2014-09-23T21:49:13Z"
},
{
"status": "Confirmed",
"security_related": false,
"description": "setattr(<identifier>, <string literal>, ...) can always be rewritten as a simple assignment. Would make a nice warning.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "schmichael",
"id": 1386424,
"duplicate_of": null,
"title": "Warn that setattr(<identifier>, <string literal>, ...) should be an assignment",
"comments": [
{
"owner": "icordasc",
"content": "Note this is only in cases like: setattr(self, 'some_attribute', val). If the second argument isn't a string literal, there would be no warning.",
"date_created": "2014-10-27T21:27:50Z"
},
{
"owner": "bitglue",
"content": "Pyflakes has no concept of \"warnings\". It only has errors, and Pyflakes on principle emits errors only about things it is sure are errors. This is a useful property that similar tools do not have: you can run Pyflakes on any codebase, and it shouldn't spew any errors unless there are really errors in the program.\n\nflake8 adds pep8 checking to pyflakes, which is a good option if you like pyflakes but want checks that are predicated on style and opinion. pylint and pychecker are unrelated to pyflakes, but also do style-based checks. You might evaluate those tools to see if they better suit your needs.",
"date_created": "2014-10-29T14:10:27Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1386424",
"date_created": "2014-10-27T21:22:19Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "e.g.:\n\n```python\nclass FakeClass(object):\n TROVE_STATUS_REASON = {\n 'FAILED':\n 'database instance was created, but failed to set up the '\n 'datastore. If a database instance is in the FAILED state, '\n 'you should delete it and create a new instance.',\n 'ERROR':\n 'last operation for the database instance failed due to an error.',\n }\n\n def fake_function(self, input):\n return TROVE_STATUS_REASON[input]\n```\n\nthrows an error of the form:\n\n(py275)MNJ05EG3QN:garbage prat8228$ pyflakes t.py\nt.py:12: undefined name 'TROVE_STATUS_REASON'\n\nwhereas the class attribute seems to be correctly defined.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "pratik-mallya",
"id": 1387175,
"duplicate_of": null,
"title": "class attributes not recognized",
"comments": [
{
"owner": "pratik-mallya",
"content": "This is on python 2.75 ",
"date_created": "2014-10-29T13:32:52Z"
},
{
"owner": "pratik-mallya",
"content": "After a discussion with therealfakemoot on irc, it looks liks this isn't a bug in pyflakes. Class attributes themselves must be\naccessed via either the classname or the instance name (i.e. self)",
"date_created": "2014-10-29T13:44:12Z"
},
{
"owner": "bitglue",
"content": "By my tests this is correct, as Python will raise a NameError when that\nfunction is called:\n\nPython 2.7.6 (default, Mar 22 2014, 22:59:56)\n[GCC 4.8.2] on linux2\nType \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>> class Foo(object):\n... TROVE_STATUS_REASON = 'too trovish'\n... def f(self, input):\n... return TROVE_STATUS_REASON\n...\n>>> Foo().f(None)\nTraceback (most recent call last):\n File \"<stdin>\", line 1, in <module>\n File \"<stdin>\", line 4, in f\nNameError: global name 'TROVE_STATUS_REASON' is not defined\n\nOn Wed, Oct 29, 2014 at 9:32 AM, Pratik Mallya <email address hidden>\nwrote:\n\n> This is on python 2.75\n>\n> --\n> You received this bug notification because you are subscribed to\n> Pyflakes.\n> Matching subscriptions: all pyflakes bugs\n> https://bugs.launchpad.net/bugs/1387175\n>\n> Title:\n> class attributes not recognized\n>\n> To manage notifications about this bug go to:\n> https://bugs.launchpad.net/pyflakes/+bug/1387175/+subscriptions\n>\n",
"date_created": "2014-10-29T13:44:26Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1387175",
"date_created": "2014-10-29T13:32:03Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "On Windows with python 2.6 pyflakes 0.8.1 fails to process files with DOS line endings (\\r\\n)\n\nOpening files in test mode, instead of binary fixes the problem for me.\nNow I can check files with both unix and dos line ending styles again.\n\nSee applied patch.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "js-6",
"id": 1397266,
"duplicate_of": null,
"title": "failed to process files on windows with dos line endings (\\r\\n)",
"comments": [
{
"owner": "js-6",
"content": "",
"date_created": "2014-11-28T10:05:38Z"
},
{
"owner": "bitglue",
"content": "Thanks for the patch. Unfortunately, this unfixes a previous bug:\n\nhttps://bugs.launchpad.net/pyflakes/+bug/1299169\n\nI made a PR on your behalf to run the patch through Travis, and this was the result:\n\nhttps://travis-ci.org/pyflakes/pyflakes/builds/42395126\n\nMaybe the right thing to do is open in binary mode only on python3? I haven't dug too deeply into that other bug, but it seems to apply to python3.\n\nI also don't have a great way to test on Windows. I don't have a Windows box, and neither does Travis. Can you perhaps do some testing to see if this is an issue that only happens on Windows, or if it happens with \\r\\n line terminated files on any platform? If it's the latter, then we can add a test to make sure this doesn't regress, which is really important since it's such a subtle problem.",
"date_created": "2014-11-28T14:14:51Z"
},
{
"owner": "icordasc",
"content": "I need to look at how pyflakes opens files more closely but there is an option that will open it and auto-detect/normalize the \\r\\n to \\n for our assumptions to work.",
"date_created": "2014-11-28T14:18:42Z"
},
{
"owner": "icordasc",
"content": "I looked it up in the docs [1] and apparently universal newline support has been deprecated. If you also read further into that section, you'll see that universal newlines have been replaced with a newline parameter and that it only works for Text-mode (while we wish to use bytes) to read the file\n\n[1]: https://docs.python.org/3/library/functions.html#open",
"date_created": "2014-11-28T14:32:28Z"
},
{
"owner": "bitglue",
"content": "I was able to reproduce on an ancient version of Ubuntu. Can you please test https://github.com/pyflakes/pyflakes/pull/10 and verify that it fixes your issue in Windows as well?",
"date_created": "2014-11-28T16:36:16Z"
},
{
"owner": "js-6",
"content": "Thank you for the patch. \nThis fixes it for python 2.6 on Windows as well.",
"date_created": "2014-12-01T08:01:19Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1397266",
"date_created": "2014-11-28T10:05:38Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Pyflakes incorrectly thinks that the local variable \"bar\" is never used in the following example:\n\ndef closures():\n bar = None\n def getset(val):\n nonlocal bar\n if val:\n bar = val\n else:\n return bar\n return getset",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "anntzer-lee",
"id": 1402851,
"duplicate_of": null,
"title": "incorrect \"local variable is never used\"",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1402851",
"date_created": "2014-12-15T22:28:42Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "The solution is simple ..., just change the line 142 from \" except ValueError: \" to \" except ( ValueError, AttributeError ): \" and everything will come back to normal.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "ademir01",
"id": 1406953,
"duplicate_of": null,
"title": "api.py crashes in the Windows - Pyflakes 0.8.2a0",
"comments": [
{
"owner": "bitglue",
"content": "Can you please include the full traceback of the crash?\n",
"date_created": "2015-01-02T14:44:10Z"
},
{
"owner": "bitglue",
"content": "This should be addressed by https://github.com/pyflakes/pyflakes/pull/16 which will be included in the next release.",
"date_created": "2015-05-27T15:37:13Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1406953",
"date_created": "2015-01-01T16:23:42Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "There's a tool for performing a check for compliance with pep257 already https://pypi.python.org/pypi/pep257/0.4.1 and it'd be great if pyflakes could support that.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "hjd",
"id": 1418658,
"duplicate_of": null,
"title": "pyflakes should verify that code conforms to pep257",
"comments": [
{
"owner": "hjd",
"content": "Sounds useful. I've marked the upstream project as also affected, since this will likely need to be added there.",
"date_created": "2015-07-24T08:30:18Z"
},
{
"owner": "icordasc",
"content": "So PyFlakes is a linter, not a style checker. It checks for unused variables, imports, etc. It doesn't apply style consistency. pep8 and pep257 are two tools that apply style checks for style consistency.\n\nFlake8 is a tool that provides linting and style checks (by utilizing pyfakes and pep8) and has an extension called \"flake8-docstrings\" which utilizes pep257 to provide the checks by running one tool.\n\npyflakes has no extension capability, and as far as I'm aware has no plans to add one since you have that feature through flake8.",
"date_created": "2015-07-24T12:53:04Z"
},
{
"owner": "hjd",
"content": "Thanks for the reply from upstream. :)\n\nI'm now unsure what to do with the Ubuntu-part of this bug report, and whether that should simply be closed too. Christian, what do you think?",
"date_created": "2015-08-23T10:53:28Z"
},
{
"owner": "icordasc",
"content": "@hjd, I strongly recommend marking it as Invalid. Unless Ubuntu wants to fork Pyflakes to add some kind of extension features (that already exist in another strongly related project) I don't know what the Ubuntu Pyflakes package can offer other than perhaps recommending pep257, pep8, flake8, and mccabe.",
"date_created": "2015-08-23T16:23:06Z"
},
{
"owner": "hjd",
"content": "Sounds reasonable to me.",
"date_created": "2015-09-05T19:02:46Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1418658",
"date_created": "2015-07-24T08:29:46Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "I believe the following is a false failure reported by pyflakes.\n\nCode snippet:\n\nsome_list = [(1, 2), (3, 4)]\nfirst_tuple, _ = some_list\nsome_list_with_results = [a for a, _ in some_list]\n\n\nTriggers the following violation:\n\nlist comprehension redefines '_' from line 2\n\n\nFor completeness i'm using:\n\npyflakes --version\n0.8.1\n\n\n/bei",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "stijndubrul",
"id": 1418997,
"duplicate_of": null,
"title": "false failure on list comprehension redefines",
"comments": [
{
"owner": "myint",
"content": "I think this is avoided when running pyflakes with Python 3 now. Though, I guess it still would affect Python 2.\n\nhttps://github.com/pyflakes/pyflakes/pull/14",
"date_created": "2015-03-20T19:30:40Z"
},
{
"owner": "bitglue",
"content": "I concur. That PR should be in the next release.",
"date_created": "2015-05-27T15:27:45Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1418997",
"date_created": "2015-02-06T14:24:33Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Running pyflakes on the following code correctly produces `2: redefinition of unused 'os' from line 1`.\n\n import os\n import os\n print(os.separator)\n\nThis slightly altered version produces the above message, but also says `1: 'os' imported but unused`. Is this a bug or due to the way importing works on Python? I wasn't sure, so I've sent this anyway. Feel free to close the bug.\n\n import os\n def f():\n import os\n print(os.separator)",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "quentinp",
"id": 1447778,
"duplicate_of": null,
"title": "'Imported but unused' warning when importing in another scope",
"comments": [
{
"owner": "bitglue",
"content": "It's because of how scopes work in python. Might be more clear with something that's not an import:\n\nfoo = 42\ndef f():\n foo = 43\n print foo\n\nOf course this will print '43'. And the first foo, the one that is 42, it's still there because the other foo was defined in another scope, the scope of f(). Also, the foo that's 42 was never used.\n\nAn import is just an assignment to a name where the value is a module. And in your case, the first 'os', is never used, thus the error.",
"date_created": "2015-04-23T19:57:29Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1447778",
"date_created": "2015-04-23T19:13:39Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "In the absence of *args and **kwargs, one can statically check if the format string refers to the right number of arguments, if numbered format specifiers like {5} refer to arguments that exist, and if keyword format specifiers refer to keyword arguments that exist.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "snarkmaster",
"id": 1450316,
"duplicate_of": null,
"title": "Idea: Check for '{} {}'.format(5).",
"comments": [
{
"owner": "asmeurer",
"content": "This is a duplicate of https://bugs.launchpad.net/pyflakes/+bug/1361849",
"date_created": "2015-04-30T16:40:28Z"
},
{
"owner": "snarkmaster",
"content": "Sorry about that.",
"date_created": "2015-05-01T04:00:32Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1450316",
"date_created": "2015-04-30T05:36:04Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Multi Line imports with unused modules are not detected as unused when they are on the second line\n\nIn this example only \"UnusedOne\" is detected as unused, but UnusedTwo is not.\n\nfrom almacen.models import UsedOne, UnusedOne,\\\n UsedTwo, UnusedTwo",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jm-federico",
"id": 1455805,
"duplicate_of": null,
"title": "multiline imports not detected as unused",
"comments": [
{
"owner": "bitglue",
"content": "I can not reproduce with the most recently released version, 0.8.1:\n\n$ pyflakes \nfrom almacen.models import UsedOne, UnusedOne,\\\n UsedTwo, UnusedTwo\n\n<stdin>:1: 'UnusedTwo' imported but unused\n<stdin>:1: 'UsedOne' imported but unused\n<stdin>:1: 'UsedTwo' imported but unused\n<stdin>:1: 'UnusedOne' imported but unused\n$ pyflakes --version\n0.8.1\n\nCould it be that you are using a very old version, or some intermediate tool is altering the output?",
"date_created": "2015-05-27T15:01:40Z"
},
{
"owner": "jm-federico",
"content": "You are absolutely right, sorry, not this apps fault.",
"date_created": "2015-06-01T15:28:02Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1455805",
"date_created": "2015-05-16T18:54:31Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "https://github.com/pyflakes/pyflakes/blob/master/NEWS.txt\n\n0.9.0 has been released, but the NEWS.txt file has not been updated to include the changes",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "frewsxcv",
"id": 1461225,
"duplicate_of": null,
"title": "0.9.0 release needs to be added to NEWS.txt file",
"comments": [
{
"owner": "bitglue",
"content": "Whoops :) Fixed with 0.9.1.",
"date_created": "2015-06-10T01:55:08Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1461225",
"date_created": "2015-06-02T19:08:04Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "I am getting \"test.py:2: 'foo' imported but unused\" when having __all__ as tuple. \n\n__all__ = ('foo',)\nfrom bar import foo\n\nIt would btw. be much nicer if one could file issues via github!",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "spaceone",
"id": 1463564,
"duplicate_of": null,
"title": "__all__ as tuple",
"comments": [
{
"owner": "spaceone",
"content": "__all__ = ['foo',] works...",
"date_created": "2015-06-09T20:50:07Z"
},
{
"owner": "spaceone",
"content": "pyflakes 0.7.3",
"date_created": "2015-06-09T20:50:43Z"
},
{
"owner": "bitglue",
"content": "0.7.3 is about two years old. I can not reproduce this with the latest release, 0.9.1.",
"date_created": "2015-06-10T10:18:53Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1463564",
"date_created": "2015-06-09T20:49:41Z"
},
{
"status": "New",
"security_related": false,
"description": "I know that pyflakes doesn't want to add support for excluding errors inside of scripts, but would you be open to adding the --exclude flag to the pyflakes command to exclude files? My situation is this. I want to run pyflakes automatically in the test suite (on Travis CI). However, there are some files that should be ignored (e.g., a compat.py file with a bunch of Python 2/3 compatibility importat that pyflakes gives a bunch of unused import and undefined name warnings for, and a bundled library that uses * imports, but which I'd rather just leave alone). I tried using extended globbing in bash, but it seems it's not so easy to mix multiple !() globs, even with globstar enabled. Anyway, I couldn't figure out how to do it.\n\nI know I can use flake8, but it seems that flake8 --select=F doesn't actually include all pyflakes errors (like syntax errors). I also kind of want to avoid flake8 just to reduce the temptation to test for pep8 errors. \n\nWould it be OK to add --exclude, like flake8 and pep8, which excludes files or directories, to the flake8 command? The --exclude flag in flake8/pep8 accepts a comma separate list of values, which seems kind of dumb to me (it makes more sense to just accept files from the command line, like \"pyflakes --exclude compat.py stuff/\", which could then be globbed), but I'm OK with keeping it that way if cross-compatibility is a concern.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1481052,
"duplicate_of": null,
"title": "--exclude flag to the command line",
"comments": [
{
"owner": "icordasc",
"content": "If there's a bug in Flake8 then please report it there and we'll investigate. I think Phil has been leaning towards the \"There's already a tool that does this\" camp so I would guess adding --exclude here is a no-go.",
"date_created": "2015-08-04T19:39:20Z"
},
{
"owner": "jayvdb",
"content": "My vote is to not add this feature, and let flake8 do CLI niceties like this.\n\nIf you want to do it with raw pyflakes, at least on unix, the following patterns can be used if multiple globs are not working.\n\n$ pyflakes `find . -name '*.py' -and -not -name package_name -and -not -name module_name.py`\n\nor\n\n$ find . -name '*.py' -and -not -name package_name -and -not -name module_name.py | xargs pyflakes\n\nor\n\n$ pyflakes `find . -name '*.py' | grep -v package_name | grep -v module_name.py`\n\ngrep -E might be better, depending on the globs you need to recreate as regex.",
"date_created": "2015-12-17T06:28:51Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1481052",
"date_created": "2015-08-03T18:56:42Z"
},
{
"status": "New",
"security_related": false,
"description": "On Python 3, the following code raises a warning:\n\n class Test(object):\n def __init__(self):\n print(__class__.__name__)\n self.x = 1\n\n t = Test()\n\nThis is actually valid Python 3 code, but PyFlakes doesn't quite understand that:\n\n test.py:3: undefined name '__class__'",
"tags": [
"easy"
],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "icordasc",
"id": 1487725,
"duplicate_of": null,
"title": "On Python 3, __class__ can be used without self",
"comments": [
{
"owner": "saladi",
"content": "Any movement on this? I keep getting warnings about this too.",
"date_created": "2016-08-21T21:07:09Z"
},
{
"owner": "meet123mangukiya",
"content": "I'd like to take up this bug",
"date_created": "2017-03-22T19:17:04Z"
},
{
"owner": "bitglue",
"content": "That would be much appreciated. Please submit your changes as a GitHub PR\nwhen they are complete.\n\nOn Wed, Mar 22, 2017 at 3:35 PM Meet <email address hidden> wrote:\n\n> I'd like to take up this bug\n>\n> --\n> You received this bug notification because you are subscribed to\n> Pyflakes.\n> Matching subscriptions: all pyflakes bugs\n> https://bugs.launchpad.net/bugs/1487725\n>\n> Title:\n> On Python 3, __class__ can be used without self\n>\n> To manage notifications about this bug go to:\n> https://bugs.launchpad.net/pyflakes/+bug/1487725/+subscriptions\n>\n",
"date_created": "2017-03-30T14:09:56Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1487725",
"date_created": "2015-08-22T14:55:32Z"
},
{
"status": "New",
"security_related": false,
"description": "I'm proposing marking ALL decorators AND function declaration on decorated duplicate declaration.\n\nSee https://github.com/DamnWidget/anaconda/issues/363 for context.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "pradyunsg",
"id": 1489540,
"duplicate_of": null,
"title": "Highlighting decorators AND function declaration",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1489540",
"date_created": "2015-08-27T16:43:58Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "pyflakes is finding an undefined name error on the unicode() built-in method. Here is an example of the output from pyflakes:\n\n$ pyflakes test.py \ntest.py:1: undefined name 'unicode'\n\nHere is the contents of test.py\n\nprint(unicode('abc'))\n\nThis is valid python and does not cause an exception when run.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "rsimmons0",
"id": 1496955,
"duplicate_of": null,
"title": "False positive on unicode built-in function",
"comments": [
{
"owner": "asmeurer",
"content": "It's likely that your pyflakes is running in Python 3 but you are executing the code in Python 2. unicode only exists in Python 2 (and pyflakes checks against the version of Python it is running in). ",
"date_created": "2015-09-17T18:35:11Z"
},
{
"owner": "bitglue",
"content": "Closing this for lack of activity. If running pyflakes with python 3 does not resolve your issue, please reopen this bug or file a new one.",
"date_created": "2015-11-17T15:23:38Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1496955",
"date_created": "2015-09-17T18:04:18Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "Apologies if this is known -- I didn't see a bug or a skipped test for it. \n\nThis should generate a warning but does not:\n\n a = None\n if True or False:\n b = None\n ab = a + b\n\nb is undefined when the `if` fails, and the code is invalid Python.\n\n a = None\n if False:\n b = None\n ab = a + b\n\n Traceback (most recent call last):\n File \"/Users/jvanasco/Desktop/scoping.py\", line 4, in <module>\n ab = a + b\n NameError: name 'b' is not defined\n\nHowever pyflakes does not catch this error at all.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jvanasco",
"id": 1497348,
"duplicate_of": null,
"title": "no warning for possibly undefined scope",
"comments": [
{
"owner": "bitglue",
"content": "What about:\n\ni = randint(0, 10)\nif is_even(i):\n b = \"foo\"\nif is_odd(i):\n b = \"bar\"\nprint b\n\nThis works all the time, but is there a way for Pyflakes to know that?",
"date_created": "2015-09-18T20:16:58Z"
},
{
"owner": "jvanasco",
"content": "I don't think Pyflakes (or developers) need to know if something would necessarily trigger an error -- just that it could.\n\nOther linters/debug tools I've used (none python) triggered a warning in similar situations (not a confirmed error) that a variable could potentially be undefined when executed. With that warning noted, one might edit the (bitglue) example to read-\n\n\ti = randint(0, 10)\n\tif is_even(i):\n\t\tb = \"foo\"\n\telse:\n\t\tb = \"bar\"\n\tprint b\n\nor even...\n\n\ti = randint(0, 10)\n\tb = None\n\tif is_even(i):\n\t\tb = \"foo\"\n\tif is_odd:\n\t\tb = \"bar\"\n\tprint b\n\nIn any event, in both the original(jonathan) and (bitglue) examples, a variable is declared within a conditional block BUT unconditionally used outside of it. While this isn't a guaranteed error, it's a potential source -- which is why we use tools like pyflakes [right?].\n",
"date_created": "2015-09-18T20:53:18Z"
},
{
"owner": "asmeurer",
"content": "One of pyflakes' goals is to avoid false positives (see https://github.com/pyflakes/pyflakes#design-principles). I personally use pyflakes in some test suites so that tests don't pass unless pyflakes gives no errors. Even the few false positives that pyflakes does give (usually surrounding compatibility imports) are irksome. \n\nPerhaps a new tool (possibly built on top of pyflakes) that checks for these more advanced sorts of errors and doesn't mind giving false positives would be in order. They're not really style issues, so I don't think pep8 is a good place for them (they also aren't part of PEP 8). \n\nAnd I'm pretty sure this has all been discussed extensively in an another issue here. ",
"date_created": "2015-09-18T21:09:34Z"
},
{
"owner": "bitglue",
"content": "> While this isn't a guaranteed error, it's a potential\n> source -- which is why we use tools like pyflakes [right?].\n\nI think maybe not. Pyflakes has a few design principles[1] which set it apart from similar tools like pylint. One of them is that Pyflakes avoids false positives even if that means admitting the possibility a false negative. This gives Pyflakes a couple nice properties:\n\nFirstly, you can run Pyflakes against any code, even really bad code, and be confident that 99.9% of what it tells you are actual problems: code which is either unnecessary, never executed, or a bug.\n\nAnother is that there's never any need to frob a bunch of configuration options to match personal style preferences (though people who like to follow PEP8 use pyflakes as part of flake8).\n\nPersonally, I lean very heavily on unit testing to catch errors in my programs. Pyflakes catches some things a unit test won't catch, like an unused variable or import. Since the unit tests catch most of the errors I really like that I don't have to fight with my linter to get it to give me relevant information.\n\nSo it sounds like we have here is just a difference in expectations so I'm going to close the ticket. But thanks for reporting the bug anyway, it's always good to get feedback. I'd encourage you to check out pylint: I don't know if it does precisely what you want, but you might find in general it does more what you want.\n\n[1] https://github.com/pyflakes/pyflakes#design-principles",
"date_created": "2015-09-18T21:22:37Z"
},
{
"owner": "jvanasco",
"content": "Respectfully: there is *nothing* in the documentation that explicitly states or otherwise suggests the extent to which false-positives are avoided includes allowing false-negatives. \"Trying very, very hard to avoid false- positives\" is decidedly not the same as knowingly not testing for scenarios that could produce false positives. \n\nIt is your decision to embrace that design decision - and I'm not going to question that. I would, however, like to point out that there is a moral responsibility to explicitly and adequately note that decision. A lot of people have placed trust in pyflakes directly (or via flake8), as part of their code auditing and build/deploy routines; there honestly should be a list of potential bugs that this library has decided not to test against [because of the potential for false-negatives] so that end-users can decide how to proceed.\n\nFYI- We rely heavily on unit testing as-well-as integrated testing. All of our custom tests passed; pyflakes (via flake8) showed no errors on any checkins or the build/deploy log... but one particular edge case kept popping up in the production logs. It took several hours of debugging to determine what happened was a variant of the above-reported issue.",
"date_created": "2015-09-21T19:57:59Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1497348",
"date_created": "2015-09-18T15:56:22Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "I don't have time to investigate this further at the moment. In the file https://github.com/asmeurer/conda/blob/22f573847d4962797a9e82b149deefa480e17e65/conda/logic.py#L511 at the given line number, if I add an undefined variable, pyflakes gives no errors.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1498174,
"duplicate_of": null,
"title": "pyflakes not working for a file",
"comments": [
{
"owner": "bitglue",
"content": "I can't reproduce this in master:\n\n o = Optimize()\n for clause in clauses:\n o.add(clause)\n asdf\n if use_combined_eq:\n o.minimize(combined_eq)\n else:\n o.minimize(z3_version_eq)\n o.minimize(z3_package_eq)\n\n\n$ pyflakes logic.py \ntest.py:511: undefined name 'asdf'\n\n Please reopen if it still seems to be an issue.",
"date_created": "2015-11-17T15:29:55Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1498174",
"date_created": "2015-09-21T20:21:30Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "$ cat test.py\nprint list(\n\u00a0\u00a0\u00a0\u00a0map(\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0lambda x: '{} {}'.format(var, x),\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0['orange', 'apple']\n\u00a0\u00a0\u00a0\u00a0)\n\u00a0\u00a0\u00a0\u00a0for var in ['an', 'example']\n)\n\n$ pyflakes test.py\ntest.py:3: undefined name 'var'\n\nthe variable \"var\" is available in the lambda expression, so I believe this is a false positive for \"undefined name\" error.\n\nEdit:\nsorry, this was my fault, after I updated pyflakes to the latest version, the issue has gone.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "mobile-microalex",
"id": 1501359,
"duplicate_of": null,
"title": "False positive \"undefined name\" in comprehensions",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1501359",
"date_created": "2015-09-30T14:20:36Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "The following file is valid Python 3:\n\n def function(arg, *, keyword_only_arg):\n pass\n\nbut pyflakes does not allow it:\n\n test.py:1:20: invalid syntax",
"tags": [
"python3"
],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "basti-w",
"id": 1503249,
"duplicate_of": null,
"title": "false negative for keyword-only arguments in Python 3",
"comments": [
{
"owner": "bitglue",
"content": "Works for me:\n\n$ python3 -m pyflakes\ndef function(arg, *, keyword_only_arg):\n pass\n$\n\nHowever, you must be sure to invoke pyflakes with the version of python you wish to check. Doing the same but with python2 will emit a syntax error as you describe. But under python2 rules, pyflakes is correct: that is invalid syntax.",
"date_created": "2015-10-06T13:07:57Z"
},
{
"owner": "basti-w",
"content": "My bad, I thought `sudo apt-get install python3-flake8` would automatically invoke the Python 3-version. Thank you for your help!",
"date_created": "2015-10-06T13:29:46Z"
},
{
"owner": "icordasc",
"content": "What version was keyword-only arguments introduced in? I feel like it wasn't very early in Python 3's life cycle so if you're using an older version of 3 that may be the cause. I expect debian/ubuntu to install the right pyflakes for the right packages.",
"date_created": "2015-10-06T20:56:06Z"
},
{
"owner": "basti-w",
"content": "Keyword-only arguments were introduced in PEP 3102 (http://legacy.python.org/dev/peps/pep-3102/) which was accepted in Python 3.0, apparently.\n\nIf you `apt-get install python3-flake8`, Ubuntu creates two binaries, `pyflakes` and `pyflakes3`. If you use the latter, it works correctly for Python 3.",
"date_created": "2015-10-07T06:59:19Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1503249",
"date_created": "2015-10-06T11:51:27Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Here's some bad code that's not caught by pyflakes:\n\n class TestStuff(unittest.TestCase):\n\n examples = {\n 'a': [\n 1,\n 2,\n 3,\n 4,\n ],\n 'b': [\n 1,\n 2,\n 3,\n 4,\n ],\n 'a': [\n 5,\n 6,\n ],\n }\n\n def test(self):\n for expected, examples in self.examples.items():\n for example in examples:\n self.assertEqual(expected, f(example))\n\nThe bug is that TestStuff.examples['a'] == [5, 6], and the original list of test examples ([1, 2, 3, 4]) has been silently lost.\n\nIt would be nice if pyflakes could warn about duplicate literal key values in dict literals.\n\n(Also, it would be nice if you'd switch to GitHub for issue tracking, because Launchpad's bug tracker makes it very inconvenient to type code examples and doesn't let one preview them.)",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "mgedmin",
"id": 1506824,
"duplicate_of": null,
"title": "Wishlist: report duplicate keys in dict literals",
"comments": [
{
"owner": "jayvdb",
"content": "A limited version of this was committed as https://github.com/PyCQA/pyflakes/pull/72 .\n\nThe main limitation is that it only reports redefined keys.\n\nThe reason is a (key, value) pair that is duplicated is probably bad coding, but it is not a bug or even a hint of a bug.\n",
"date_created": "2016-09-15T21:49:40Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1506824",
"date_created": "2015-10-16T10:26:48Z"
},
{
"status": "Confirmed",
"security_related": false,
"description": "Running current pyflakes on astroid results in maximum recursion depth exceeded on a test module.\n\nhttps://bitbucket.org/logilab/astroid/src/6d4e198bdc7091f36c2c24d911c5ee92b64847c2/astroid/tests/testdata/python2/data/joined_strings.py\n\n$ pyflakes astroid/tests/testdata/python2/data/joined_strings.py\nTraceback (most recent call last):\n File \"/usr/bin/pyflakes\", line 9, in <module>\n load_entry_point('pyflakes==1.0.0', 'console_scripts', 'pyflakes')()\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/api.py\", line 172, in main\n warnings = checkRecursive(args, reporter)\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/api.py\", line 129, in checkRecursive\n warnings += checkPath(sourcePath, reporter)\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/api.py\", line 96, in checkPath\n return check(codestr, filename, reporter)\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/api.py\", line 57, in check\n w = checker.Checker(tree, filename)\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/checker.py\", line 294, in __init__\n self.handleChildren(tree)\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/checker.py\", line 567, in handleChildren\n self.handleNode(node, tree)\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/checker.py\", line 609, in handleNode\n handler(node)\n...\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/checker.py\", line 609, in handleNode\n handler(node)\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/checker.py\", line 566, in handleChildren\n for node in iter_child_nodes(tree, omit=omit):\n File \"/usr/lib/python2.7/site-packages/pyflakes-1.0.0-py2.7.egg/pyflakes/checker.py\", line 80, in iter_child_nodes\n if isinstance(field, ast.AST):\nRuntimeError: maximum recursion depth exceeded while calling a Python object\n\nSetting sys.setrecursionlimit(2500) fixes the problem",
"tags": [],
"duplicates": [],
"assignee": "jayvdb",
"milestone": null,
"owner": "jayvdb",
"id": 1507827,
"duplicate_of": null,
"title": "maximum recursion depth exceeded in 1050 string join",
"comments": [
{
"owner": "icordasc",
"content": "So I looked into this a little.\n\nAs you can (maybe) tell by the stack trace what happens is we get stuck in a recursion loop between handleChildren and handleNode. Why?\n\nSo the first thing we see is the Assign statement, and the value of the assign is a BinOp which consists of a left with another BinOp and a right with a string. You might have an idea where this is going. That BinOp then has a BinOp on the left side and a String on the right. Etc. etc. etc.\n\nI don't know how many things like this we'll see in the real world, so my inclination is to maybe figure out what operations we might want to try to flatten before recursing through them if that makes any sense. We could potentially flatten this like so:\n\n [BinOp, String]\n [BinOp, String, String]\n [BinOp, String, String, String]\n ...\n\nBut I have a hunch that'll be slow to do and could end up being impractical for anything other than some what special cases like this one. (I'm also operating on low coffee so it could just be I'm missing an obvious solution.)",
"date_created": "2015-10-31T19:47:08Z"
},
{
"owner": "jayvdb",
"content": "WIP patch up at https://github.com/pyflakes/pyflakes/pull/70\nIt looks like my solution performs roughly equivalently as the current code, with a definite measurable reduction in sys time, but I havent done any extensive timing yet, since the code/timing will need to change quite a bit to fix cases where it currently passes the tests but reports non-existent problems.\n\nA more simplistic approach, suitable for merging promptly, is https://github.com/pyflakes/pyflakes/pull/68",
"date_created": "2016-05-07T06:45:17Z"
},
{
"owner": "jayvdb",
"content": "I ran into this bug on https://pypi.python.org/pypi/idna recently released v2.1, file https://github.com/kjd/idna/blob/master/idna/idnadata.py\n\nThis is ranked 119th most popular package : http://pypi-ranking.info/module/idna\n\nBoth patches fix this bug for idna as well as astroid's test data.",
"date_created": "2016-07-20T12:25:27Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1507827",
"date_created": "2015-10-20T00:56:02Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "https://www.python.org/dev/peps/pep-0492/\n\nadds the following syntax\n\nasync def test(foo):\n\npyflakes reports this as invalid syntax.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jayvdb",
"id": 1511164,
"duplicate_of": null,
"title": "pep492 async def is invalid syntax",
"comments": [
{
"owner": "jayvdb",
"content": "Hmm.\n\nWhen I use the pyflakes script installed by 'python setup.py install', I get the syntax error.\n\nWhen I use 'python3.5 -m pyflakes ... ' there is no syntax error.\n\nThey are both executing the same python binary (checked with strace as this is strange...)",
"date_created": "2015-10-29T00:54:08Z"
},
{
"owner": "asmeurer",
"content": "Probably a Python path (sys.path) issue. Are you maybe running in the pyflakes directory and one is picking up the source from the current directory and the other isn't? \n\nAlso, if you have setuptools installed (you probably do), the pyflakes entry point is a setuptools entry point, meaning it does all manner of wacky stuff to import pyflakes (I'm not clear why the pyflakes setup.py doesn't just use 'scripts': [\"bin/pyflakes\"] for both setuptools and non-setuptools).",
"date_created": "2015-10-29T05:24:12Z"
},
{
"owner": "jayvdb",
"content": "In both cases I was running it in a different directory.\nI've re-tried it with a fresh 3.6, and both methods of invocation work correctly (and because it is fresh, sys.path is crystal clean, so that may be related.)\nHappy for this to be closed, as I'm not likely to spend much time figuring out the cause, and the cause is likely not clearly pyflakes's problem.",
"date_created": "2015-10-29T05:39:15Z"
},
{
"owner": "icordasc",
"content": "What versions of pyflakes were you testing this with? This was fixed in 1.0.0 (if I recall the version correctly).\n\nYou can see the support was added in https://github.com/pyflakes/pyflakes/blob/master/pyflakes/checker.py#L653..L654",
"date_created": "2015-10-29T13:45:18Z"
},
{
"owner": "jayvdb",
"content": "I am using master.",
"date_created": "2015-10-29T13:59:29Z"
},
{
"owner": "icordasc",
"content": "Are you sure you didn't initially install pyflakes on a version of Python where the async keywords were actually invalid syntax?",
"date_created": "2015-10-29T14:54:42Z"
},
{
"owner": "jayvdb",
"content": "I used strace to check both invocations were using python3.5 . I didnt spend more time understanding why /usr/bin/pyflakes wasnt working, at the time, and now I've only briefly tried and havent been able to reproduce it.\nAgain, I'm happy for this to be closed unless there is a likely cause specific in pyflakes.",
"date_created": "2015-11-06T05:15:09Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1511164",
"date_created": "2015-10-29T00:37:09Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "I am using flake8 on some Python code and after upgrading to 2.5.0 from 2.4.1 (which upgraded pyflakes) I started getting this error:\n\nTraceback (most recent call last):\n File \"/home/gozdalik/.virtualenvs/starfish/bin/flake8\", line 11, in <module>\n sys.exit(main())\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/main.py\", line 33, in main\n report = flake8_style.check_files()\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/engine.py\", line 176, in check_files\n return self._retry_serial(self._styleguide.check_files, paths=paths)\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/engine.py\", line 167, in _retry_serial\n return func(*args, **kwargs)\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pep8.py\", line 1670, in check_files\n self.input_dir(path)\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pep8.py\", line 1706, in input_dir\n runner(os.path.join(root, filename))\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/engine.py\", line 121, in input_file\n return fchecker.check_all(expected=expected, line_offset=line_offset)\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pep8.py\", line 1412, in check_all\n self.check_ast()\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pep8.py\", line 1358, in check_ast\n checker = cls(tree, self.filename)\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/_pyflakes.py\", line 43, in __init__\n withDoctest=self.withDoctest)\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pyflakes/checker.py\", line 294, in __init__\n self.handleChildren(tree)\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pyflakes/checker.py\", line 567, in handleChildren\n self.handleNode(node, tree)\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pyflakes/checker.py\", line 609, in handleNode\n handler(node)\n File \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pyflakes/checker.py\", line 686, in GLOBAL\n global_scope = self.scopeStack[global_scope_index]\nIndexError: list index out of range\n\nThe code I'm running pyflakes on is proprietary so unfortunately I can't share it. Any idea how to help debugging this issue?",
"tags": [],
"duplicates": [],
"assignee": "jayvdb",
"milestone": null,
"owner": "gozdal",
"id": 1512184,
"duplicate_of": null,
"title": "List index out of range on scopeStack ",
"comments": [
{
"owner": "jayvdb",
"content": "The relevant code was added in https://github.com/pyflakes/pyflakes/commit/03ffc76367c2910f37908105391c425cc4ae52da\n\nAnd I am quite sure that \"global_scope_index = 1 if self.withDoctest else 0\" is wrong.\n\nAnd https://github.com/pyflakes/pyflakes/pull/38 should fix the problem for you.",
"date_created": "2015-11-02T22:31:24Z"
},
{
"owner": "bitglue",
"content": "Can you reduce the code that causes the failure to a minimal example that you can share?",
"date_created": "2015-11-03T14:53:03Z"
},
{
"owner": "gozdal",
"content": "Do you have any tips how do I go doing that? From the stack it not obvious\nto me which file is causing the problem.\n\nwt., 3.11.2015 o 10:01 u\u017cytkownik Phil Frost <email address hidden> napisa\u0142:\n\n> Can you reduce the code that causes the failure to a minimal example\n> that you can share?\n>\n> --\n> You received this bug notification because you are subscribed to the bug\n> report.\n> https://bugs.launchpad.net/bugs/1512184\n>\n> Title:\n> List index out of range on scopeStack\n>\n> Status in Pyflakes:\n> New\n>\n> Bug description:\n> I am using flake8 on some Python code and after upgrading to 2.5.0\n> from 2.4.1 (which upgraded pyflakes) I started getting this error:\n>\n> Traceback (most recent call last):\n> File \"/home/gozdalik/.virtualenvs/starfish/bin/flake8\", line 11, in\n> <module>\n> sys.exit(main())\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/main.py\",\n> line 33, in main\n> report = flake8_style.check_files()\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/engine.py\",\n> line 176, in check_files\n> return self._retry_serial(self._styleguide.check_files, paths=paths)\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/engine.py\",\n> line 167, in _retry_serial\n> return func(*args, **kwargs)\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pep8.py\",\n> line 1670, in check_files\n> self.input_dir(path)\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pep8.py\",\n> line 1706, in input_dir\n> runner(os.path.join(root, filename))\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/engine.py\",\n> line 121, in input_file\n> return fchecker.check_all(expected=expected, line_offset=line_offset)\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pep8.py\",\n> line 1412, in check_all\n> self.check_ast()\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pep8.py\",\n> line 1358, in check_ast\n> checker = cls(tree, self.filename)\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/flake8/_pyflakes.py\",\n> line 43, in __init__\n> withDoctest=self.withDoctest)\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pyflakes/checker.py\",\n> line 294, in __init__\n> self.handleChildren(tree)\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pyflakes/checker.py\",\n> line 567, in handleChildren\n> self.handleNode(node, tree)\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pyflakes/checker.py\",\n> line 609, in handleNode\n> handler(node)\n> File\n> \"/home/gozdalik/.virtualenvs/starfish/local/lib/python2.7/site-packages/pyflakes/checker.py\",\n> line 686, in GLOBAL\n> global_scope = self.scopeStack[global_scope_index]\n> IndexError: list index out of range\n>\n> The code I'm running pyflakes on is proprietary so unfortunately I\n> can't share it. Any idea how to help debugging this issue?\n>\n> To manage notifications about this bug go to:\n> https://bugs.launchpad.net/pyflakes/+bug/1512184/+subscriptions\n>\n",
"date_created": "2015-11-03T19:40:50Z"
},
{
"owner": "jayvdb",
"content": "This is easy to reproduce -- the problem occurs whenever `global` is used in the module scope when `self.withDoctest` is enabled, because the use of `self.withDoctest` is very wrong in determining scope levels.\n\nCreate a file `global_scope_bug.py` containing only `global foo`, and enable doctests.\n\nPYFLAKES_DOCTEST=1 PYTHONPATH=. python -m pyflakes global_scope_bug.py\n\nAnd my patch does fix it, but I'll refresh it to add tests and a more detailed commit message.",
"date_created": "2015-11-04T01:55:09Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1512184",
"date_created": "2015-11-01T23:43:49Z"
},
{
"status": "New",
"security_related": false,
"description": "```\ncoreyf@frewbook-pro /tmp> cat a.py\nimport a.b\n```\n\n```\ncoreyf@frewbook-pro /tmp> flake8 a.py\na.py:1:1: F401 'a' imported but unused\n```\n\nExpected output:\n\n```\ncoreyf@frewbook-pro /tmp> flake8 a.py\na.py:1:1: F401 'a.b' imported but unused\n```",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "frewsxcv",
"id": 1512877,
"duplicate_of": null,
"title": "Misleading 'unused import' message ",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1512877",
"date_created": "2015-11-03T21:27:43Z"
},
{
"status": "New",
"security_related": false,
"description": "PEP 479 (https://www.python.org/dev/peps/pep-0479/) changes \"raise StopIteration\" inside a generator to cause RuntimeError to be raised (previously, it would stop the generator, same as \"return None\").\n\nThis feature is so far only available as a __future__ import in Python 3.5. \n\nDue to the way __future__ imports work, it's not possible to use \"from __future__ import generator_stop\" and support Python < 3.5 at the same time. Hence, a check on the source, i.e., pyflakes, is a good workaround (I guess there's also a deprecation warning which can be enabled, but checking code without running it is still useful). \n\nOne thing I'm still a little unclear about is if you'd ever still want to raise StopIteration legitimately, even with the new behavior. The fact that it's now a RuntimeError + a deprecation warning seems to indicate no to me, but I could be wrong.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1515396,
"duplicate_of": null,
"title": "Warn on \"raise StopIteration\"",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1515396",
"date_created": "2015-11-11T20:55:12Z"
},
{
"status": "New",
"security_related": false,
"description": "Assume the following code:\n\ntry:\n fd = open(filename, 'r')\nfinally:\n if fd is not None:\n fd.close()\n\nThis would raise \"UnboundLocalError: local variable 'fd' referenced before assignment\" if opening the file fails e.g. because of no permissions/not existing files/etc..\nIt would be very nice if pyflakes detect this kind of error and warn about the use of 'fd' in the finally block if 'fd' is created inside of the try-block.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "spaceone",
"id": 1522024,
"duplicate_of": null,
"title": "detect \"referenced before assignment\" variables",
"comments": [
{
"owner": "jayvdb",
"content": "Note that this would cause errors for 'valid' code, when finally referenced a variable created only in try: which *may* have been bound before the exception. The coder may know 99% that the variable created in the try block will never fail (except maybe out of memory errors, I suppose). e.g. something like\n\n----\ntry:\n bar = foo.x\n baz = bar.y\nfinally:\n if bar is not None:\n bar.z\n----\n\nAnyway, it is extremely prone to bugs, so IMO it is acceptable to error in that scenario.\n\nI suspect this is quite easy to solve moderately well.\n\nInstead of simply processing all TRY children nodes sequentially\n\nhttps://github.com/pyflakes/pyflakes/blob/master/pyflakes/checker.py#L1092\n\nprocess `finally:` children first, and then the `try:`, `except:` and `else:` children.\n\nThe better approach would be to save a copy of the contents of the scope before processing the `try:` children nodes, and use that saved copy of the scope while processing the `finally:` children. That way it is possible to check whether the referenced names were created during the `try:` branch.",
"date_created": "2015-12-03T01:08:51Z"
},
{
"owner": "asmeurer",
"content": "I think it's a good idea. I've been bitten by it before with something like\n\ntry:\n p = subprocess.Popen([cmd])\n p.communicate()\nfinally:\n return p.returncode\n\nwhere cmd is not found. It's worse in Python 2 where the exceptions don't chain, but a NameError or UnboundLocalError looks bad regardless. It's also a good reason to use context managers instead of try/finally when possible, and to minimize the code that is inside of a try block. \n\nBut I suppose it would be good to also check some real code for potential false positives. ",
"date_created": "2015-12-03T01:55:32Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1522024",
"date_created": "2015-12-02T13:33:35Z"
},
{
"status": "New",
"security_related": false,
"description": "Working with some NumPy code recently, I accidentally wrote this:\n\n<build output array>\n<build mask array>\n\nout[mask] == NaN # This should have been a single `=`, not a ==.\nreturn out\n\nAfter a few minutes of debugging my NaN-less array, I realized that I had accidentally written `==` instead of `=`, turning my assignment statement into no-op comparison operator.\n\nI'd be nice if PyFlakes gave a warning for a statement that's just an expression performing an equality comparison. There are very few cases where I'd expect that something like this is doing what the author intended.\n\nA more aggressive version of this check would be to warn on any expression that's just a binary operator. The assumption there would be that the \"statement\" `a + b` is at best dead code, and at worst an operator with a highly non-obvious side-effect.\n\nI'd be happy to work on either version of this if there's support for it.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "scoutoss",
"id": 1523001,
"duplicate_of": null,
"title": "Warn on Unassigned `==` Expression as Statement",
"comments": [
{
"owner": "jayvdb",
"content": "A minimal fix detecting ast.Compare within ast.Expr is simple.\n\nAfter a little playing, I think the best vector to approach this is to add checking of ast.Expr children nodes.\nExpr is a fallback node type, only occurring when Assign, If, etc are not present. Generally speaking, Expr means an unused expression.\nThere are a few cases where it is needed, such as docstrings (Str), yield, Call being the main one, some dubious cases like Attribute and Name which should have side effects but often do, and then all binary, bool and compare ops which should ever be found in an Expr context.\n\nOne significant problem is the pyflakes test suite extensively uses code snippets that include unused expressions so the snippet is simple, so a good fix will need to alter lots of tests so the code tested is more like real code.",
"date_created": "2015-12-05T07:12:52Z"
},
{
"owner": "jayvdb",
"content": "\"..like Attribute and Name which should have side effects but often do..\"\n\nshould have been\n\n\"..like Attribute and Name which should *not* have side effects but often do..\"\n\nI've put up a PR for an even more aggressive solution that Scott proposed, reporting at any Expr which is likely unused.\n\nhttps://github.com/pyflakes/pyflakes/pull/55\n\nIt doesnt introduce many tests explicitly about the new error condition; at present I am mostly interested in whether any sensible use of Expr are being prevented with this new error.\n\nThat still allows plain `foo` (ast.Name) which is almost always silly except when being used inside try block with exception NameError caught, and the more useful `foo.bar` (ast.Attribute) which is often used to trigger an AttributeError. I could add a bit of logic to only allow these two within a try: block.\n\nAlso allowed is `...` which in Python 3 can be used as a placeholder, and it should be a separate error condition if pyflakes is going to treat it as problematic. pyflakes tests also use that syntax.",
"date_created": "2015-12-05T12:14:41Z"
},
{
"owner": "asmeurer",
"content": "Strictly speaking, it is possible for a[b] == c to have side-effects, and hence be used as a standalone statement. ",
"date_created": "2015-12-05T20:02:14Z"
},
{
"owner": "jayvdb",
"content": "Agreed. However many of the side-effects of \"a[b] == c\", most notably defaultdict population, could be obtained by using \"a[b]\" instead. \"a[b]\" can be permitted by adding ast.Subscript to the list of allowed Expr node types.\n\nIf pyflakes really needs to permit \"a[b] == c\", could we introduce a 'strict' mode that reports extremely dubious cases.\n\nWorth noting there are only four hits in the cpython tip\nOne is Lib/getpass.py:177, which is using a tuple to assert two names exist in an imported module. This report would be avoided by being more permissive in try: blocks.\n\nThe other three of them are code introduced for http://bugs.python.org/issue23780 , which is intentionally triggering an exception.",
"date_created": "2015-12-05T21:48:45Z"
},
{
"owner": "jayvdb",
"content": "At the beginning of December I put up a patch for this: https://github.com/pyflakes/pyflakes/pull/55\n",
"date_created": "2016-02-08T18:16:08Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1523001",
"date_created": "2015-12-05T00:09:07Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "operator matmul in Python 3.6 is not handled. It should be ignored like all of the other operators.",
"tags": [
"easy"
],
"duplicates": [
1551671
],
"assignee": "myint",
"milestone": null,
"owner": "jayvdb",
"id": 1523163,
"duplicate_of": null,
"title": "matmul not handled",
"comments": [
{
"owner": "sorin-sbarnea",
"content": "I get this error on Python 3.5, not 3.6:\n\nFile \"/Users/sorins/bmll/flare/env/lib/python3.5/site-packages/pyflakes/checker.py\", line 567, in handleChildren \nself.handleNode(node, tree) \nFile \"/Users/sorins/bmll/flare/env/lib/python3.5/site-packages/pyflakes/checker.py\", line 608, in handleNode \nhandler = self.getNodeHandler(node.__class__) \nFile \"/Users/sorins/bmll/flare/env/lib/python3.5/site-packages/pyflakes/checker.py\", line 462, in getNodeHandler \nself._nodeHandlers[node_class] = handler = getattr(self, nodeType) \nAttributeError: 'FlakesChecker' object has no attribute 'MATMULT' \n",
"date_created": "2016-03-01T11:32:37Z"
},
{
"owner": "myint",
"content": "Sorin, you are not using the latest pyflakes. You need to clone it from https://github.com/pyflakes/pyflakes.",
"date_created": "2016-03-01T13:56:20Z"
},
{
"owner": "sorin-sbarnea",
"content": "Thanks for the hint. Still, I think I prefer to disable pyflakes completely instead of having to use trunk edition on an entire CI environment. It should not be too hard to get a new bugfix release on pypi. I even automated this on few projects.",
"date_created": "2016-03-01T14:09:25Z"
},
{
"owner": "bitglue",
"content": "I just uploaded 1.1.0 to pypi which should resolve this issue.",
"date_created": "2016-03-01T15:34:21Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1523163",
"date_created": "2015-12-05T21:51:49Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "When given the following code, pyflakes 1.0.0 exits successfully without any output:\n\n\nfoo = None\n\ndef func1():\n bar\n\ndef func2():\n global foo\n\n\nIf func1 is moved to after func2, pyflakes correctly detects that 'bar' is undefined.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "josh-elsasser",
"id": 1526893,
"duplicate_of": null,
"title": "\"undefined name\" silenced by unrelated global",
"comments": [
{
"owner": "jayvdb",
"content": "I believe this has already been fixed in master with https://github.com/pyflakes/pyflakes/pull/41 , and is waiting for release. Try installing from master at https://github.com/pyflakes/pyflakes",
"date_created": "2015-12-16T18:56:14Z"
},
{
"owner": "jayvdb",
"content": "That bug fix and a few others should probably be released promptly as 1.1.0",
"date_created": "2015-12-16T19:20:31Z"
},
{
"owner": "josh-elsasser",
"content": "Confirmed, sorry for the noise.",
"date_created": "2015-12-16T22:33:12Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1526893",
"date_created": "2015-12-16T16:59:04Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "`raise` without any arguments inside an exception block can re-raise the exception.\n\noutside an exception block it causes the following on at least 2.7:\n\nTypeError: exceptions must be old-style classes or derived from BaseException, not NoneType",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jayvdb",
"id": 1528539,
"duplicate_of": null,
"title": "raise not inside exception block",
"comments": [
{
"owner": "jayvdb",
"content": "Fix PR: https://github.com/pyflakes/pyflakes/pull/57",
"date_created": "2015-12-22T12:57:44Z"
},
{
"owner": "bitglue",
"content": "This is valid Python code:\n\ndef foo():\n raise\n\ndef bar():\n try:\n raise Exception()\n except:\n foo()\n\nAs such, a `raise` outside an `except:` block isn't an error per se: it depends on the call stack from which its called. Since we can't know that until runtime I don't think it's something Pyflakes can check.",
"date_created": "2015-12-23T13:08:32Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1528539",
"date_created": "2015-12-22T11:37:48Z"
},
{
"status": "New",
"security_related": false,
"description": "It would be great if PyFlakes could catch users specifying duplicate keys in dictionary literals, e.g.,\n\n d = {\n 'a': 1,\n 'b': 2,\n 'a': 3,\n }\n\nThat second 'a' would be useful to be warned about.",
"tags": [
"easy"
],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "icordasc",
"id": 1530909,
"duplicate_of": null,
"title": "Detect duplicate keys in dictionary literals",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1530909",
"date_created": "2016-01-04T16:27:44Z"
},
{
"status": "New",
"security_related": false,
"description": "Using pyflakes 8.1 on this code does not raise error :\n\nimport sys\nprint >>sys.stderr, \"Hello\"\n\n\nLaunched with :\n\npython3 -m pyflakes hello.py",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jpinon",
"id": 1541912,
"duplicate_of": null,
"title": "accept python2 print syntax in python 3 files",
"comments": [
{
"owner": "asmeurer",
"content": "It's valid syntax in Python 3. >> is the right shift operator, and the comma creates a tuple. If you run the code, you'll see that it raises a TypeError, not a SyntaxError. Unless pyflakes is going to do some basic operator type checking on builtins (could be a good idea?) it's not going to detect this. ",
"date_created": "2016-02-04T16:18:40Z"
},
{
"owner": "jayvdb",
"content": "fwiw, flake8 plugin `hacking` emits:\n\nH233 Python 3.x incompatible use of print operator\n\nand `flake8-print` emits\n\nT001 print statement found.\n\nIt seems reasonable and straight forward for pyflakes to also detect this on Python 3 only.\n\nHowever, to do this right, pyflakes needs an accurate understanding of `__future__.print_function` so that the error also occurs on Python 2 when `print_function` is active. That should be fairly easy also now, as __future__ in doctest is now correctly detected (see https://github.com/pyflakes/pyflakes/commit/9c88c0ec3f4cdb0fb2e69c2bdadc0bdd03da4a55 ).",
"date_created": "2016-02-08T18:41:07Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1541912",
"date_created": "2016-02-04T16:06:38Z"
},
{
"status": "New",
"security_related": false,
"description": "Python 3.6 now has a SyntaxWarning for unused constants.\n\nhttp://bugs.python.org/issue26204\n\nPyflakes could implement the same for Python 3.5 and lower.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jayvdb",
"id": 1543246,
"duplicate_of": null,
"title": "unused constants",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1543246",
"date_created": "2016-02-08T18:48:00Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Since pyflakes 1.2.0, running it over this file:\n\n import os.path\n import os\n assert os\n\nproduces:\n\n x.py:2: redefinition of unused 'os' from line 1\n\nSwitching the order of the imports works around the issue, but I think this shouldn't be an error.",
"tags": [],
"duplicates": [],
"assignee": "jayvdb",
"milestone": null,
"owner": "qbuntuone",
"id": 1578051,
"duplicate_of": null,
"title": "1.2.0: F811 when importing os/os.path",
"comments": [
{
"owner": "jayvdb",
"content": "Very likely to be a bug in my patch, which was supposed to have zero effect, except for improving the error messages, but it looks like this scenario wasnt covered in the tests (the inverse scenario was covered, as you've found).\n\nhttps://github.com/pyflakes/pyflakes/commit/aec68a7847d8dbd1371242f42f9302103a68178f",
"date_created": "2016-05-04T05:12:29Z"
},
{
"owner": "jayvdb",
"content": "The simple fix for that specific problem is https://github.com/jayvdb/pyflakes/commit/2ba836ad18168b9ba3f0d53273da217a9e4d1bb9\nBuild OK at https://travis-ci.org/jayvdb/pyflakes/builds/127720312\n\nFeel free to pull it in and release a bug fix release if this is a serious problem.\n\nHowever I would like a few more hours to dig further, to ensure there are no other corner cases.\n\nfwiw, I believe there is an lp bug asking that both of these are an error, as `os.path` is unused, even though `os` is used. Need to find that bug also.",
"date_created": "2016-05-04T07:16:19Z"
},
{
"owner": "qbuntuone",
"content": "Thanks for the quick fix! I'm okay with waiting a bit for a patch release, I just blacklisted 1.2.0 for now :)\n\n> fwiw, I believe there is an lp bug asking that both of these are an error, as `os.path` is unused, even though `os` is used. Need to find that bug also.\n\nGood point, though that was just an oversight in my example - my real code where I noticed this uses both os and os.path.",
"date_created": "2016-05-04T08:32:44Z"
},
{
"owner": "jayvdb",
"content": "https://github.com/pyflakes/pyflakes/pull/62\n\nand fwiw again, the other lp bug I was thinking of is https://bugs.launchpad.net/pyflakes/+bug/1153355",
"date_created": "2016-05-04T13:37:12Z"
},
{
"owner": "jayvdb",
"content": "Released as 1.2.1",
"date_created": "2016-05-07T16:06:11Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1578051",
"date_created": "2016-05-04T04:58:01Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "I like reading changelogs of projects I'm using ;)\n\nUnfortunately it seems like NEWS of pyflakes didn't get updated anymore since 0.9.2 - is that intentional?",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "qbuntuone",
"id": 1578115,
"duplicate_of": null,
"title": "NEWS not up-to-date",
"comments": [
{
"owner": "bitglue",
"content": "It should be updated in the 1.2.0 release, is it not?",
"date_created": "2016-05-04T11:27:11Z"
},
{
"owner": "qbuntuone",
"content": "Ah - it's updated at https://github.com/pyflakes/pyflakes/blob/master/NEWS.txt but not http://bazaar.launchpad.net/~pyflakes-dev/pyflakes/master/view/head:/NEWS.txt - is the bzr repo even still used or is only the issue tracker on launchpad?",
"date_created": "2016-05-04T11:44:00Z"
},
{
"owner": "bitglue",
"content": "The bzr repo is just a mirror of the git repo, plus replication lag, made worse because I forgot to push master last night. I just started an import so it should be updated soon.",
"date_created": "2016-05-04T12:04:02Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1578115",
"date_created": "2016-05-04T08:35:19Z"
},
{
"status": "New",
"security_related": false,
"description": "pyflakes makes it hard to check code that works on python 2 and 3 because some names are only defined in one version.\n\nFor example, take this little module:\n\n\nimport sys\n\ndef type_is_str(var):\n ''' returns True if the given variable is a str (or unicode string when using python 2)'''\n if type(var) == str:\n return True\n elif sys.version_info[0] < 3 and type(var) == unicode: # python 2 also uses the 'unicode' type\n return True\n else:\n return False\n\n\npyflakes3 errors out with\n undefined name 'unicode'\nwhile pyflakes2 validates this code successfully (because unicode is a valid name in py2).\n\nCan you make pyflakes a bit more intelligent so that it skips branches for the \"wrong\" version? Or, if that is too hard, add a way to skip a line marked with a special comment like\n # PYFLAKES:IGNORE\n?\n\n(The py3 testing was done with python3-pyflakes-1.2.3.)",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "cboltz",
"id": 1585991,
"duplicate_of": null,
"title": "undefined name 'unicode' in \"wrong\" sys.version_info branch",
"comments": [
{
"owner": "asmeurer",
"content": "For what it's worth, your 'type_is_str\" is wrong way to check if something is a string. You shouldn't use \"type(x) == T\". You should instead use \"isinstance(x, T)\". The more common way to do this is to define\n\nif PY3:\n string_types = (str,)\nelse:\n string_types = (str, unicode) # You can also use basestring\n\nand then check \"isinstance(var, string_types)\" in your code.\n\nAs to the issue itself, Pyflakes would have to become significantly smarter to be able to parse all the different ways that people check for Python 3. It would need to be able to parse \"sys.version_info[0] < 3\", and similar constructs in full enough generality to catch every way that people write it, but in a static way. I'm not saying it can't be done, but Pyflakes would have to be about 100x smarter than it is now to be able to handle this sort of thing. I recommend factoring all your Python 2/3 logic into a single file and then don't bother testing that file with pyflakes. Or use a library like six or future. ",
"date_created": "2016-05-26T18:41:14Z"
},
{
"owner": "jayvdb",
"content": "In most cases you can do the following as a workaround for this pyflakes issue:\n\nif PY3:\n unicode = str\n\nThen unicode is a valid name, even if it isnt used.\n\nIMO if pyflakes was to fix this, it should allow the project to define PYxx names (e.g. PY3) with an environment marker somewhere (tox.in), and then pyflakes can look for those simple names in the code being analyised.",
"date_created": "2016-05-26T19:27:13Z"
},
{
"owner": "asmeurer",
"content": "I'm not a fan of that workaround because most Python 2/3 names like that were the result of Python 3 removing a name (unicode, long, xrange, ...), and redefining them in Python 3 leads to a coding style where you write Python 2 code and use compatibility imports to make it work in Python 3. But I prefer to write Python 3 code and use compatibility imports to make it work in Python 2. ",
"date_created": "2016-05-26T19:47:57Z"
},
{
"owner": "jayvdb",
"content": "Agreed, but it can work, especially for projects where that is the reality: used primarily on Python 2 for a decade, and Python 3 is supported but is second class.\n\nI find comments in code distasteful in general, but necessary in practise, but I am very opposed to '\u00edgnore' style comments in pyflakes (use flake8 & flake8-putty if you want that).\n\nWhat would be nice is a way to declare environment differences where they are needed via comments or another noop, with environment markers to safe guard.\n\nI.e. for the problem in this ticket, inject builtins into the inner most scope at the point in the scope where it is needed only. E.g. (untested)\n\n import sys\n PY3 = sys.version_info[0] == 3\n\n def foo(a):\n if PY3:\n return isinstance(a, str)\n else:\n # pyflakes builtin: unicode, basestring, WindowsError; python_version < '3' and sys_platform == 'win32'\n return isinstance(a, basestring)\n\nThen pyflakes can:\n1. When that environment marker is True, verify all those builtins exist\n2. When that environment marker is False, inject any missing builtins\n\nThat way, provided pyflakes is used on all relevant platforms to achieve 100% coverage of these platform specific branches, the declarative comment must be maintained or pyflakes will barf, and the builtins will exist.\n\nThe remaining weakness of that is when someone adds code below that if statement, and then uses \u00f9nicode in code which executes in all environments -- pyflakes will not notice.\n\nTo provide a fool-proof solution, the injected builtins could only be registered at the top of a function, and the recommended pattern is to have alternative functions for each distinct environment.\n\ni.e.\n\ndef _py2_foo(a):\n # pyflakes builtins: ... ; ...\n ...\n\ndef _py3_foo(a):\n # pyflakes builtins: ... ; ...\n ...\n\nif PY2:\n foo = _py2_foo\nelse:\n foo = _py3_foo",
"date_created": "2016-05-27T07:52:07Z"
},
{
"owner": "jayvdb",
"content": "(...Comments in code *to assist tools*...)",
"date_created": "2016-05-27T07:52:54Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1585991",
"date_created": "2016-05-26T10:47:02Z"
},
{
"status": "New",
"security_related": false,
"description": "Hi,\n\nthanks for this really great tool!\nOne issues I stumbled upon was that type hints seem to be ignored / not detected.\nFor example, we have an import at the top of a file:\n\n from typing import List\n\nAnd then later in an __init__ function something like this:\n\n self.scripts = [] # type: List[script.Script]\n\n\nNow running pyflakes (through flake8) gives me this error:\n\n foo.py:4:1: F401 'List' imported but unused\n\n\nPEP484 defines this kind of type comments.\nIs there an option to enable type hint detection?\nOr 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 :)\n\nThanks!",
"tags": [
"comments",
"hints",
"pep484",
"type"
],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "w-thomas-q",
"id": 1587170,
"duplicate_of": null,
"title": "Detect type hints: PEP484",
"comments": [
{
"owner": "asmeurer",
"content": "Is it really necessary to have the unused imports for the typing comments to work? ",
"date_created": "2016-06-10T21:17:15Z"
},
{
"owner": "icordasc",
"content": "asmeurer I've asked repeatedly that it not be necessary. That said, mypy-lang folks continue to insist it is necessary.\n\nRegardless, I don't think pyflakes wants to do PEP 484 work since that's mypy-lang's area of expertise Thomas. Further, pyflakes needs a better AST considering the current one does *not* preserve comments. Without preserving comments, PyFlakes cannot introspect comments for # type: Foo to find that it is being used.",
"date_created": "2016-06-10T21:53:21Z"
},
{
"owner": "tabbott",
"content": "https://github.com/dropbox/typed_ast is a fork of the AST module that preserves type comments (and is used by mypy-lang); using that might be an option for allowing pyflakes to support the Python 2 type comment syntax.",
"date_created": "2016-09-21T20:19:11Z"
},
{
"owner": "qwertystop",
"content": "Apart from whether or not pyflakes intends to support type hinting, it currently marks it as a syntax error (on arguments and return types):\n\ndef echo(arg: str) -> str:\n return arg\n\nIt marks invalid syntax at the first colon, and at the dash if the type hint on argument is removed.",
"date_created": "2016-09-25T19:59:59Z"
},
{
"owner": "asmeurer",
"content": "Make sure your pyflakes is running in Python 3. Pyflakes detects syntax errors based on the version of Python it is running from. If you run pyflakes from Python 2 on Python 3-only code, it will complain about syntax errors. The easiest way to do this is to run \n\npython3 -m pyflakes yourfile.py",
"date_created": "2016-09-25T21:12:24Z"
},
{
"owner": "qwertystop",
"content": "Oh, oops. Found that just a few minutes ago when I was going to file something similar for keyword-only args. Was running pyflakes at two removes (via prospector, through the \"syntastic\" vim plugin), and didn't realize that it wasn't automatic for versions.",
"date_created": "2016-09-25T21:18:48Z"
},
{
"owner": "happycamp",
"content": "Please fix the imported but unused errors for the typing library.\n\nI'm running into those when adding type hints to my python code.\n\nCurrently doing:\n\n from typing import Any, Dict, List, Tuple, Union # noqa\n\nAs a work-around.",
"date_created": "2017-03-03T17:12:21Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1587170",
"date_created": "2016-05-30T19:47:29Z"
},
{
"status": "Incomplete",
"security_related": false,
"description": "The following code raises an F401 error.\n\n```\nimport scipy.optimize\nimport scipy as sp\n\nprint(sp.optimize)\n```\n\nI don't see any obvious workaround. I used to do:\n\n```\nimport scipy.optimize\nsp = scipy\n\nimport numpy\n\nprint(sp.optimize)\n```\n\nbut now flake8 correctly flags the line \"sp = scipy\" as E402 module level import not at top of file, so this workaround is less useful. (One could put all the module assignments at the end, but this is not very good for reading the code.)\n\nI seem to recall discussing this at some point but cannot find the old discussion.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "mforbes-physics",
"id": 1589186,
"duplicate_of": null,
"title": "F401 erroneously raised with \"import as\"",
"comments": [
{
"owner": "jayvdb",
"content": "So the flake8 error F401 is pyflakes reporting the following for line 1: 'scipy.optimize' imported but unused.\n\nWhich is correct for the sample code you have given.\n\nscipy.optimize is unused, as the object with name 'scipy' is not accessed on line 2; instead the import on line 2 creates a new object 'sp' which just happens to be a module called 'scipy' in the import lookup system.\n\nSo I dont believe this is a bug, based on the sample code provided.\n\nI am guessing that you dont really want to print scipy.optimize ? You are trying to hide the error, by doing a dummy usage?\n\n\nThe following will do the import, and hide the pyflakes error\n\nimport scipy.optimize as _\nimport scipy as sp\n\ndel _\n\ndef x():\n return sp.foo()\n\nIf you really need to print or access scipy.optimize, the this works\n\nimport scipy.optimize\nimport scipy as sp\n\nprint(scipy.optimize)\n\ndef x():\n return sp.foo()\n\nBut maybe your real code cant be solved those ways, in which case let me know the project and I'll take a look at the problem with real code.\n",
"date_created": "2016-06-05T05:09:45Z"
},
{
"owner": "mforbes-physics",
"content": "The print line is simply a way to \"use\" scipy.optimize. A \"real\" usage (MWE) would be\n\n```\nimport scipy.optimize\nimport scipy as sp\n\n\nres = sp.optimize.root(lambda x: x, 1)\n```\n\nThis has the same problem. Your example with del _ is a indeed a workaround (though it is pretty ugly!)\n\n\nIt is extremely common to use scipy, numpy, and matplotlib via:\n\nimport numpy as np\nimport scipy as sp\nfrom matplotlib import pyplot as plt\n\nthen to use np. sp. or plt. in ones code. However, especially with scipy, the top level import does not bring in the whole library, hence the need for \n\nimport scipy.optimize\n\nAlthough this might be difficult to detect, I believe it is a real bug since scipy.optimize is indeed used (just through the standard alias sp.optimize)",
"date_created": "2016-06-05T05:25:57Z"
},
{
"owner": "jayvdb",
"content": "Then a cleaner workaround would be something like\n\nimport scipy.optimize\nimport scipy as sp\n\nassert sp.optimize == scipy.optimize\n\n--\n\nor even just `assert scipy` will do the trick, and will work for multiple scipy.x imports.\n\nThe difficulty is that from a symbol/name perspective, which is what pyflakes mostly uses, the name `scipy` is created in the module and never used.\n\nBut I am seeing your point .. we know that `import scipy.optimize` adds `optimize` to what will be later named `sp`, and it is used with that alias.\n\nThe related problem is that pyflakes doesnt yet do any sanity checking on submodule imports (import x.y). i.e. the following passes\n\nimport scipy.foo\nimport scipy.bar\nscipy.baz\n\nIt should have errors about `scipy.foo` and `scipy.bar` being unused, and `scipy` on line 3 being an implicit import of `scipy`.\n\nBut maybe we can ignore the fact that submodule import usage tracking is not working, and focus on avoiding the error in your scenario of using `import x as y`. i.e. this passes\n\nimport scipy.optimize\nimport scipy\nassert scipy\n\nIn the above, the 'optimize' part is ignored by pyflakes, so why shouldnt the following also pass:\n\nimport scipy.optimize\nimport scipy as sp\nassert sp\n\nI think we have enough information to allow the above the pass, without any regressions.",
"date_created": "2016-06-05T06:51:56Z"
},
{
"owner": "mforbes-physics",
"content": "Again, the reason I am now having an issue is that flake8 adds \"E402 module level import not at top of file\" which requires the assert statement to come after all the imports breaking locality.\n\nIt would be really nice if pyflakes could track the rename of scipy to py, but I think that the best workaround at this point is to del all the unused modules at the end of the import section:\n\n```\nimport scipy.optimize\nimport scipy as sp\n\nimport numpy.linalg\nimport numpy as np\n\n...\n\ndel scipy, numpy\n\n...\n```\n\nThen the statement at least has some meaning - use sp., not scipy. etc. in the code, following conventions.",
"date_created": "2016-06-05T07:14:55Z"
},
{
"owner": "asmeurer",
"content": "The problem is that pyflakes treats imports like variable assignments, but they aren't quite like that. If you write\n\na = func()\n\nand then never use a, pyflakes is right to tell you that a is never used, because you could just as well have written \n\nfunc()\n\nwithout any assignment. But \"import scipy.optimize\" is the only way to load the scipy.optimize module (it isn't loaded with \"import scipy\" for performance purposes). So the purpose of the line is to load a module, but it also happens to load a name into the namespace. \n\nSecondly, it's best practice to import scipy and numpy as sp and np, respectively. \n\n> and `scipy` on line 3 being an implicit import of `scipy`.\n\nI don't think that's an error. Python explicitly runs the top-level __init__.py and puts the module name in the namespace. For instance, this code works just fine\n\nimport numpy.linalg\nnumpy.array\n\n",
"date_created": "2016-06-06T20:30:38Z"
},
{
"owner": "jayvdb",
"content": "I agree pyflakes can special case submodule imports, as they cant be done another way.\nUnless anyone objects, I will do the fix, which I suspect is a one-liner now.\n\n> > and `scipy` on line 3 being an implicit import of `scipy`.\n>\n> I don't think that's an error. Python explicitly runs the top-level __init__.py and puts the module name in the namespace. For instance, this code works just fine\n>\n> import numpy.linalg\n> numpy.array\n\nWhile this is possible, it can also be a problem in complex code. Pywikibot had one such gnarly problem (https://phabricator.wikimedia.org/T113161) which I should extract out into a simple example of how implicit imports can be problematic.",
"date_created": "2016-06-06T21:35:54Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1589186",
"date_created": "2016-06-05T03:40:35Z"
},
{
"status": "New",
"security_related": false,
"description": "This is perhaps a bit obscure, but here's a class of syntax errors that aren't caught by pyflakes\n\n$ cat test.py\ndef test(x):\n global x\n$ pyflakes test.py\n$ python test.py\n File \"test.py\", line 2\n global x\nSyntaxError: name 'x' is parameter and global\n\nI'm unsure what the full set of possible errors are here. One would need to check the Python source. I know there are some others relating to the Python 3 \"nonlocal\" keyword as well.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1590549,
"duplicate_of": null,
"title": "global/local syntax errors not caught",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1590549",
"date_created": "2016-06-08T20:26:11Z"
},
{
"status": "New",
"security_related": false,
"description": "pyflakes correctly warns on using x before defining it in the if branch:\n\ndef bar(a):\n pass\n\n\ndef x_is_bad_if():\n if False:\n x = bar(x)\n else:\n x = bar(1)\n\n return x\n\nHowever, no warning is generated for the else branch:\n\ndef bar(a):\n pass\n\n\ndef x_is_bad_else():\n if False:\n x = bar(1)\n else:\n x = bar(x)\n\n return x",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "yowilfred",
"id": 1597279,
"duplicate_of": null,
"title": "no detection of undefined parameters in else branches",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1597279",
"date_created": "2016-06-29T10:44:08Z"
},
{
"status": "New",
"security_related": false,
"description": "If a program's source uses UTF-8, but the file's encoding is not declared using a `coding` declaration, Pyflakes accepts the program as valid, even though Python itself refuses it.\n\n$ file coding.py\ncoding.py: UTF-8 Unicode text\n$ cat coding.py\nprint \"\u00a1this file contains \u016dnicode!\"\n$ pyflakes --version\n1.2.3\n$ pyflakes coding.py\n$ python coding.py\n File \"coding.py\", line 1\nSyntaxError: Non-ASCII character '\\xc2' in file coding.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details\n$ \n\nExpected outcome: Pyflakes should report a syntax error for such files.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "aaroncrane",
"id": 1608595,
"duplicate_of": null,
"title": "Programs in UTF-8 with no declared coding are accepted",
"comments": [
{
"owner": "aaroncrane",
"content": "",
"date_created": "2016-08-01T16:10:05Z"
},
{
"owner": "icordasc",
"content": "What version of Python are you using and what version of Python is PyFlakes installed on?",
"date_created": "2016-08-01T16:29:15Z"
},
{
"owner": "aaroncrane",
"content": "Both are Python 2.7.12",
"date_created": "2016-08-02T11:06:09Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1608595",
"date_created": "2016-08-01T16:10:05Z"
},
{
"status": "New",
"security_related": false,
"description": "this code gives: undefined name 'j'\n\nfor i in range(10):\n\u00a0\u00a0\u00a0\u00a0if i % 3 == 0:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0j += i\n\u00a0\u00a0\u00a0\u00a0else:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0j = 0\n\u00a0\u00a0\u00a0\u00a0print(j)\n\nwhile the following emits nothing\n\nfor i in range(10):\n\u00a0\u00a0\u00a0\u00a0if not i % 3 == 0:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0j = 0\n\u00a0\u00a0\u00a0\u00a0else:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0j += i\n\u00a0\u00a0\u00a0\u00a0print(j)\n\n\npyflakes --version\n1.2.3\n\nI'm creating a new report besides #1431099 and #1308508 because this is not related to the del statement",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "afg984",
"id": 1612066,
"duplicate_of": null,
"title": "False positive undefined name, which is defined in branch",
"comments": [
{
"owner": "bitglue",
"content": "Pyflakes ignores conditional branches, since short of being a Python interpreter it can't really know if they will branch or not. So all pyflakes sees is this:\n\n\nj += 1\nj = 0\nprint(j)\n\n\nj = 0\nj += 1\nprint(j)\n\n\nCan you think of a way to handle this situation which doesn't involve running the code, and which does not generate false positives?",
"date_created": "2016-08-11T17:05:25Z"
},
{
"owner": "asmeurer",
"content": "I think false positives come from names that aren't defined in conditionals that are used afterwords, like\n\nif something:\n i = 0\nelse:\n # i not defined\nif something:\n f(i)\nelse:\n # code that doesn't use i\n\nIf Pyflakes warned that the first else block didn't define i it would be a false positive, because i is never accessed when the code reaches that control flow.\n\nBut in this case, the variable is not defined *in* the conditional block. I don't see how that could be a false positive. So it's a distinction between\n\n- Variables defined in only a subset of conditionals, and used below (fine)\n- Variables used in a conditional that aren't defined above (not fine)\n",
"date_created": "2016-08-11T17:25:25Z"
},
{
"owner": "afg984",
"content": "In a loop body, conditionals below does not always run before conditionals above\n\nfor example: statement_2 does not necessarily run after statement_1\n\nwhile condition_1:\n if condition_2:\n statement_1\n else:\n statement_2\n\n@bitglue\nI think treating all variables defined in other branches as defined can silence the warning.\nI have no opinions on whether doing this can be justified by the reported case, though.\n\n@asmeurer\nI said false positive because Pyflakes warned of code that can be run in the python interpreter. Maybe I have used the term incorrectly.\n\nAlso, at least to me, the problem seems to be more clear now. I can update the original report if needed.",
"date_created": "2016-08-11T18:29:06Z"
},
{
"owner": "afg984",
"content": "Edit:\nIn a loop body, conditionals below does not always run before conditionals above\nShould be\nIn a loop body, conditionals below does not always run *after* conditionals above",
"date_created": "2016-08-11T18:31:32Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1612066",
"date_created": "2016-08-11T05:58:02Z"
},
{
"status": "New",
"security_related": false,
"description": "The following will always result in\n TypeError: 'bool' object is not iterable\n\nfor a in (1 == 2):\n pass\n\nIt is fairly easy to detect as it is a compare in a for loop.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jayvdb",
"id": 1614338,
"duplicate_of": null,
"title": "detect compare used instead of an iterable",
"comments": [
{
"owner": "asmeurer",
"content": "Seems like part of a larger issue of propagating type inference from literals. int.__eq__(int) returns bool; bool.__iter__() raises TypeError. I would love to see pyflakes do this, but it would be better to do it in a generic way, rather than picking and choosing random examples. \n\nNote that == for general objects could return anything because of __eq__ (and there are definitely some libraries that use it as syntactic sugar). ",
"date_created": "2016-08-18T03:25:50Z"
},
{
"owner": "asmeurer",
"content": "In particular, if a and b are numpy arrays, then a == b is a numpy array (which is iterable). ",
"date_created": "2016-08-18T03:26:44Z"
},
{
"owner": "jayvdb",
"content": "Ya, sorry this is a specific case. I found it while working on https://github.com/PyCQA/pycodestyle/issues/371#issuecomment-240614113 , and thought I better raise it here before I forgot it.\n\nIt is unfortunate that it can only easily be done for literals and built in types, and needs to understand the classes possibly defined in other modules before it could reliably work for anything else.\n\nIm not sure how valuable it is if it only supports literals and built in types.",
"date_created": "2016-08-18T03:52:37Z"
},
{
"owner": "asmeurer",
"content": "I think if it were done generically it would be very useful, because it would catch a lot of typos. Even just spellchecking attribute names on literals would help me out personally quite a bit. ",
"date_created": "2016-08-18T04:25:25Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1614338",
"date_created": "2016-08-18T03:11:28Z"
},
{
"status": "Fix Released",
"security_related": false,
"description": "Seems to occur when checking code that has adjacent string literals. e.g. \"abc\" \"def\", but not totally sure that's the cause.\n\nHopefully this will be easy to spot by looking at your source code. Let me know of you need more info.\n\nBob",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "bobjalex",
"id": 1624098,
"duplicate_of": null,
"title": "AttributeError: 'Checker' object has no attribute 'JOINEDSTR'",
"comments": [
{
"owner": "jayvdb",
"content": "This has been fixed in master - https://github.com/PyCQA/pyflakes/pull/80",
"date_created": "2016-09-15T21:08:47Z"
},
{
"owner": "bobjalex",
"content": "Thanks for reply -- I patched my version and all is well.\n\nOn Thu, Sep 15, 2016 at 2:08 PM, John Vandenberg <email address hidden> wrote:\n\n> This has been fixed in master -\n> https://github.com/PyCQA/pyflakes/pull/80\n>\n> ** Changed in: pyflakes\n> Status: New => Fix Committed\n>\n> --\n> You received this bug notification because you are subscribed to the bug\n> report.\n> https://bugs.launchpad.net/bugs/1624098\n>\n> Title:\n> AttributeError: 'Checker' object has no attribute 'JOINEDSTR'\n>\n> Status in Pyflakes:\n> Fix Committed\n>\n> Bug description:\n> Seems to occur when checking code that has adjacent string literals.\n> e.g. \"abc\" \"def\", but not totally sure that's the cause.\n>\n> Hopefully this will be easy to spot by looking at your source code.\n> Let me know of you need more info.\n>\n> Bob\n>\n> To manage notifications about this bug go to:\n> https://bugs.launchpad.net/pyflakes/+bug/1624098/+subscriptions\n>\n",
"date_created": "2016-09-17T18:38:33Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1624098",
"date_created": "2016-09-15T20:35:42Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Ellipsis is a built-in singleton, also having literal form '...'. For example:\n\ndef foo(arg):\n if arg is ...:\n print(\"yes\")\n else:\n print(\"no\")\n\nPyflakes is reporting it as invalid syntax. It's minor, but the ellipsis is quite convenient when a singleton is needed and None won't work.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "qwertystop",
"id": 1627538,
"duplicate_of": null,
"title": "Reports ellipsis literal as syntax error",
"comments": [
{
"owner": "asmeurer",
"content": "Again, this does work correctly, but you need to run pyflakes in Python 3, since ellipsis literals are Python 3-only. ",
"date_created": "2016-09-26T02:14:39Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1627538",
"date_created": "2016-09-25T20:52:18Z"
},
{
"status": "New",
"security_related": false,
"description": "It's generally bad practice to catch all exception types like this:\n\n try:\n o = open('file.txt', 'rb')\n data = json.loads(o.read())\n except:\n print(\"Can't parse file\")\n\nFor example, sometimes the `except` block handles the wrong sort of exception. There are many sorts of exceptions that could have been thrown in the example above (file not found, bad json format, etc), and the original exception would have done a much better job of informing us of what went wrong. The author should only catch specific types of exceptions for specific ways to handle them.\n\nIt would be great if a rule could be added to catch instances where all exceptions are being handled, either in the above form or with the catch-all `except Exception:`. Where an explicit catch-all could be silenced with a `# NOQA` in instances where they really want everything caught.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "conrad-p-dean",
"id": 1628263,
"duplicate_of": null,
"title": "Warning on the catching of all exception types",
"comments": [
{
"owner": "asmeurer",
"content": "Sadly there are a lot of false positives here, and pyflakes tries to avoid all false positives. While one class of false positives can be ignored easily (if there is a 'raise' call in the except block), not all have that form. It's a bit of a style issue. For those cases where you really do want to catch all exceptions, it \"really\" better to write \"except:\" instead of \"except BaseException:\"? And do you \"really\" want to be catching BaseException instead of Exception? Usually you don't, but not always. \n\n\"except Exception:\", the less bad variant, is very common in acceptable forms (i.e., false positives for a rule that disallows them). ",
"date_created": "2016-09-27T20:40:17Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1628263",
"date_created": "2016-09-27T19:56:44Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "These two lines of the code:\n\n if isinstance(pk_proc.before, basestring):\n cmd_output += pk_proc.before\n\nwill be honored by pyflakes (and flake8) with\n\n libs/proc.py:443:39: F821 undefined name 'basestring'\n\nwhich is just wrong. `basestring` is perfectly defined type and this seems like a quite canonical way how to check (in Py2k) whether the variable is either unicode or str.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "mcepl",
"id": 1636146,
"duplicate_of": null,
"title": "unrecognized type basestring",
"comments": [
{
"owner": "icordasc",
"content": "You seem to be running PyFlakes and Flake8 under python 3. You can verify this by doing `flake8 --version`. basestring is actually *not* defined on Python 3, so if you're writing code for Python 2 (that isn't going to run on Python 3) you should install Flake8 for Python 2 and run it that way too, e.g.,\n\n```\ncurl -O https://bootstrap.pypa.io/get-pip.py\npython2.7 get-pip.py\npython2.7 -m pip install flake8\npython2.7 -m flake8 libs/proc.py\n```",
"date_created": "2016-10-24T15:48:36Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1636146",
"date_created": "2016-10-24T11:20:16Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "Currently, no effort is made to check names from a * import. Attached is a basic patch that does.\n\nIt works by exec'ing the \"from ... import *\" and using a locals dictionary to avoid polluting the module namespace, then adding all the names found as additional bindings. checkDeadScopes is modified to not report unused names from the * import as unused.\n\nA better solution is probably to recursively run pyflakes on the * imported module to avoid possible side effects, but that is beyond my available time.",
"tags": [
"enhancement",
"import",
"star"
],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "ethan-stoneleaf",
"id": 1648647,
"duplicate_of": null,
"title": "* imports are not handled well",
"comments": [
{
"owner": "ethan-stoneleaf",
"content": "",
"date_created": "2016-12-08T22:59:24Z"
},
{
"owner": "ethan-stoneleaf",
"content": "Modified patch to fix the false positive of\n\n... may be undefined, or defined from star imports: ...",
"date_created": "2016-12-09T00:03:02Z"
},
{
"owner": "ethan-stoneleaf",
"content": "",
"date_created": "2016-12-09T00:18:52Z"
},
{
"owner": "asmeurer",
"content": "Patches should be submitted as GitHub pull requests, but a heads up that this is likely to get rejected, as imports can execute arbitrary code (and aside from that, this would slow down pyflakes by quite a bit). ",
"date_created": "2016-12-09T00:45:38Z"
},
{
"owner": "bitglue",
"content": "Indeed. The contribution is appreciated, but pyflakes by design does not execute any of the code being checked.",
"date_created": "2016-12-09T01:34:51Z"
},
{
"owner": "ethan-stoneleaf",
"content": "I did not expect to have the patch accepted as-is. It's mainly a blue print of the needed changes, with the actual acquisition of the * module globals a proof-of-concept.",
"date_created": "2016-12-09T02:13:20Z"
},
{
"owner": "bitglue",
"content": "Please feel free to open a PR on GitHub, though be advised anything that imports or executes code under test will probably not be accepted. It's very slow, and can have undesirable side effects.",
"date_created": "2016-12-09T02:38:25Z"
},
{
"owner": "asmeurer",
"content": "Even a static check would have to make some assumptions about the state of the file system and sys.path when the import happens. That could mean weird errors where pyflakes passes or fails depending on what version of a dependency happens to be installed, but a more realistic problem is that you have to deal with egg .pth files and all that nonsense. \n\nWhich isn't to say I necessarily think it can't or shouldn't be done (with some loose assumptions). But I've always felt that import * is \"bad\" anyway and pyflakes bailing on it isn't a huge deal. \n\nException: relative import * imports in __init__.py. I really wish those worked. Maybe limiting this to only relative imports would be acceptable? I know Phil has already stated in other issues that pyflakes reading code from other files in the same module would be acceptable for pyflakes. ",
"date_created": "2016-12-09T02:54:49Z"
},
{
"owner": "ethan-stoneleaf",
"content": "No worries of pyflakes failing -- if it's unable to read the * module it falls back to the default behavior.",
"date_created": "2016-12-09T03:10:48Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1648647",
"date_created": "2016-12-08T22:59:24Z"
},
{
"status": "New",
"security_related": false,
"description": "pyflakes reports F821 for \"undefined name '__module__'\", which is part of a set of available builtins: https://docs.python.org/3/reference/datamodel.html\n\n\nCode to reproduce: https://gist.github.com/jreese/f81d30c867ed2eaeb3bd25318da29686\n\nRunning `pyflakes foo.py` generates F821 for the above code, but this value should be not be considered undefined.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "jreese",
"id": 1648651,
"duplicate_of": null,
"title": "f821 reports __module__ as undefined",
"comments": [
{
"owner": "asmeurer",
"content": "Python docs are confusing here. They say\n\n> Special attributes: __name__ is the class name; __module__ is the module name in which the class was defined; __dict__ is the dictionary containing the class\u2019s namespace; __bases__ is a tuple (possibly empty or a singleton) containing the base classes, in the order of their occurrence in the base class list; __doc__ is the class\u2019s documentation string, or None if undefined.\n\nbut __dict__ and __bases__ are undefined in the class body (pyflakes seems to be correct for all except for __module__). ",
"date_created": "2016-12-08T23:30:36Z"
},
{
"owner": "jreese",
"content": "How easy would this be to fix? Would it help if I submitted a patch? If so, can you point me to the relevant part of the codebase that I should take a look at?",
"date_created": "2016-12-12T19:22:00Z"
},
{
"owner": "icordasc",
"content": "John, that's not apparent to me. Have you tried searching the code-base for __dict__ or __bases__ to see if there is special handling?\n\nGiven that pyflakes works on a compiled AST, I have to wonder if this is a bug in Python's AST that is preventing us from recognizing __module__. I think we have a similar problem with __class__",
"date_created": "2016-12-12T20:09:28Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1648651",
"date_created": "2016-12-08T23:13:59Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Hi,\n\nI keep getting that error in my code.\n\nmy_tool.py:1444:48: E999 SyntaxError: invalid syntax\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0all_osd = {x: tmp_all_osd[x] for x in requested_list}\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0^\n\nCan't figure out what is wrong here.\nPython execute the line just fine and the result is as expected.\n\nUsing Python 2.7\npyflakes 1.3.0\nflake8 3.2.1 (pyflakes: 1.3.0, flake8-comprehensions: 1.2.1, mccabe: 0.5.2, pycodestyle: 2.2.0) CPython 2.6.6 on Linux\n\nAny insight?\n\nThanks a lot,\n\nMax",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "msimard",
"id": 1649693,
"duplicate_of": null,
"title": "Getting E999 SyntaxError on valid dict comprehension",
"comments": [
{
"owner": "icordasc",
"content": "Hi Max, a few things:\n\n1. The correct issue tracker is https://gitlab.com/pycqa/flake8\n\n2. Dictionary comprehensions were added in Python 2.7\n\n3. To use the features of a specific version of Python, Flake8 needs to be installed using that version. In your bug report, it says you've installed on Python 2.6.6 so in fact the dictionary comprehension *is* invalid Syntax.\n\n4. How in the world did you install Flake8 on Python 2.6? That shouldn't work. It uses features of Python 2.7 that aren't present in 2.6.",
"date_created": "2016-12-14T13:26:26Z"
},
{
"owner": "msimard",
"content": "Hi Ian,\n\nThanks for the quick feedback.\nSorry about not using the proper tracker.\n\nThe only thing I did is \"pip install pyflakes/flake8\".\nNothing else.\n\nMy Python version says 2.7.6, not 2.6.6.\n\nI'll try to correct the installation.\n\nThanks,\n\nMax",
"date_created": "2016-12-14T19:35:30Z"
},
{
"owner": "icordasc",
"content": "Max, your original comment here says:\n\n\"flake8 3.2.1 (pyflakes: 1.3.0, flake8-comprehensions: 1.2.1, mccabe: 0.5.2, pycodestyle: 2.2.0) CPython 2.6.6 on Linux\"\n\nSo yes, you did install it on Python 2.6.6. You need to do `python2.7 -m pip install flake8` to get it to install on 2.7 for you (it would appear).",
"date_created": "2016-12-15T15:20:20Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1649693",
"date_created": "2016-12-13T20:59:07Z"
},
{
"status": "New",
"security_related": false,
"description": "Consider the following example, straight from the official docs for `functools.singledispatch` (https://docs.python.org/3.5/library/functools.html#functools.singledispatch):\n\nfrom functools import singledispatch\n@singledispatch\ndef fun(arg, verbose=False):\n if verbose:\n print(\"Let me just say,\", end=\" \")\n print(arg)\n@fun.register(int)\ndef _(arg, verbose=False):\n if verbose:\n print(\"Strength in numbers, eh?\", end=\" \")\n print(arg)\n@fun.register(list)\ndef _(arg, verbose=False):\n if verbose:\n print(\"Enumerate this:\")\n for i, elem in enumerate(arg):\n print(i, elem)\n\npyflakes 1.5.0 spuriously reports:\n\nfoo.py:13: redefinition of unused '_' from line 7\n\n(In practice I would avoid warning on assignments to '_' as much as possible, and possible warn on *uses* of '_' as much as possible -- although it may actually be used by gettext for i18n?)",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "anntzer-lee",
"id": 1658400,
"duplicate_of": null,
"title": "Spurious \"redefinition of unused\" for singledispatch implementations",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1658400",
"date_created": "2017-01-22T05:53:57Z"
},
{
"status": "New",
"security_related": false,
"description": "On Py3,\n\nclass C:\n def ownclass(self):\n return __class__\nprint(C().ownclass())\n\nexecutes correctly (`__class__` is the class in which the method was defined, which is not necessarily the type of `self`, see https://www.python.org/dev/peps/pep-3135/#specification). But pyflakes spuriously complains:\n\n/tmp/foo.py:3: undefined name '__class__'",
"tags": [
"easy"
],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "anntzer-lee",
"id": 1658411,
"duplicate_of": null,
"title": "__class__ cell is defined for methods in py3",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1658411",
"date_created": "2017-01-22T07:55:10Z"
},
{
"status": "New",
"security_related": false,
"description": "For the following snippet\n\nfrom bar import bar\n\ndef foo():\n pass\n\nclass X():\n def foo(self):\n pass\n\n def bar(self):\n pass\n\npyflakes reports the following errors:\n\npp.py:1: 'bar.bar' imported but unused\npp.py:10: redefinition of unused 'bar' from line 1\n\nNote that only imported symbols trigger the problem.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "lelegaifax",
"id": 1659273,
"duplicate_of": null,
"title": "Erroneous report of redefined symbol",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1659273",
"date_created": "2017-01-25T12:08:34Z"
},
{
"status": "Confirmed",
"security_related": false,
"description": "All errors related to undefined symbols used within f-strings are reported with an incorrect line number of \"1\".\n\nThe following snippet\n\nprint('Foo')\nprint(f'{a}')\n\nreports\n\np.py:1: undefined name 'a'\n\nwhereas the error appears on line 2.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "lelegaifax",
"id": 1666811,
"duplicate_of": null,
"title": "Incorrect line number of wrong symbol name inside f-strings",
"comments": [
{
"owner": "oscar-campos",
"content": "This is not a problem in PyFlakes but in the formatted literals implementation in the core of CPython itself. The AST child Name node for the formatting variables reports 1 as both line and column as the nodes are generated by PyParser_ASTFromString \"automagically\" in fstring_find_expr (Python/pythoinrun.c and Python/ast.c respectively).\n\nI don't see how this should/could be fixed by PyFlakes",
"date_created": "2017-03-21T20:39:33Z"
},
{
"owner": "lelegaifax",
"content": "Sadly this is true, the Name elements of an fstring carry an useless lineno, as the following script demonstrates:\n\nfrom ast import FormattedValue, Str, parse\n\ncode = \"\"\"\\\na = 1\nb = f\"a={a} c={c}\"\n\"\"\"\n\nparsed = parse(code)\nfirst, second = parsed.body\nbvalue = second.value\n\nprint(type(bvalue))\n\nfor n in bvalue.values:\n print(type(n))\n if isinstance(n, Str):\n print(\"%d:%d %r\" % (n.lineno, n.col_offset, n.s))\n else:\n assert isinstance(n, FormattedValue)\n print(\"%d:%d\" % (n.lineno, n.col_offset))\n v = n.value\n print(type(v))\n print(\" %d:%d %r\" % (v.lineno, v.col_offset, v.id))\n\nthat emits:\n\n<class '_ast.JoinedStr'>\n<class '_ast.Str'>\n2:4 'a='\n<class '_ast.FormattedValue'>\n2:4\n<class '_ast.Name'>\n 1:1 'a'\n<class '_ast.Str'>\n2:4 ' c='\n<class '_ast.FormattedValue'>\n2:4\n<class '_ast.Name'>\n 1:1 'c'\n\nHowever, couldn't PyFlakes recognize those Name elements and go up to the enclosing FormattedValue and use its position as the error location?\n",
"date_created": "2017-03-22T00:08:42Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1666811",
"date_created": "2017-02-22T08:25:16Z"
},
{
"status": "New",
"security_related": false,
"description": "$ cat pyflakes-test.py \ntry:\n raise Exception(\"test\")\nexcept Exception as e:\n print(e)\n x = lambda: e\n print(x)\n print(x())\n\n$ pyflakes --version\n1.5.0\n\n$ pyflakes pyflakes-test.py\npyflakes-test.py:5: undefined name 'e'\n\nrunning this with older pyflakes seems to work OK:\n\n$ pyflakes --version\n0.8.1\n\n$ pyflakes pyflakes-test.py && echo $?\n0",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "toikarin",
"id": 1669713,
"duplicate_of": null,
"title": "erroneous 'undefined name' in exception handling + lambda",
"comments": [],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1669713",
"date_created": "2017-03-03T08:49:43Z"
},
{
"status": "New",
"security_related": false,
"description": "An import used by a type annotation inside __new__() in a metaclass is considered unused by flake8/pyflakes/whatever component.\n\ne.g. given:\n\n from django.db.models import Model\n\n\n class SomeMetaclass(type):\n def __new__(mcs, name, bases, attrs):\n model_class_attrs: [(str, Model,)] = []\n model_class_attrs.clear()\n return super().__new__(mcs, name, bases, attrs)\n\n\nRunning flake8 results in the error:\n\n example.py:1:1: F401 'django.db.models.Model' imported but unused\n\n\nVersions:\n\nPython 3.6\nflake8 3.3.0\nmccabe 0.6.1\npycodestyle 2.3.1\npyflakes 1.5.0",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "thauk-copperleaf",
"id": 1670468,
"duplicate_of": null,
"title": "Import used by type annotation inside __new__ is considered unused",
"comments": [
{
"owner": "asmeurer",
"content": "I believe this was fixed here https://github.com/PyCQA/pyflakes/pull/88",
"date_created": "2017-03-08T20:24:15Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1670468",
"date_created": "2017-03-06T19:09:25Z"
},
{
"status": "New",
"security_related": false,
"description": "*Please describe how you installed Flake8*\n\nExample:\n\n```\npython3 -m venv ~/.virtualenvs/flake8\nworkon flake8\npip install -U pip setuptools wheel\npip install flake8 flake8-commas\n```\n\n*Please provide the exact, unmodified output of `flake8 --bug-report`*\n\nnah\n\n*Please describe the problem or feature*\nflake8 thinks that mangled globals or freevars are undefined in:\n\n```python\ndef _Ham__spam(value):\n value + ' yes mangling really works like this'\n\nclass Ham:\n def foo(self, value):\n return __spam(value)\n```\n\n*If this is a bug report, please explain with examples (and example code) what you expected to happen and what actually happened.*\n\nI expected __spam to be considered defined, because it is.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "tagrain",
"id": 1675153,
"duplicate_of": null,
"title": "finds mangled globals and freevars undefined/unused",
"comments": [
{
"owner": "asmeurer",
"content": "This is relevant for someone implementing this https://stackoverflow.com/questions/11024344/python-name-mangling-function",
"date_created": "2017-03-22T20:48:27Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1675153",
"date_created": "2017-03-22T20:00:27Z"
},
{
"status": "Confirmed",
"security_related": false,
"description": "Consider the following script:\n\nimport bar\n\nclass Foo:\n def bar(self):\n pass\n\nPyflakes emits:\n\n$ pyflakes foo.py \nfoo.py:1: 'bar' imported but unused\nfoo.py:4: redefinition of unused 'bar' from line 1\n\nBoth disappears if `bar` is actually used, so the following is clean:\n\nimport bar\n\nclass Foo:\n def bar(self):\n pass\n\ncoffee = bar.Espresso()",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "lelegaifax",
"id": 1675659,
"duplicate_of": null,
"title": "Imports and methods fall in the same namespace?",
"comments": [
{
"owner": "asmeurer",
"content": "The error seems correct to me. If you had\n\nimport bar\n\nclass Foo:\n a = bar\n\nthen Foo().a would be bar (the module). If you had\n\nclass Foo:\n def bar(self):\n pass\n\n a = bar\n\nthen Foo().a would be bar (the method). So the method does override the imported name in the class namespace, which pyflakes warns about (but only if the name is unused, to avoid false positives).",
"date_created": "2017-03-24T20:25:10Z"
},
{
"owner": "lelegaifax",
"content": "Well, I don't agree with your argument, but if that's instead valid, then I would\nexpect that a very similar case, that is\n\ndef a():\n pass\n\nclass A:\n def a(self):\n pass\n\nshould emit the same error instead of the current happy mood, and even\n\na = 1\n\ndef b():\n a = 2\n\nshould \"warn\" me about the override of a global symbol within the function namespace,\ninstead of the current and IMHO correct warning about unused assignment.\n\nIn any case, the fact that the error \"disappear\" as soon as I use the imported symbol\nseems wrong: the class method is still overriding the global symbol.",
"date_created": "2017-03-24T21:49:25Z"
},
{
"owner": "asmeurer",
"content": "I think pyflakes automatically assumes functions and module level variables are \"used\" because they could just be defined to be importable from other modules. ",
"date_created": "2017-03-24T23:31:19Z"
},
{
"owner": "bitglue",
"content": "Report seems legit to me. In the example:\n\nimport bar\n\nclass Foo:\n def bar(self):\n pass\n\nthe bar import is unused, and there should remain an error about that. But defining a bar function inside the class scope does not seem like an error. Pyflakes does not emit errors for shadowing global variables, imports or otherwise, unless it's done such that something which was imported can not possibly be used. Like this:\n\n$ pyflakes\nimport foo\nfoo = 1\n<stdin>:2: redefinition of unused 'foo' from line 1\n\nI'm vaguely remembering there was some implementation reason for this bug, and maybe it was too difficult to fix. But that was years ago...worth at least investigating.",
"date_created": "2017-03-29T02:15:10Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1675659",
"date_created": "2017-03-24T07:40:58Z"
},
{
"status": "Invalid",
"security_related": false,
"description": "Under both Python 2 and 3, I expect the F812 warning to be reported.\n\nI originally found this via TravisCI testing, see https://travis-ci.org/peterjc/biopython/builds/225261622 for example, before preparing this minimal test case. Originally logged against flake8 as https://gitlab.com/pycqa/flake8/issues/326\n\nI am using pyflakes 1.5.0 installed with pip under macOS using either Apple provided Python 2.7, or a self-compiled Python 3.4.\n\nTest script and its output:\n\n```\n$ cat test_F812.py\nx = 3\n\ny = [chr(x + 32) for x in range(3)]\n\nprint(\"The value of x should be 2 or 3 (matching your version of Python):\")\nprint(x)\n$ python test_F812.py\nThe value of x should be 2 or 3 (matching your version of Python):\n2\n$ python3 test_F812.py\nThe value of x should be 2 or 3 (matching your version of Python):\n3\n```\n\nExpected output as seen on Python 2.7,\n\n```\n$ /usr/local/bin/pyflakes --version\n1.5.0\n$ /usr/local/bin/pyflakes test_F812.py ; echo \"Return code $?\"\ntest_F812.py:3: list comprehension redefines 'x' from line 1\nReturn code 1\n```\n\nor to show explicitly this is under Python 2,\n\n```\n$ python --version\nPython 2.7.10\n$ python -m pyflakes --version\n1.5.0\n$ python -m pyflakes test_F812.py ; echo \"Return code $?\"\ntest_F812.py:3: list comprehension redefines 'x' from line 1\nReturn code 1\n```\n\nProblem output as seen on Python 3.4,\n\n```\n$ pyflakes --version\n1.5.0\n$ pyflakes test_F812.py ; echo \"Return code $?\"\nReturn code 0\n```\n\nor to show explicitly this is under Python 3,\n\n```\n$ python3 --version\nPython 3.4.1\n$ python3 -m pyflakes --version\n1.5.0\n$ python3 -m pyflakes test_F812.py ; echo \"Return code $?\"\nReturn code 0\n```",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "maubp",
"id": 1685910,
"duplicate_of": null,
"title": "F812 fails under Python 3",
"comments": [
{
"owner": "icordasc",
"content": "This is the intended behaviour for PyFlakes. It has different errors that it reports based on which version of Python it's run under.",
"date_created": "2017-04-24T21:47:19Z"
},
{
"owner": "maubp",
"content": "OK, thanks for the quick clear cut reply. This surprised me - could the general principle be mentioned on the README?\n\nhttps://github.com/PyCQA/pyflakes/blob/master/README.rst\n\nIf there is a table of all the pyflakes error codes in your documentation I could not find it, but it would be great to say there which are Python 2 or 3 specific.",
"date_created": "2017-04-24T21:53:46Z"
},
{
"owner": "asmeurer",
"content": "The codes themselves aren't specific. Pyflakes parses the code using the AST, syntax rules, and built in names for the version of Python it is running in. For instance, using \"xrange\" will give an undefined name warning in Python 3 but not in Python 2. ",
"date_created": "2017-04-24T22:14:07Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1685910",
"date_created": "2017-04-24T20:08:47Z"
},
{
"status": "Won't Fix",
"security_related": false,
"description": "For the following code\n\ndef test():\n a = False\n for i in range(10):\n if a:\n print(b)\n else:\n a = True\n b = 1\n\n\npyflakes gives the following errors\n\ntest.py:5: undefined name 'b'\ntest.py:8: local variable 'b' is assigned to but never used\n\nBut test() runs just fine without any errors.",
"tags": [],
"duplicates": [],
"assignee": null,
"milestone": null,
"owner": "asmeurer",
"id": 1686327,
"duplicate_of": null,
"title": "Undefined variable defined later in a loop",
"comments": [
{
"owner": "bitglue",
"content": "Here we know a is False because it was assigned with a literal. But what if it's the result of a function call, or even a more complex expression?\n\nHave you encountered this in the wild?",
"date_created": "2017-04-29T23:02:14Z"
},
{
"owner": "asmeurer",
"content": "I hit it in my own code. But, honestly, it's a very unstable coding pattern. I ended up adding a minor thing to it which required defining the variable before the loop. So if fixing this is too hard or adds too many false negatives I wouldn't be too worried about it. ",
"date_created": "2017-04-30T00:29:30Z"
},
{
"owner": "bitglue",
"content": "Yeah, I think it would be pretty tricky. Right now pyflakes skips over conditional branches as if they aren't even there, so all it sees is:\n\n a = False\n print(b)\n a = True\n b = 1\n\nTechnically it could be fixed when `a` is assigned a literal, but between the effort required to implement the fix and the added complexity to the code I don't think it's worthwhile.",
"date_created": "2017-05-11T16:04:03Z"
}
],
"importance": "Undecided",
"lp_url": "https://bugs.launchpad.net/bugs/1686327",
"date_created": "2017-04-26T07:39:25Z"
}
]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment