{"action":"created","issue":{"url":"https://api.github.com/repos/PyCQA/pylint/issues/746","labels_url":"https://api.github.com/repos/PyCQA/pylint/issues/746/labels{/name}","comments_url":"https://api.github.com/repos/PyCQA/pylint/issues/746/comments","events_url":"https://api.github.com/repos/PyCQA/pylint/issues/746/events","html_url":"https://github.com/PyCQA/pylint/issues/746","id":122747071,"number":746,"title":"Getting sane in 2.0","user":{"login":"PCManticore","id":448166,"avatar_url":"https://avatars.githubusercontent.com/u/448166?v=3","gravatar_id":"","url":"https://api.github.com/users/PCManticore","html_url":"https://github.com/PCManticore","followers_url":"https://api.github.com/users/PCManticore/followers","following_url":"https://api.github.com/users/PCManticore/following{/other_user}","gists_url":"https://api.github.com/users/PCManticore/gists{/gist_id}","starred_url":"https://api.github.com/users/PCManticore/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/PCManticore/subscriptions","organizations_url":"https://api.github.com/users/PCManticore/orgs","repos_url":"https://api.github.com/users/PCManticore/repos","events_url":"https://api.github.com/users/PCManticore/events{/privacy}","received_events_url":"https://api.github.com/users/PCManticore/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/PyCQA/pylint/labels/discussion","name":"discussion","color":"c7def8"},{"url":"https://api.github.com/repos/PyCQA/pylint/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":12,"created_at":"2015-12-17T14:40:43Z","updated_at":"2015-12-18T08:43:58Z","closed_at":null,"body":"I want to start a discussion regarding what we want to have in pylint 2.0, from the point of view of the usability of the tool, rather than the static analysis capabilities. There are a lot of folks out there who could use pylint, but they don't use it currently because of various reasons, most of them having\r\nreal arguments that I'd like to address with this issue.\r\n\r\nWhen talking about this 2.0, I'm not referring to the previous 2.0 that arised in discussions we had over IRC, with advanced static analysis capabilities, such as control flow graphs, points-to analysis and abstract interpretation. We'll have to call the latter one 3.0 though, since it's going to be another major API breaker. 2.0, in my opinion, should have a main focus of reducing the annoyances that users have with the tool from a UX perspective.\r\n\r\nWithout further ado, here are the issues I'd like to address with 2.0:\r\n\r\n1. Sane defaults\r\n\r\nPylint's output is too verbose by default. While I agree that most of the messages should\r\nbe left as is, we could try to activate the -E flag by default. It should offer the most useful set of errors that users shouldn't have in their project, leaving style checking and other non-critical checks to be activated explicitly by those interested in them.\r\n\r\nThe reports are not so useful, we could activate \"--reports=n\" by default. They tend to be useful in some situations, but impedes the normal workflow when working with pylint. The only capability that I'd like to have activated by default is the score, though, since it tends to make the code quality a gamification for beginners.\r\n\r\nRemove or downgrade to extensions some checkers, such as too-few-public-methods, too-many-public-methods etc. I'll have to compile a full list for these, but I'm interested in what messages don't seem so useful for  the community.\r\n\r\nReevaluate constants for checker's options, such as the maximum number of statements, maximum number of arguments etc. For me, some of them are set too low and I always change them.\r\n\r\n   \r\n2. Prefer false negatives over false positives\r\n\r\nCurrently we're doing the opposite thing, we emit a message even if there is a high risk of a false positive to occur. Things changed quite a bit in the last year though regarding this aspect.\r\nFor instance, we don't emit no-member if we don't detect all the base classes of the class which owns the attribute we're trying to access. \r\n\r\nBut we're not there yet, we still have tons of false positives, but this is a topic that's not going to go away so soon, requiring a higher level understanding of Python than we currently have\r\nand more static analysis concepts brought into our need (call graphs, abstract interpretation, flow control understanding, points-to and so much more). What we can do is to try not to emit a message if we're not 100% confident that it's actually a problem. The first example that comes into my\r\nmind is no-member, which we could try not to emit if we can infer multiple values for the same object. \r\nThe idea is to keep away false positives, but letting false negatives taking their position. It's much worse to deal with 100 false positives in a project that with 10-15 false negatives (which will eventually be detected correctly, as soon as we'll implement what's missing for them).\r\n\r\n\r\nSo, what do you folks think about this? What else we should target for 2.0 and what would be of interest to you for using pylint more often? The plan is to have this 2.0 out in march-april,\r\nwith the main focus for an advanced 3.0 later on this year.\r\n\r\ncc @The-Compiler @dmand @ceridwen I'd like your opinion as well on this one."},"comment":{"url":"https://api.github.com/repos/PyCQA/pylint/issues/comments/165715501","html_url":"https://github.com/PyCQA/pylint/issues/746#issuecomment-165715501","issue_url":"https://api.github.com/repos/PyCQA/pylint/issues/746","id":165715501,"user":{"login":"The-Compiler","id":625793,"avatar_url":"https://avatars.githubusercontent.com/u/625793?v=3","gravatar_id":"","url":"https://api.github.com/users/The-Compiler","html_url":"https://github.com/The-Compiler","followers_url":"https://api.github.com/users/The-Compiler/followers","following_url":"https://api.github.com/users/The-Compiler/following{/other_user}","gists_url":"https://api.github.com/users/The-Compiler/gists{/gist_id}","starred_url":"https://api.github.com/users/The-Compiler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/The-Compiler/subscriptions","organizations_url":"https://api.github.com/users/The-Compiler/orgs","repos_url":"https://api.github.com/users/The-Compiler/repos","events_url":"https://api.github.com/users/The-Compiler/events{/privacy}","received_events_url":"https://api.github.com/users/The-Compiler/received_events","type":"User","site_admin":false},"created_at":"2015-12-18T08:43:58Z","updated_at":"2015-12-18T08:43:58Z","body":"> Also, I'm not really in favor of having a lot of things disabled by default, because I feel like most people won't ever take a look at them.\r\n\r\nI fear the same, but I think this can be solved with a good \"getting started\" documentation.\r\n\r\n> If we go that way I would rather like to see a registry of pylint plugins, not shiped with the core. But that's development, documentation and communication work.\r\n\r\nSome useful plugin system would indeed be a nice thing. Ideally something based on setuptools entry points, so you could simply install `pylint-style`, `pylint-pedantic`, etc. etc. via pip :wink:\r\n\r\n> Message that could be removed\r\n\r\nAs mentioned I'd prefer to see stuff disabled by default (or moved to plugins) than removed completely. Some of those surely are useful for some poeple.\r\n\r\n> A side note to finish: we (logilab) have recently added new messages, some of which seem indeed problematic yet as Florian noticed (`wrong-import-order`, `ungrouped-imports`, `redefined-variable-type`). I personnaly think that those will become nice to have messages once most problematic issues with them will be sorted out, and so they are worth the effort.\r\n\r\nI agree with that - I can see their value if they work properly.\r\n"}}