Mailman 3 March 2018 - code-quality

Some other additions to PyCQA possibly
by Carl Crowder 21 Apr '18

21 Apr '18

Hi there, There are a few other things that came out of the ashes of Landscape.io that may or may not make sense to move into PyCQA too: 1) pylint-celery - this one I don’t think anyone uses and it isn’t very useful anyway 2) pylint-plugin-utils - this is used by pylint-django and pylint-celery as far as I know, I’m not sure how useful it is outside of that 3) prospector - this is the bigger one, lots of people use this, but I can understand that it might not be in the same state of mind as the rest of the PyCQA code :-) Let me know what you think either way! Carl

5 8

__all__ defined inside a class
by Alexander Todorov 23 Mar '18

23 Mar '18

Hi folks, I've just noticed that a legacy piece of code I'm working with contains the following pattern: class SomeClass(object): __all__ = ['add', 'delete'] def __init__(self): pass def get(self): pass def add(self, x): pass def delete(self, x): pass And the caller of this class actually uses the .get() method. I have this in at least 10 different places. I wasn't able to find any information about __all__ having any special meaning when defined inside a class so this looks like a mistake. Q1: Do we want pylint to warn about __all__ being detected not at module level ? Q2: Do we want another check to warn about class attributes staring with single/double underscore ? -- Alex

4 4

Hello I am a newcomer applying for GSoC, trying to get an upstream commit
by ishan srivastava 23 Mar '18

23 Mar '18

I think I can fix the issue https://github.com/PyCQA/pylint/issues/1822 <https://github.com/PyCQA/pylint/issues/1822>, can someone direct me to which files I should be looking at? Ishan Srivastava p: +91 8277536737 e: 160010013(a)iitdh.ac.in <mailto:160010013@iitdh.ac.in>, ishan.srt(a)gmail.com <mailto:ishan.srt@gmail.com>

1 0

Maintainers for Baron/RedBaron
by Bryce Guinta 22 Mar '18

22 Mar '18

It looks like [baron](https://github.com/PyCQA/baron) and [redbaron]( https://github.com/PyCQA/redbaron) haven't had any response from their maintainers for several months now. There are some really great pull requests waiting to be merged for Python3 support, and I'd like to see these projects continue instead of being abandoned or forked. Could we send out a request for new maintainers to keep these projects going?

1 0

Small pyflakes surprise
by Skip Montanaro 20 Mar '18

20 Mar '18

I don't use pyflakes much myself, but the maintainers of our CI system at work run it as an early stage, so if it complains, well, you know, nothing much happens. So, I'm starting to pay a bit closer attention to its output. To keep me from forgetting it, my Makefile's lint target now runs both pylint and pyflakes against a couple directories in my repo. Running "make lint" today, I saw pyflakes emit messages for a file named utils.py.~1~, that is, an Emacs backup file. This is a new file in my sandbox which hasn't yet been added to the Git repo, so Emacs knows to create backups. (Once checked in, it will rely on Git.) It seems odd to me that pyflakes would decide to check such a file. Is this a bug or a feature? Looks like we are running 1.6.0, which appears to be more-or-less current. Thx, Skip Montanaro

1 1

[PyCQA/astroid] backport bugfix for six.moves to release branch 1.6
by Francesco Tartaggia 16 Mar '18

16 Mar '18

Hi all, I'm writing about PR https://github.com/PyCQA/astroid/pull/478 (Fix submodule import in six.moves). Are you interested in backporting the fix from master branch to the 1.6 release branch? Doing so would fix the "Unable to import 'six.moves.urllib.parse' (import-error)" issue for pylint, without modifying pylint's astroid dependency declaration. If so, do you prefer a PR right on top of latest released tag "astroid-1.6.1" or on top of branch 1.6? What are the release schedule for astroid-1.6.2? Best regards, francesco tartaggia

2 2

Bug in flake8 git pre-commit hook?
by Mattia Ciollaro 08 Mar '18

08 Mar '18

Hey guys, Try and do the following: ```bash mkdir test && cd test git init flake8 --install-hook git git config --bool flake8.strict true echo a= 2 > foo.py && git add foo.py git commit -m "This is bad!" ``` This commit is accepted! It shouldn't be. Note that if you instead do ```bash mkdir test2 && cd test2 git init flake8 --install-hook git git config --bool flake8.strict true echo a= 2 > foo.py && git add foo.py git commit -m "Add a foo file" echo b =3 > foo.py && git add foo.py git commit -m "This is bad!" ``` then the first commit is wrongly accepted, but the second commit (and any following) is correctly rejected. My best guess: this has to do with `copy_indexed_files_to` in the line ```python filepaths = list(copy_indexed_files_to(tempdir, lazy)) ``` inside of the definition of `hook` from flake8.main.git Curious to know your thoughts! Cheers, Mattia

1 0