From mattia.ciollaro at spreemo.com Wed Mar 7 14:33:13 2018 From: mattia.ciollaro at spreemo.com (Mattia Ciollaro) Date: Wed, 7 Mar 2018 14:33:13 -0500 Subject: [code-quality] Bug in flake8 git pre-commit hook? Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.crowder at gmail.com Thu Mar 8 12:58:34 2018 From: carl.crowder at gmail.com (Carl Crowder) Date: Thu, 8 Mar 2018 09:58:34 -0800 Subject: [code-quality] Some other additions to PyCQA possibly Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcmanticore at gmail.com Thu Mar 8 13:02:48 2018 From: pcmanticore at gmail.com (Claudiu Popa) Date: Thu, 8 Mar 2018 19:02:48 +0100 Subject: [code-quality] Some other additions to PyCQA possibly In-Reply-To: References: Message-ID: Hi Carl, >From my point of view, they could all live in the organisation, at least pylint-plugin-utils and prospector still seem useful to folks. On Thu, Mar 8, 2018 at 6:58 PM, Carl Crowder wrote: > 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 > > _______________________________________________ > code-quality mailing list > code-quality at python.org > https://mail.python.org/mailman/listinfo/code-quality > From ashley at awhetter.co.uk Thu Mar 8 15:51:22 2018 From: ashley at awhetter.co.uk (Ashley Whetter) Date: Thu, 08 Mar 2018 12:51:22 -0800 Subject: [code-quality] Some other additions to PyCQA possibly In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From carl.crowder at gmail.com Thu Mar 8 19:06:43 2018 From: carl.crowder at gmail.com (Carl Crowder) Date: Thu, 8 Mar 2018 16:06:43 -0800 Subject: [code-quality] Some other additions to PyCQA possibly In-Reply-To: References: Message-ID: I would say that the motivation of pylint-plugin-utils was twofold: First - it was a bit of a pain to try to figure out how to write a plugin. This was about 5 years ago though so not sure if that is still true but it took me a while to figure out. Docs on that could be better. Second - it was really just a utility to make it easier to do several things which were useful, such as ?skip this error in this context? or ?add this error in this context?. I definitely think the plugin API in pylint could be easier to use, I?m not sure if pylint-plugin-utils is the answer because it?s just a bandaid really. It could be useful to see the symptoms it was trying to solve though. Carl On 8 March 2018 at 21:51:29, Ashley Whetter (ashley at awhetter.co.uk) wrote: Does it make more sense to try and merge pylint plugin utils into pylint core? If the plugin interface is clunky enough on its own that there exists utilities for creating plugins, then I think that's an issue that we need to look at resolving. I've been taking a look at this repository recently for the per directory config project in pylint to get sense of how the plugin interface is being used and getting ideas for the kind of thing that we should be aiming for. Ashley -------------- next part -------------- An HTML attachment was scrubbed... URL: From francesco.tartaggia at etiqa.it Fri Mar 16 07:27:02 2018 From: francesco.tartaggia at etiqa.it (Francesco Tartaggia) Date: Fri, 16 Mar 2018 12:27:02 +0100 Subject: [code-quality] [PyCQA/astroid] backport bugfix for six.moves to release branch 1.6 Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcmanticore at gmail.com Fri Mar 16 08:51:44 2018 From: pcmanticore at gmail.com (Claudiu Popa) Date: Fri, 16 Mar 2018 13:51:44 +0100 Subject: [code-quality] [PyCQA/astroid] backport bugfix for six.moves to release branch 1.6 In-Reply-To: References: Message-ID: Hi Francesco, Yes, definitely, sounds like a good idea! For astroid and pylint's maintenance branches we prefer PRs on top of the corresponding branches rather than on top of the tag. There's currently no release schedule planned for 1.6.2, we just have to release it on PyPi. SInce we already have a couple of more PRs that were backported, I'm going to do it today. Thanks! Claudiu On 16 March 2018 at 12:27, Francesco Tartaggia wrote: > 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 > > > _______________________________________________ > code-quality mailing list > code-quality at python.org > https://mail.python.org/mailman/listinfo/code-quality > From francesco.tartaggia at etiqa.it Fri Mar 16 09:50:09 2018 From: francesco.tartaggia at etiqa.it (Francesco Tartaggia) Date: Fri, 16 Mar 2018 14:50:09 +0100 Subject: [code-quality] [PyCQA/astroid] backport bugfix for six.moves to release branch 1.6 In-Reply-To: References: Message-ID: Hi Claudiu, I submitted PR https://github.com/PyCQA/astroid/pull/516. Unfortunately it fails some pylint checks on py35, but failures seem to be on files not related with the PR itself: I'm leaving the PR untouched. francesco On 16 March 2018 at 13:51, Claudiu Popa wrote: > Hi Francesco, > > Yes, definitely, sounds like a good idea! For astroid and pylint's > maintenance > branches we prefer PRs on top of the corresponding branches rather > than on top of the tag. > There's currently no release schedule planned for 1.6.2, we just have to > release > it on PyPi. SInce we already have a couple of more PRs that were > backported, > I'm going to do it today. > > Thanks! > Claudiu > > On 16 March 2018 at 12:27, Francesco Tartaggia > wrote: > > 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 > > > > > > _______________________________________________ > > code-quality mailing list > > code-quality at python.org > > https://mail.python.org/mailman/listinfo/code-quality > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip.montanaro at gmail.com Mon Mar 19 12:07:51 2018 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Mon, 19 Mar 2018 11:07:51 -0500 Subject: [code-quality] Small pyflakes surprise Message-ID: 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 From skip.montanaro at gmail.com Mon Mar 19 14:24:57 2018 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Mon, 19 Mar 2018 13:24:57 -0500 Subject: [code-quality] Small pyflakes surprise In-Reply-To: References: Message-ID: > 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. Issue and PR created: https://github.com/PyCQA/pyflakes/issues/332 https://github.com/PyCQA/pyflakes/pull/331 Skip From carlospecter at gmail.com Wed Mar 21 11:24:31 2018 From: carlospecter at gmail.com (=?utf-8?Q?Carlos_Co=C3=AAlho?=) Date: Wed, 21 Mar 2018 12:24:31 -0300 Subject: [code-quality] Some other additions to PyCQA possibly In-Reply-To: References: Message-ID: Any news on moving prospector to PyCQA? Em 8 de mar de 2018, ?(s) 21:06, Carl Crowder escreveu: > I would say that the motivation of pylint-plugin-utils was twofold: > > First - it was a bit of a pain to try to figure out how to write a plugin. This was about 5 years ago though so not sure if that is still true but it took me a while to figure out. Docs on that could be better. > > Second - it was really just a utility to make it easier to do several things which were useful, such as ?skip this error in this context? or ?add this error in this context?. > > I definitely think the plugin API in pylint could be easier to use, I?m not sure if pylint-plugin-utils is the answer because it?s just a bandaid really. It could be useful to see the symptoms it was trying to solve though. > > Carl > > >> On 8 March 2018 at 21:51:29, Ashley Whetter (ashley at awhetter.co.uk) wrote: >> >> Does it make more sense to try and merge pylint plugin utils into pylint core? >> If the plugin interface is clunky enough on its own that there exists utilities for creating plugins, then I think that's an issue that we need to look at resolving. >> I've been taking a look at this repository recently for the per directory config project in pylint to get sense of how the plugin interface is being used and getting ideas for the kind of thing that we should be aiming for. >> >> Ashley > _______________________________________________ > code-quality mailing list > code-quality at python.org > https://mail.python.org/mailman/listinfo/code-quality -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce.paul.guinta at gmail.com Wed Mar 21 21:49:40 2018 From: bryce.paul.guinta at gmail.com (Bryce Guinta) Date: Wed, 21 Mar 2018 19:49:40 -0600 Subject: [code-quality] Maintainers for Baron/RedBaron Message-ID: 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From atodorov at mrsenko.com Thu Mar 22 17:23:37 2018 From: atodorov at mrsenko.com (Alexander Todorov) Date: Thu, 22 Mar 2018 23:23:37 +0200 Subject: [code-quality] __all__ defined inside a class In-Reply-To: References: Message-ID: <284042a1-e9c7-f056-517c-826f645e6d8f@mrsenko.com> 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 From ishan.srt at gmail.com Thu Mar 22 17:25:30 2018 From: ishan.srt at gmail.com (ishan srivastava) Date: Fri, 23 Mar 2018 02:55:30 +0530 Subject: [code-quality] Hello I am a newcomer applying for GSoC, trying to get an upstream commit Message-ID: <22F17889-F88A-453E-9742-2396B97A4ACD@gmail.com> I think I can fix the issue 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 at iitdh.ac.in , ishan.srt at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From graffatcolmingov at gmail.com Thu Mar 22 21:30:44 2018 From: graffatcolmingov at gmail.com (Ian Stapleton Cordasco) Date: Thu, 22 Mar 2018 20:30:44 -0500 Subject: [code-quality] __all__ defined inside a class In-Reply-To: <284042a1-e9c7-f056-517c-826f645e6d8f@mrsenko.com> References: <284042a1-e9c7-f056-517c-826f645e6d8f@mrsenko.com> Message-ID: On Thu, Mar 22, 2018 at 4:23 PM, Alexander Todorov wrote: > 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 Hi Alex, Regarding Q1: Maybe? It's not entirely clear based on your brief example what the original author though __all__ did here. Regarding Q2: Why would you want to prohibit class attributes starting with single or double underscores? The former is useful for "private" class attributes. The latter performs name mangling which can be useful in situations (see: https://stackoverflow.com/a/1301369/1953283). I don't think pylint should be warning in this case. Cheers, Ian From list at satchell.net Thu Mar 22 21:53:50 2018 From: list at satchell.net (Stephen Satchell) Date: Thu, 22 Mar 2018 18:53:50 -0700 Subject: [code-quality] __all__ defined inside a class In-Reply-To: References: <284042a1-e9c7-f056-517c-826f645e6d8f@mrsenko.com> Message-ID: <654e1edb-9351-430d-b663-621a6b2a579b@satchell.net> On 03/22/2018 06:30 PM, Ian Stapleton Cordasco wrote: > On Thu, Mar 22, 2018 at 4:23 PM, Alexander Todorov wrote: >> 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 > > Hi Alex, > > Regarding Q1: Maybe? It's not entirely clear based on your brief > example what the original author though __all__ did here. > > Regarding Q2: Why would you want to prohibit class attributes starting > with single or double underscores? The former is useful for "private" > class attributes. The latter performs name mangling which can be > useful in situations (see: > https://stackoverflow.com/a/1301369/1953283). I don't think pylint > should be warning in this case. And then, from http://xion.io/post/code/python-all-wild-imports.html, is this little gem of a note: > All in all (ahem), this hints at a cute little trick which is also very self-evident: > > __all__ = ['DO_NOT_WILD_IMPORT'] > > Put this in a Python module, and no one will be able to import * from it! > Much more effective than any lint warning ;-) From steve at pearwood.info Fri Mar 23 01:00:28 2018 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 23 Mar 2018 16:00:28 +1100 Subject: [code-quality] __all__ defined inside a class In-Reply-To: References: <284042a1-e9c7-f056-517c-826f645e6d8f@mrsenko.com> Message-ID: <20180323050027.GT16661@ando.pearwood.info> On Thu, Mar 22, 2018 at 08:30:44PM -0500, Ian Stapleton Cordasco wrote: > Regarding Q2: Why would you want to prohibit class attributes starting > with single or double underscores? The former is useful for "private" > class attributes. The latter performs name mangling which can be > useful in situations (see: > https://stackoverflow.com/a/1301369/1953283). I don't think pylint > should be warning in this case. But __all__ is a dunder name, and dunders are reserved for use by Python. I don't know what the author of the class thought they were doing, but they shouldn't have been using __all__ for it, hence the idea of a warning. But it probably isn't practical to keep a white list of permitted dunders and warn about those that any others. -- Steve From atodorov at mrsenko.com Fri Mar 23 07:24:14 2018 From: atodorov at mrsenko.com (Alexander Todorov) Date: Fri, 23 Mar 2018 13:24:14 +0200 Subject: [code-quality] __all__ defined inside a class In-Reply-To: <20180323050027.GT16661@ando.pearwood.info> References: <284042a1-e9c7-f056-517c-826f645e6d8f@mrsenko.com> <20180323050027.GT16661@ando.pearwood.info> Message-ID: <48190749-61e8-73b3-cbb7-168cce391282@mrsenko.com> ?? 23.03.2018 ? 07:00, Steven D'Aprano ??????: > On Thu, Mar 22, 2018 at 08:30:44PM -0500, Ian Stapleton Cordasco wrote: > >> Regarding Q2: Why would you want to prohibit class attributes starting >> with single or double underscores? The former is useful for "private" >> class attributes. The latter performs name mangling which can be >> useful in situations (see: >> https://stackoverflow.com/a/1301369/1953283). I don't think pylint >> should be warning in this case. > > But __all__ is a dunder name, and dunders are reserved for use by > Python. > > I don't know what the author of the class thought they were doing, but > they shouldn't have been using __all__ for it, hence the idea of a > warning. But it probably isn't practical to keep a white list of > permitted dunders and warn about those that any others. > Thanks everyone for the replies and the useful links. I also don't know what the original author was trying to do. In most cases in the original code this class attribute is not used and it looks like they were trying to control the list of exported class methods. I don't have other explanation about it. I am with Steven on this one, __all__ is a dunder (plus it looks very confusing inside the class context) so warn about it. I didn't express myself clearly on the second question. Instead of warning about class attributes that *start* with single or double underscore how about pylint warns about class attributes whose names are dunders (both start and end with double underscores) ? -- Alex