Sporadic C0103(invalid-name) warnings
Hi, I thought that I'd ask here before opening an issue. I'm seeing intermittent warnings on the same code. For this line: doc.DeveloperName = dev_type # pylint: disable=invalid-name I get this warning: file.py:50: [C0103(invalid-name), TestSomething._create] Attribute name "DeveloperName" doesn't conform to '[a-z_][a-z0-9_]{2,50}$' pattern The environment is sterile; this happens during our build process which doesn't use artifacts from intermediate stages. The code is retrieved with "git clone" followed by installing fixed pip packages and running pylint. Versions: Python: python:3.6.11-stretch (docker image) astroid==2.4.2 pylint==2.5.3 Any ideas on how to prevent this? Right now I only have the workaround of add the extra strings to "good-names" in pylintrc. Thanks in advance! - David
Hey, On Wed, Aug 12, 2020 at 09:12:00AM -0000, David Resnick via code-quality wrote:
I thought that I'd ask here before opening an issue. I'm seeing intermittent warnings on the same code.
Perhaps a shot in the dark, but do you happen to use multiple jobs via pylint's -j option? I've seen various funny behavior when doing that. Florian -- me@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/
Thanks a lot for the idea, Florian. Removing that flag has made a huge difference in my pylint runs. I don't know if it will stop it from being flaky, but after the flag was removed I received a lot of correct warnings that for some reason were not being shown. It is definitely a good idea not to use this flag. - David On Wed, Aug 12, 2020 at 11:38 PM Florian Bruhin <me@the-compiler.org> wrote:
-j doesn’t offer any benefit but does create some pain, it doesn’t even make runs faster. It should just be removed/disabled/pass-thru’d, for now, until it’s stable and does what it says on the tin. I’ve a few PRs aimed at testing the parallel aspect, improving the accuracy and eventually improving the performance of it.... but it’s been slow going getting them in, partly my fault, but partly because of the feedback cadence. On Sun, 23 Aug 2020 at 14:55, David Resnick via code-quality < code-quality@python.org> wrote:
double the fish ltd. Kemp House 160 City Road London United Kingdom EC1V 2NX Tel: 07854616533 Email: frank@doublethefish.com
Hey, On Wed, Aug 12, 2020 at 09:12:00AM -0000, David Resnick via code-quality wrote:
I thought that I'd ask here before opening an issue. I'm seeing intermittent warnings on the same code.
Perhaps a shot in the dark, but do you happen to use multiple jobs via pylint's -j option? I've seen various funny behavior when doing that. Florian -- me@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/
Thanks a lot for the idea, Florian. Removing that flag has made a huge difference in my pylint runs. I don't know if it will stop it from being flaky, but after the flag was removed I received a lot of correct warnings that for some reason were not being shown. It is definitely a good idea not to use this flag. - David On Wed, Aug 12, 2020 at 11:38 PM Florian Bruhin <me@the-compiler.org> wrote:
-j doesn’t offer any benefit but does create some pain, it doesn’t even make runs faster. It should just be removed/disabled/pass-thru’d, for now, until it’s stable and does what it says on the tin. I’ve a few PRs aimed at testing the parallel aspect, improving the accuracy and eventually improving the performance of it.... but it’s been slow going getting them in, partly my fault, but partly because of the feedback cadence. On Sun, 23 Aug 2020 at 14:55, David Resnick via code-quality < code-quality@python.org> wrote:
double the fish ltd. Kemp House 160 City Road London United Kingdom EC1V 2NX Tel: 07854616533 Email: frank@doublethefish.com
participants (3)
-
David Resnick -
Florian Bruhin -
Frank Harrison