Thanks for your interest in pylint. pylint is a free software published
under the terms of the GNU General Public License version 2. I believe
you can find the answers to all your questions inside this license.
If you have any further questions about pylint, you can write to the
mailing list: code-quality(a)python.org
Le 30/01/2014 01:11, vreddy(a)baseinfosec.com a écrit :
> My name is Varada. I am planning to use Pylint in our framework which
> will be made available commercially. We are in development stage. Please
> let us know what are the things that I need to consider in order to use
> Pylint in our framework.
Olivier CAYROL LOGILAB - Paris / Toulouse (France)
Logiciels libres innovants pour le Web et les Sciences |Python CubicWeb
Innovative free software for Web and Sciences |SaltStack Debian
I wanted to canvas your opinion about something.
Currently, if you have a print statement with brackets in Python2, pylint will raise a comment C0325. This is suppressed if "from __future__ import print_statement" is used.
My question is whether or not using print statements with parentheses in python2 should result in a warning. This was brought up as a bug for prospector (see here: https://github.com/landscapeio/prospector/issues/11) and I'm not sure what to decide. On the one hand, without the explicit print function import, the parentheses are superfluous. On the other hand, it is a valid way of making code 2 and 3 compatible.
My own thoughts are that the correct way of ensuring Python 2 and 3 compatibility is to use the 'from __future__' import, however that's not compatible with 2.5 and lower.
Any thoughts or comments here?
I am trying to use pylint for my unit testing. And so I downloaded
the latest patch of pylint from the link "
http://download.logilab.org/pub/pylint/". So when I started running pylint
on my python file, it throws me an error. I have attached the screenshot of
that error page.
Moreover, should I install the dependencies(astroid and logilab)
Or will it be auto-installed when am installing Pylint?
So please help me out of this. If I have to install the dependencies
too, please send me the links for downloading the dependencies.
Thanks in advance
I just wanted to let you know, after Pyflakes seemed dead for about 5
months I created a fork called Frosted:
While it seems that Pyflakes is somewhat alive again, In the fork a lot of
code has been simplified and a lot of necessary but missing features (such
as configuration) have been added. Additionally, I've merged in a lot of
improvements from the Pyflakes community at large. I will be working hard
to improve Frosted further, and any suggestions / feature improvements that
are recommended will be met with enthusiasm :).
While, I would be willing to merge the two projects at some later point, I
think in the short-term the rapid development and freedom working under a
new project name will bring - will be very beneficial. I have added Florent
Xicluna and Steven Myint as collaborators on the project, as these are both
developers I have high regard for, and remove the possibility of me being
the single source of failure for unmerged pull-requests.
So if you have time, please check out the project, request features, and
make pull requests. Lets make a great Python code checker even better!
No. I get the E1101 error. So it seems it is a problem with my system.
locate pylint shows that the only installed package is
I installed it with pip.
or., 2014.eko urtren 17a 10:45(e)an, Sylvain Thénault(e)k idatzi zuen:
> On 17 janvier 10:18, Zunbeltz Izaola wrote:
>> Dear Sylvain,
>> It is strange that the error is for all the methods of the gtk3 objects.
>> I import the Gtk namespace in the following way
>> from gi.repository import Gtk
>> from gi.repository import Gio
>> Construction the basic objects, like Box(), is fine; but calling its
>> methods raises the error mensage.
>> This is why I think that brain was not enabled by default.
>> The tests at pylint-brain/test run fine.
>> The pylint --version output is
>> pylint 1.1.0,
>> astroid 1.0.1, common 0.60.1
>> Python 2.7.5+ (default, Sep 19 2013, 13:49:51)
>> [GCC 4.8.1]
> [syt@orion ~]$ cat girepo.py
> from gi.repository import Gtk
> b = Gtk.Box()
> [syt@orion ~]$ pylint -rn girepo.py
> ************* Module girepo
> C: 1, 0: Missing module docstring (missing-docstring)
> C: 2, 0: Invalid constant name "b" (invalid-name)
> Does this work for you?
On Sun, Jan 19, 2014 at 11:12 AM, Kay Hayen <kay.hayen(a)gmail.com> wrote:
> this was interesting to me:
>> Error numbers in tools such as pep8 and pyflakes (although flake8 adds
>> them to pyflakes) are usually not made to be entirely successive. For
>> the most part, there are groupings of errors. The best explanation of
>> this is pep8's documentation:
>> Anything starting with E1 is related to indentation, anything starting
>> with E2 is related to whitespace. These are conceptually classes of
>> errors. PyLint also follows this convention if I remember correctly
>> and you would do well to do the same. The error codes that Flake8 adds
>> to PyFlakes follow that convention as well.
> So for my compiler Nuitka, there are very few warnings so far, mostly
> it is very limited in its tracing abilities, but I am expanding this now,
> and so far
> I was kind of clueless on how to properly format error and warning messages.
> It probably will a while, before I find the need to expand it, but it would
> be good
> to have a common ground, reusable data. For PyLint, these texts seem spread
> out in the variables files.
You would do best to research (and possibly revive) past conversations
on this list about a standardization of error messages. I believe the
standard that Flake8 uses is also pep8's format (which is similar to
PyLint). pep257 also has a rewrite branch to use that format. Trying
to create a standard about something so subjective is difficult and it
becomes more difficult when tools like pep8 support providing your own
> Is there an easy way to access the PyLint warning/error message texts.
I would hope so, but I do not personally know.
> Would you be OK with me to grep these out of PyLint or Wiki, and use them under
> in my project as well. I would of course prefer, for these to exist a place
> that makes
> reuse easier.
I cannot grant you permission to do this because I am not associated
with the project. For others reading the list, the ASF2 refers to
https://www.apache.org/licenses/LICENSE-2.0, also known as the Apache
License 2.0. I'm also a bit fuzzy on the compatibility of the LGPL2.1
with Apache 2.0. I'm also not entirely certain how PyLint's error
codes would benefit your project.
> Basically, I am saying, why isn't this some kind of standard. And can we
> make it
Standardizing anything is difficult. People rarely agree on anything.
One way to achieve your standard, however, may be to write a package
(ideally permissively licensed like Nuitka) that provides formatters
for the more popular options, i.e., pep8 and pyflakes. Then simply
encourage those writing similar tools to use that to reduce code
duplication and possible errors. If your module achieves enough
popularity, it would then become a de facto standard rather than a
standard designed by committee.
Further, you seem to be conflating ideas:
- Message/warning formatting
- Error code design
The former deals with how the message is printed, while the latter is
far more semantic in how error codes are assigned. The latter will be
far harder to codify than even the former. Again a module to help with
this may work but I would guess that people will be less inclined to
use it than a module which formats the messages for them.
I read that pylint can handle the gobject introspection thanks to
astroid and pylint-brain.
I installed version 1.1 of pylint and py2gi.py is installed in my system.
But, I don't understand how to enable the use of py2gi, because I still
have the E1101
Instance of 'Box' has no 'pack_start' member (no-member)
Thanks in advance for your help,
When we updated to pylint 1.1 many of the messages changed. In
particular, the invalid-name (C0103) message used to say:
... Invalid name "Test_which" for type class (should match
which was really useful, since (if you understand regular expressions)
it tells the user exactly what the name pattern should be. Now, however,
it only says:
... Invalid class name "Test_which"
This is less than useful, since as a user I might not know where to go
to find out what the RE is that was matched against. The messages
generated by --list-msgs only shows the general message:
:invalid-name (C0103): *Invalid %s name "%s"*
Used when the name doesn't match the regular expression associated to
(constant, variable, class...).
which doesn't help.
The default REs show up in the --long-help output, but a user has to run
that manually, then look for the option which affects the particular
message he is seeing.
Is there a way simple way to get the REs on the generated html pages again?
Mark E. Hamilton
Senior Member of Technical Staff
Sandia National Laboratories
often I write code like this:
for expression in expressions:
if not expression.isExpressionConstantRef():
That is to search in an iterable, and return based on finding something,
or returning in the alternative, I specifically prefer the "else:"
branch over merely putting it after the "for" loop.
This triggers the above message, which I consider flawed, because as
soon as there is a "raise", or "return", that should be good enough as
well. Basically any aborting statement, not only break.
I wanted to hear your opinion on this, pylint bug, or only in my mind.
I'm upgrading from pylint 0.27.0 to 1.0.0 in my company's code base and I've run into a bit of an issue. For several of our modules, we use 'pylint: disable=C0302', to disable the too-many-lines error for the module. In pylint 0.26 this worked just fine as long as we put the line somewhere at the top of the module before any imports, like so:
#! /usr/bin/env python
# pylint: disable=C0302
<rest of code>
However, after upgrading to 1.0.0 it seems that the disable comment for C0302 HAS to go on the first line. This gets awkward because one has to mix it with the shebang line, like so:
#! /usr/bin/env python # pylint: disable=C0302
<rest of code>
I have a feeling that this will be difficult and awkward for other developers in our code base to figure out. It's also very strange because module-wide suppression of other errors (e.g. W0223) continue to work even if they are not on the very first line. Is this a bug or is there some other way to accomplish a module-wide suppression of C0302 without mixing it with the shebang?