Hey, thanks for the great feedback on our output improvements. I'd just like to confirm what we'll be working on before I ticket the new behaviour
New ticket: Truncate repeated warnings two options: Enabled by default, use --unabridged to show all warnings message: [ More warnings in this category, use --unabridged to show them all ] or Disabled by default, use --truncate to truncate repeated warnings message: [ More warnings in this category, don't use --truncate flag if you would like to see them all ] Which option would be better, and what's a better, simpler name for the option than unabridged/truncate? And before I sign off, I'd like to throw my support behind the idea of disabling convention warnings by default. Can we ticket this and address it as part of our output fixes? I think it would go a long way towards making pylint more friendly for first time users. Thanks! -Sarah On Wed, Mar 17, 2010 at 7:00 AM, <[email protected]>wrote: > Send Python-Projects mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.logilab.org/mailman/listinfo/python-projects > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-Projects digest..." > > > Today's Topics: > > 1. Re: Proposed output improvements (Mads Kiilerich) > 2. Re: pylint #4581 proposed fix (Maarten ter Huurne) > 3. Re: pylint #4581 proposed fix (Sylvain Th?nault) > 4. Re: Proposed output improvements (Maarten ter Huurne) > 5. Re: pylint #18860: warn on assert( a, b ?) patch (Emile Anclin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Mar 2010 02:15:29 +0100 > From: Mads Kiilerich <[email protected]> > Subject: Re: [Python-projects] Proposed output improvements > To: Sylvain Th?nault <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > Sylvain Th?nault wrote, On 03/15/2010 11:56 AM: > > On 14 mars 00:40, Mads Kiilerich wrote: > > > >> Pylint has a lot of options to controlling the behaviour and output. > >> But it is my experience that there are so many that they are very > >> hard to find and use correctly. > >> > > do you have some ideas about how to improve this? Do you see some > > options which are in your opinion useless? > > > > It is very hard to give constructive feedback to something as subjective > as usability - especially on the command line - but I will try ... > > Pylint has functionality and options I don't think are essential, and in > my opinion it would be better not have (or show) these - neither in > code, help, documentation, nor conceptual complexity. But I did not and > will not call any of the options useless. > > > It seems like pylint have different goals with different focus and > emphasis. > > The man page says: > pylint - python code static checker > > I think this is what I want. I would like pylint to be more like a > "unix" command line tool, simple, "stupid", 100% reproducable and > predictable and doing one thing well. By that criteria gcc and lint are > nice tools, and I want something similar for python, both in content and > output format. I don't care much about pylint's metrics for my coding > style, but I want static semantic analysis with type inference in order > to catch bugs as early as possible. That behavior and output is also > usable for simple integration with editors. The end goal in this mode > should be to get down to zero reported issues - either by fixing code or > adding workarounds or disable checks. It should be simple to enable and > disable checks, and configuration should be command line options in > shellscripts or makefiles - not in configuration files. > > pylint --help says: > Check that a module satisfy a coding standard (and more !). > > This seems to have a different focus where pylint plays another role, as > a friendly wizard working more interactively together with the user to > move the code towards a goal (aka "better"). The output is a verbose > "report" describing several aspects of the code. Much of the > functionality and configurability I don't like probably makes sense here. > > > Much of the "friendly" functionality and options is disturbing noise to > me, and optimizing for conflicting goals is obviously frustrating and > should be avoided. Perhaps it would be better to make different tools > for the different purposes? > > And do people really want a command-line tool with text output in the > second "friendly" case? Who likes to read a 100-line report with ascii > art on the command line? Wouldn't a GUI tool or web interface for > drilling down in the analysis and browsing the code be more suitable? > > > So in _my_ opinion all the options and functionality for reports could > be removed, while the command line options for checks should polished to > match what command line users intuitively expects. > > Some quick examples/ideas: > > "-w" to enable more and more checks/warnings, reporting only errors by > default > > "--enable" and "--disable" to enable and disable "anything" as > pylint --disable C,R,W0311 --enable C0111 foo.py > - to disable conventions and refactorings (what they should have been by > default! ;-) ) and a warning, and then enable docstring checks anyway. > or > pylint --dis C,R,W0311 --en C0111 foo.py > pylint -C -R -W0311 +C0111 foo.py > > "-h W0311" to show help/description of this message > > "-h W" to list warnings that can be enabled > > "-v" to show more verbose messages, assuming exact and terse output by > default > > I am aware that I am mixing checkers and messages and categories, but I > think/hope the concepts can be simplified. > > /Mads > > > > ------------------------------ > > Message: 2 > Date: Wed, 17 Mar 2010 09:28:45 +0100 > From: Maarten ter Huurne <[email protected]> > Subject: Re: [Python-projects] pylint #4581 proposed fix > To: [email protected] > Message-ID: <[email protected]> > Content-Type: Text/Plain; charset="iso-8859-15" > > On Tuesday 16 March 2010, Donovan Lee Wanhoy wrote: > > > Attached is .diff file on a proposed fix for pylint #4581: option to NOT > > get a Missing docstring (C0111) warning if a method is overridden. > > This sounds like a useful feature. > > > All I did was: > > - add an option, no-docstring-overridden that when invoked > > --no-docstring-overridden=y, it won't check the docstring for a method > > that is overridden. > > Is there a reason to make it optional, rather than have it enabled at all > times? > > Bye, > Maarten > > > ------------------------------ > > Message: 3 > Date: Wed, 17 Mar 2010 09:44:03 +0100 > From: Sylvain Th?nault <[email protected]> > Subject: Re: [Python-projects] pylint #4581 proposed fix > To: Maarten ter Huurne <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > On 17 mars 09:28, Maarten ter Huurne wrote: > > > All I did was: > > > - add an option, no-docstring-overridden that when invoked > > > --no-docstring-overridden=y, it won't check the docstring for a method > > > that is overridden. > > > > Is there a reason to make it optional, rather than have it enabled at all > > times? > > I agree I don't see that much cases where we could want to disable this > behaviour. > -- > Sylvain Th?nault LOGILAB, Paris (France) > Formations Python, Debian, M?th. Agiles: http://www.logilab.fr/formations > D?veloppement <http://www.logilab.fr/formations%0AD?veloppement> logiciel > sur mesure: http://www.logilab.fr/services > CubicWeb, the semantic web framework: http://www.cubicweb.org > > > > ------------------------------ > > Message: 4 > Date: Wed, 17 Mar 2010 10:58:54 +0100 > From: Maarten ter Huurne <[email protected]> > Subject: Re: [Python-projects] Proposed output improvements > To: [email protected] > Message-ID: <[email protected]> > Content-Type: Text/Plain; charset="utf-8" > > On Wednesday 17 March 2010, Mads Kiilerich wrote: > > > It seems like pylint have different goals with different focus and > > emphasis. > > > > The man page says: > > pylint - python code static checker > > > > I think this is what I want. I would like pylint to be more like a > > "unix" command line tool, simple, "stupid", 100% reproducable and > > predictable and doing one thing well. By that criteria gcc and lint are > > nice tools, and I want something similar for python, both in content and > > output format. I don't care much about pylint's metrics for my coding > > style, but I want static semantic analysis with type inference in order > > to catch bugs as early as possible. That behavior and output is also > > usable for simple integration with editors. > > In mode detail, I use pylint in this way to: > - check whether there are any obvious errors before starting manual or > automated tests, to save time > - check whether I am done refactoring, especially in the case of moving > functions or classes to a new or different module > - as a pre-commit sanity check > > In this use, typically pylint is run on one or a small set of sources: > those > sources that the user is currently making changes to. > > > The end goal in this mode > > should be to get down to zero reported issues - either by fixing code or > > adding workarounds or disable checks. It should be simple to enable and > > disable checks, and configuration should be command line options in > > shellscripts or makefiles - not in configuration files. > > I agree about zero issues being the goal, since that way any issues > reported > mean there is work to be done; you don't lose time checking which issues > can > be ignored and which cannot. > > I disagree about the configuration: to me it is more convenient to have > pylint pick up the pylintrc that is in the same directory as the sources > instead of writing a shell script to provide those same options. As an > additional bonus, the pylintrc works on Windows too, while shellscripts and > makefiles do not (unless you require mingw or cygwin). > > > pylint --help says: > > Check that a module satisfy a coding standard (and more !). > > > > This seems to have a different focus where pylint plays another role, as > > a friendly wizard working more interactively together with the user to > > move the code towards a goal (aka "better"). The output is a verbose > > "report" describing several aspects of the code. Much of the > > functionality and configurability I don't like probably makes sense here. > > I have used pylint to measure code quantity and quality, using a nightly > cron-like job. It produced an HTML report that included line counts, > duplicate code and the remaining violations on all source files. It was not > in any way interactive though; could you explain that part? > > > Much of the "friendly" functionality and options is disturbing noise to > > me, and optimizing for conflicting goals is obviously frustrating and > > should be avoided. Perhaps it would be better to make different tools > > for the different purposes? > > I wouldn't want to have to configure two different tools. However, it would > make sense to have a "quick check" mode and a separate "full report" mode. > In the quick check mode, certain checks and reports would be disabled. > > > And do people really want a command-line tool with text output in the > > second "friendly" case? Who likes to read a 100-line report with ascii > > art on the command line? Wouldn't a GUI tool or web interface for > > drilling down in the analysis and browsing the code be more suitable? > > Personally, I like HTML output in this mode. > > > "-w" to enable more and more checks/warnings, reporting only errors by > > default > > There are a lot of warnings that I would like to see in the quick check > scenario: > - abstract methods that are not overridden: these are likely to crash the > program, so it's more efficient to fix them before testing > - unused arguments: might point to incomplete implementation > - variables shadowing something from a higher level: might be a bug > - unused imports, so I can clean them up before committing > > So limiting it to only errors would not be my preference. > > > "--enable" and "--disable" to enable and disable "anything" as > > pylint --disable C,R,W0311 --enable C0111 foo.py > > This sounds convenient. However, it does require that each identifier > belongs only to one category, otherwise it becomes ambiguous. > > > - to disable conventions and refactorings (what they should have been by > > default! ;-) ) and a warning, and then enable docstring checks anyway. > > I agree that the refactor warnings should be disabled on the quick check. > The duplicate code search cannot really do its job anyway if a subset of > sources is checked. > > I would want conventions enabled, since I also want zero violations there. > However, it makes sense to disable convention checking by default and allow > it to be enabled by pylintrc, since it's likely that the configuration > (regexps) will have to be tweaked to the conventions of a particular > project > anyway. > > > or > > pylint --dis C,R,W0311 --en C0111 foo.py > > I don't think you'd be typing this line again and again; as you said it > would be in a shell script or makefile (or maybe an alias). Therefore the > characters saved by using "--dis" instead of "--disable" are not worth it, > in my opinion. > > > pylint -C -R -W0311 +C0111 foo.py > > This causes confusion whether "-C" is something that is disabled or an > option named "C". > > > "-h W0311" to show help/description of this message > > So the same as the current "--help-msg", but with a shorter name? That > would > be useful, since it is likely that this will be typed directly on the > command line. > > > "-h W" to list warnings that can be enabled > > Do you mean the full list of messages that pylint knows, or only the ones > that are disabled? > > > In any case, I think you're right that there are two different ways of > using > pylint, each with different goals. And that many features that are useful > in > the "full report" use are complicating things in the "quick check" command > line use. > > Bye, > Maarten > > > ------------------------------ > > Message: 5 > Date: Wed, 17 Mar 2010 11:58:30 +0100 > From: Emile Anclin <[email protected]> > Subject: Re: [Python-projects] pylint #18860: warn on assert( a, b ?) > patch > To: [email protected] > Message-ID: <201003171158.30135.emile.anc...@logilab> > Content-Type: text/plain; charset="utf-8" > > On Monday 15 March 2010 12:50:13 Colin Morris wrote: > > If it were possible to check a little more carefully what's being > > asserted, then we could give a very specific message. As I understand > > it, we're warning against the case where someone is trying to assert > > some boolean expression along with a message to pass to the > > AssertionError's constructor ("assert x, msg"), but instead muddles the > > syntax and asserts a tuple ("assert (x, msg)"). If we could check that > > what's being asserted is a size 2 tuple literal, then we could give a > > more specific message like: "Assertion will always be true. Did you > > mean 'assert x, msg'?". > > here we just have to test len(node.elts) == 2 > > > Also, that could avoid some false positives > > since, I imagine, there are legitimate situations where you might want > > to assert some variable that holds a tuple of undetermined size (though > > 'assert len(sometuple) is not 0' might be more clear). I don't know if > > this is possible though--can the ASTNG tell whether a tuple is a > > literal or not? > > I think, here is (at least) a misunderstanding : we will trigger our > message on a *astng* Tuple node, as in Fletcher Johnson's patch : > > + if isinstance(node.test, astng.Tuple): > > and we always know all elements of a Tuple node; > > not on a Name node that could possibly be inferred as be a *python* tuple. > But: > > >>> from logilab.astng import builder, nodes > >>> bb = builder.ASTNGBuilder() > >>> tree = bb.string_build(""" > ... a = tuple(b for b in iterbl) > ... """) > >>> list(tree['a'].infer()) > [<Instance of __builtin__.tuple at 0x24025104>] > >>> inst = list(tree['a'].infer())[0] > >>> isinstance(inst, nodes.Tuple) > False > > > > Without those checks, we can't really be sure that the assertion will > > always be true, so the warning message would have to be a bit more > > noncommittal. Maybe something like: > > > > "Found assertion of tuple. Did you mean to do 'assert a, msg'?" > > or > > "Assertion of a non-empty tuple will always pass. Did you mean 'assert > > a, msg'?" > > So, there should be two different messages depending on > len(node.test.elts) == 2 or not > > -- > > Emile Anclin <[email protected]> > http://www.logilab.fr/ http://www.logilab.org/ > Informatique scientifique & et gestion de connaissances > > > ------------------------------ > > _______________________________________________ > Python-Projects mailing list > [email protected] > http://lists.logilab.org/mailman/listinfo/python-projects > > End of Python-Projects Digest, Vol 68, Issue 13 > *********************************************** >
_______________________________________________ Python-Projects mailing list [email protected] http://lists.logilab.org/mailman/listinfo/python-projects
