Just wanted to drop you a line that the Pylint website
<http://www.pylint.org/> is down, as I can see locally, on our CIs (I
initially noticed it when our docs build failed due to sphinx linkcheck
detecting the pylint links as broken) and on isup.me.
Also, as it seems you have a working HTTPS implementation it would be
prudent to change your published links over to that.
I stumbled on this in a colleague's code today:
def __init__(self, me):
self._name = me
Running this code would find the bug very quickly (good argument for unit
tests). Still, it would be nice if some static analysis tool could identify
that the return value would produce infinite recursion. Neither pylint nor
pyflakes complained. I'm not asking for a solution to the halting problem.
Just a realization that you are inside a property method and returning that
item. I'd be happy for a false positive or two. I'm well-steeped in use of
# pylint: disable=...
One more in rare cases wouldn't be a big deal.
(I'd be happy to try and write a checker for pylint. Last time I looked
though a few years ago, I lacked enough knowledge of the code base to knock
Pylint-1.7.1 is installed here and runs with python-3.6.5. I have a
directory with 5 modules (not my project) and I want to understand the logic
using pyreverse. It's not working for me and the pyreverse web page hasn't
helped me learn how to use it successfully.
The directory contains these modules:
controller.py, main.py, addModRecord.py, commonDlgs.py, model.py
Invoking pyreverse yields a ValueError:
$ pyreverse -o png -f ALL -cAS -p ./main.py addModRecord.py commonDlgs.py controller.py model.py
Traceback (most recent call last):
File "/usr/bin/pyreverse", line 11, in <module>
load_entry_point('pylint==1.7.1', 'console_scripts', 'pyreverse')()
File "/usr/lib/python3.6/site-packages/pylint/__init__.py", line 24, in run_pyreverse
File "/usr/lib/python3.6/site-packages/pylint/pyreverse/main.py", line 110, in __init__
File "/usr/lib/python3.6/site-packages/pylint/pyreverse/main.py", line 125, in run
diadefs = handler.get_diadefs(project, linker)
File "/usr/lib/python3.6/site-packages/pylint/pyreverse/diadefslib.py", line 223, in get_diadefs
File "/usr/lib/python3.6/site-packages/pylint/pyreverse/diadefslib.py", line 185, in class_diagram
module, klass = klass.rsplit('.', 1)
ValueError: not enough values to unpack (expected 2, got 1)
Pyreverse is looking at ../pyreverse/main.py rather than the main.py
module in the code I want analyzed. I need to learn how to write the command
line so pyreverse shows me the relationships among modules, classes, and
methods, and I've not found docs or a web site discussion that shows me how
to do this.
tl;dr: Two of us think it'd be good to collaborate even more and
standardize on more things between projects. We'd like your feedback.
So Claudiu and I had some time to chat while we were at PyCon. I think
much of the discussion was spurred by
https://github.com/PyCQA/meta/issues/25 and I think we came to some
solid agreement on things we'd like to see the PyCQA become and do.
We covered two main topics:
1. The joking name that I chose for our tiny organization is causing
confusion for others. For example, we have several tools that we
maintain that contribute to improving and maintaining people's code
quality. However, people often see two or more of those tools as
exclusive or as conflicting (e.g., pylint and flake8, pylint and
2. There are a lots of things that we all do similarly but just
slightly differently. It would be *fantastic* for our users if they
didn't have to learn 15 ways of doing things (I'm exaggerating of
An Authority should be an Authority ... or at least act as something
approximating a single unit
The idea here is that we should do our best to explain to users that
there's no animosity between pylint and flake8. In fact, Flake8 runs
Pylint everytime we run our tests. Just like flake8 runs itself
against its own code base as well as Pylint, we should have a cohesive
story to users. There's lots of junk on the internet about why to use
one over the other.
I proposed that we might want to sell users on an approach like so: If
you've never used one of these tools before, start small. Flake8 seems
to be slightly easier for folks to get started with. Let's suggest
that as a first step kind of like sticking your toes in the water to
determine the temperature. Once you're happy with that and you want
something a little more advanced and powerful, start using Pylint.
Continue using both. They overlap but they don't entirely coincide.
You learned A, I learned B, they learned C, let's all learn from each other
The next step would be aggregating everyone's learnings. Pylint has
been around for nearly 2 decades (if I remember correctly) and Flake8
has been around for almost a decade (maybe it's been a decade? I don't
even know anymore). We have more and more tools. We all use
configuration files and we all have slightly different behaviour with
respect to how we handle them, find them, etc.
We could all standardize and document a standard for the organization.
In my opinion, that standard should be pyproject.toml (c.f.,
https://snarky.ca/clarifying-pep-518/). INI + ConfigParser is
terrible. TOML, while I don't like the fact that it hasn't been
properly specified or standardized, is at least a bit more flexible.
Further, the packaging community has chosen this and is unifying on
it. The PEP even specifically suggests people being able to use
sections named "tool.pylint" or "tool.flake8". It looks close enough
to INI that I don't think it'd be a pain for users to migrate.
I think as we make this migration, we should also consider migrating
to a simpler configuration structure - namely eliminating User
configuration (either in $HOME or in $XDG_CONFIG) as well as system
It makes sense that if we're standardizing on all of this for users,
we can also build libraries for standardizing things in the org: ideas
of some low hanging-fruit:
- Multiprocessing (-j/--jobs for concurrency)
- Configuration file management (e.g., format, parsing, locating, and merging)
- Naming error codes (e.g., standardizing on how pylint names things)
- Standardizing on configurability of running versus ignored checks
- And a few others
Naturally, this is just the things we discussed and we're by no means
the people making final decisions here, so we'd like you to weigh in.
Please CC-me in all answers to this message, I am not subscribed to the
If I implement an abstract class in Python:
>>> class Ancestor(object):
>>> def __init__(self):
>>> raise NotImplementedError
Then write a child class:
>>> class Child(Ancestor):
>>> def __init__(self):
>>> return self
Pylint finds a warning W0231 super-init-not-called on the definition of
IMHO, it should not be the case, as a Child class will never call the
constructor of the ancestor.
Am I missing something?
I am GSoC student under Kodi(XBMC) org. And we have an addon-checker tool
<https://github.com/xbmc/addon-check> that checks for addons submitted.
I will be using pylint for implementing some checks into our code base. Now
the problem we are facing is that if the folder is missing __init__.py file
pylint does run on those folders.
Now this problem is know under issue #352
<https://github.com/PyCQA/pylint/issues/352> but no work is been done on it
since last year.
so I was willing to know that Are you guys planning to solve the issue any
time soon ?
We recently tried to upgrade from pylint-1.5 to pylint-1.8 because of
some of the new features we wanted. Unfortunately, this upgrade failed
because we use the html output feature, and have for some years, and
that is now gone.
Is there a recommended solution for generating HTML from the results
other than 'write it yourself', as the documentation seems to indicate?
Some sort of converter that will generate the same style report as
before for us? I tried pylint-json2html, but couldn't get that to work.
Mark E. Hamilton
Engineering Sciences Center
Senior Member of Technical Staff
Sandia National Laboratories