From mail at mayurshah.in  Fri Jul 13 10:40:37 2018
From: mail at mayurshah.in (mail at mayurshah.in)
Date: Fri, 13 Jul 2018 14:40:37 +0000
Subject: [code-quality] [meetup] [online] Subscribe to Software Testing
 Board's monthly meetups
Message-ID: <0000000000009440c80570e27647@google.com>

Hi All,

The team at Software Testing Board organizes a monthly meetup where one of  
the testing professionals will talk about the new Testing Framework,  
Testing Strategy, any new Testing Tool or anything related to Software  
Testing.

These meetups are not tutorials or workshops. Just another tester is  
presenting you the new tools, framework or an idea they are working on. You  
can pick it up and explore it further. You can ask your questions to the  
presenters and they will try to answer with the best of their knowledge.  
You can even provide your feedback or suggestions for speakers or to us.

These live meetups are happening through YouTube and Google Hangout every  
4th Saturday of the month at 5:00 PM IST.

To join the upcoming meetup, go to YouTube and search "Software Testing  
Board". Click subscribe and press the bell icon to never miss a  
notification from us.

To know more about the meetup, check out About section of the channel.

If you have any questions, feel free to write back or connect with me on  
LinkedIn (https://www.linkedin.com/in/theqaguy/)

Thank you,
Mayur Shah

From pcmanticore at gmail.com  Sun Jul 15 05:54:27 2018
From: pcmanticore at gmail.com (Claudiu Popa)
Date: Sun, 15 Jul 2018 11:54:27 +0200
Subject: [code-quality] pylint 2.0 / astroid 2.0 released!
Message-ID: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>

Hi folks,

The pylint team is happy to announce the release of pylint 2.0 and astroid 2.0!

This release only works with Python 3.4+, while older pylint releases
are still maintained for Python 2 compatibility, at least until next year.

You can find more details about what's new in this release over here:
http://pylint.pycqa.org/en/latest/whatsnew/2.0.html

Thanks and enjoy linting!
Claudiu & all the Pylint contributors

From graffatcolmingov at gmail.com  Sun Jul 15 09:22:05 2018
From: graffatcolmingov at gmail.com (Ian Stapleton Cordasco)
Date: Sun, 15 Jul 2018 08:22:05 -0500
Subject: [code-quality] pylint 2.0 / astroid 2.0 released!
In-Reply-To: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
References: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
Message-ID: <CAN-Kwu3q8eSw6dwE5GQwNqdEqr7strk5kJkQ7mhmvNQtZazeaQ@mail.gmail.com>

Congratulations!

This is a huge milestone!

On Sun, Jul 15, 2018 at 4:54 AM, Claudiu Popa <pcmanticore at gmail.com> wrote:
> Hi folks,
>
> The pylint team is happy to announce the release of pylint 2.0 and astroid 2.0!
>
> This release only works with Python 3.4+, while older pylint releases
> are still maintained for Python 2 compatibility, at least until next year.
>
> You can find more details about what's new in this release over here:
> http://pylint.pycqa.org/en/latest/whatsnew/2.0.html
>
> Thanks and enjoy linting!
> Claudiu & all the Pylint contributors
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality

From kay.hayen at gmail.com  Mon Jul 16 07:56:02 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Mon, 16 Jul 2018 13:56:02 +0200
Subject: [code-quality] pylint 2.0 / astroid 2.0 released!
In-Reply-To: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
References: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
Message-ID: <CAMEZBD+meqjOifje8g8oEmPqsfTqCyyZOBMVR1zthMrQdDO+Dw@mail.gmail.com>

Hello PyLint team,

my congratulations too. I have a few questions though.

First of all, I am going to maintain my code base for Python2 and
Python3 dual lingo. Using both the Python2 and the Python3 variant of
PyLint, in different major versions poses a problem.

One thing I encounter is "too-many-statements", which was fixed a
bunch I assume. Now if I whitelist those, I will get
"useless-suppression" by PyLint 1.9.2 and will have to put that one
too,
which prevents me from noticing if it ever becomes unnecessary. I wish
there was a way for me, to not only do pylint:
disable=too-many-statements, but say pylint2:
disable=too-many-statements
and then only that "pylint2" version would consider it. But I assume,
you don't care about people who still care about Python2 code
correctness and Python3 correctness at the same time? It
must be a clear minority that I am in.

I might have to solve these warnings. In some places, I like to
tolerate breaking those rules, if there is nothing to gain from
breaking things up, say e.g. populating an option parser is going
to be a lot of statements, that is just that then.

The other is the new message that I am getting in cases:

nuitka\nodes\ExpressionBases.py:116 E1128 assignment-from-none
ExpressionBase.getStrValue Assigning to function call which only
returns None

For code like this:

    def getStringValue(self):
        """ Node as string value, if possible."""
        # Virtual method, pylint: disable=no-self-use
        return None

    def getStrValue(self):
        """ Value that "str" or "PyObject_Str" would give, if known.

            Otherwise it is "None" to indicate unknown. Users must not
            forget to take side effects into account, when replacing a
            node with its string value.
        """
        string_value = self.getStringValue()

        if string_value is not None:
            return makeConstantReplacementNode(
                node     = self,
                constant = string_value
            )

        return None

Obviously I have disabled the "useless-return" immediately, I am not
comfortable with explicit "None" returns not allowed, so do I have to
white list those,
because that is what virtual methods are for. I am not getting what
this is about, is my pattern here so uncommon?

Otherwise, I have a bug to report related to "bad-continuation", but I
will do this to the tracker later today.

Generally I liked the new warnings, which lead to improved code, esp.
the new chaining suggestions are full spot on.

Yours,
Kay

From pcmanticore at gmail.com  Mon Jul 16 08:41:18 2018
From: pcmanticore at gmail.com (Claudiu Popa)
Date: Mon, 16 Jul 2018 14:41:18 +0200
Subject: [code-quality] pylint 2.0 / astroid 2.0 released!
In-Reply-To: <CAMEZBD+meqjOifje8g8oEmPqsfTqCyyZOBMVR1zthMrQdDO+Dw@mail.gmail.com>
References: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
 <CAMEZBD+meqjOifje8g8oEmPqsfTqCyyZOBMVR1zthMrQdDO+Dw@mail.gmail.com>
Message-ID: <CAMy=CLokEB6vnn6W4YJZqj2YjpwAO3+Rq8Pb5pzAvCiCp82JGg@mail.gmail.com>

Hi Kay,


On 16 July 2018 at 13:56, Kay Hayen <kay.hayen at gmail.com> wrote:
> Hello PyLint team,
>
> my congratulations too. I have a few questions though.

Thank you!


>
> First of all, I am going to maintain my code base for Python2 and
> Python3 dual lingo. Using both the Python2 and the Python3 variant of
> PyLint, in different major versions poses a problem.
>
> One thing I encounter is "too-many-statements", which was fixed a
> bunch I assume. Now if I whitelist those, I will get
> "useless-suppression" by PyLint 1.9.2 and will have to put that one
> too,
> which prevents me from noticing if it ever becomes unnecessary. I wish
> there was a way for me, to not only do pylint:
> disable=too-many-statements, but say pylint2:
> disable=too-many-statements
> and then only that "pylint2" version would consider it. But I assume,
> you don't care about people who still care about Python2 code
> correctness and Python3 correctness at the same time? It
> must be a clear minority that I am in.

I'm sorry, I don't quite understand what is the problem. Do you get
`too-many-statements` when using pylint with Python 2, but are you
not getting these when using pylint with Python 3?
If so, it might be because `too-many-statements` got some fixes
in Pylint 2.0, while it didn't for Pylint 1.9. If it's trivial to backport,
we can do it, as the 1.9 branch is going to be maintained for at least
a couple of months (2019 or so).
Regarding your second point related to filtering depending if it's
Pylint 2.0 or Pylint 1.9, I don't think it's necessary to have that
level of complexity.


> The other is the new message that I am getting in cases:
>
> nuitka\nodes\ExpressionBases.py:116 E1128 assignment-from-none
> ExpressionBase.getStrValue Assigning to function call which only
> returns None
>
> For code like this:
>
>     def getStringValue(self):
>         """ Node as string value, if possible."""
>         # Virtual method, pylint: disable=no-self-use
>         return None
>
>     def getStrValue(self):
>         """ Value that "str" or "PyObject_Str" would give, if known.
>
>             Otherwise it is "None" to indicate unknown. Users must not
>             forget to take side effects into account, when replacing a
>             node with its string value.
>         """
>         string_value = self.getStringValue()
>
>         if string_value is not None:
>             return makeConstantReplacementNode(
>                 node     = self,
>                 constant = string_value
>             )
>
>         return None

This one is tricky, because pylint cannot infer that you are relying on an
implementation class so that `getStringValue` method has a provided value
(if I understood correctly). If you use the `abc` module though, that
is, to mark
`getStringValue` as an abstract method, there's a chance you might not get this
error any longer (and if not, that's likely a bug that we should fix).


>
> Obviously I have disabled the "useless-return" immediately, I am not
> comfortable with explicit "None" returns not allowed, so do I have to
> white list those,
> because that is what virtual methods are for. I am not getting what
> this is about, is my pattern here so uncommon?

I don't recall exactly but I think it wasn't supposed to catch this particular
use case of no-body functions. Please submit it as an issue!

>
> Otherwise, I have a bug to report related to "bad-continuation", but I
> will do this to the tracker later today.

Sounds good, thanks!

>
> Generally I liked the new warnings, which lead to improved code, esp.
> the new chaining suggestions are full spot on.

Thank you!


Cheers,
Claudiu

From kay.hayen at gmail.com  Mon Jul 16 09:47:05 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Mon, 16 Jul 2018 15:47:05 +0200
Subject: [code-quality] pylint 2.0 / astroid 2.0 released!
In-Reply-To: <CAMy=CLokEB6vnn6W4YJZqj2YjpwAO3+Rq8Pb5pzAvCiCp82JGg@mail.gmail.com>
References: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
 <CAMEZBD+meqjOifje8g8oEmPqsfTqCyyZOBMVR1zthMrQdDO+Dw@mail.gmail.com>
 <CAMy=CLokEB6vnn6W4YJZqj2YjpwAO3+Rq8Pb5pzAvCiCp82JGg@mail.gmail.com>
Message-ID: <CAMEZBD+4VfebpbndDK2tTog3ZEwLdFMR7Kp4SxJ6uJKqNz_DbA@mail.gmail.com>

Hello there,

> > disable=too-many-statements, but say pylint2:
> > disable=too-many-statements
> > and then only that "pylint2" version would consider it. But I assume,
> > you don't care about people who still care about Python2 code
> > correctness and Python3 correctness at the same time? It
> > must be a clear minority that I am in.
>
> I'm sorry, I don't quite understand what is the problem. Do you get
> `too-many-statements` when using pylint with Python 2, but are you
> not getting these when using pylint with Python 3?

I am now getting them with Python3, I should have gotten them with
Python2 all the time.

> If so, it might be because `too-many-statements` got some fixes
> in Pylint 2.0, while it didn't for Pylint 1.9. If it's trivial to backport,
> we can do it, as the 1.9 branch is going to be maintained for at least
> a couple of months (2019 or so).

That would be great. However, eventually there will be differences.

> Regarding your second point related to filtering depending if it's
> Pylint 2.0 or Pylint 1.9, I don't think it's necessary to have that
> level of complexity.

I guessed so. Maybe I will have to drop PyLint for checking Python2
eventually. It's
a pity, because it can really save a *lot* of CPU cycles for me. When
PyLint finds
an error in Nuitka, before I running a full test battery of endless
compilations of
Python codes that are not affected, to finally see what is normally
visible to PyLint.

That complexity then ends up in my hands, e.g. with my own way of pre-processing
files for PyLint, so that it would behave as I see it. Copying the
source tree before
checking to a temporary folder while replacing "pylint2: disable..."
with nothing or
with "pylint: disable" depending on PyLint version. Making your parser accept
another keyword would therefore be great. Is this something a plugin
could do for
PyLint?

> > The other is the new message that I am getting in cases:
> >
> > nuitka\nodes\ExpressionBases.py:116 E1128 assignment-from-none
> > ExpressionBase.getStrValue Assigning to function call which only
> > returns None
> >
> > For code like this:
> >
> >     def getStringValue(self):
> >         """ Node as string value, if possible."""
> >         # Virtual method, pylint: disable=no-self-use
> >         return None
> >
> >     def getStrValue(self):
> >         """ Value that "str" or "PyObject_Str" would give, if known.
> >
> >             Otherwise it is "None" to indicate unknown. Users must not
> >             forget to take side effects into account, when replacing a
> >             node with its string value.
> >         """
> >         string_value = self.getStringValue()
> >
> >         if string_value is not None:
> >             return makeConstantReplacementNode(
> >                 node     = self,
> >                 constant = string_value
> >             )
> >
> >         return None
>
> This one is tricky, because pylint cannot infer that you are relying on an
> implementation class so that `getStringValue` method has a provided value
> (if I understood correctly). If you use the `abc` module though, that
> is, to mark
> `getStringValue` as an abstract method, there's a chance you might not get this
> error any longer (and if not, that's likely a bug that we should fix).

Making it abstract would be counter productive, as it's also the
default implementation to be used by most of the things. It
is for overload really.

But I get it, there is no way of knowing. Maybe disable it for methods?

Thanks for your response,
Kay

From list at satchell.net  Mon Jul 16 14:31:26 2018
From: list at satchell.net (Stephen Satchell)
Date: Mon, 16 Jul 2018 11:31:26 -0700
Subject: [code-quality] pylint 2.0 / astroid 2.0 released!
In-Reply-To: <CAMEZBD+meqjOifje8g8oEmPqsfTqCyyZOBMVR1zthMrQdDO+Dw@mail.gmail.com>
References: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
 <CAMEZBD+meqjOifje8g8oEmPqsfTqCyyZOBMVR1zthMrQdDO+Dw@mail.gmail.com>
Message-ID: <1e2caddf-bb77-d6f1-d287-fbcfb0c2cd9d@satchell.net>

On 07/16/2018 04:56 AM, Kay Hayen wrote:
> But I assume,
> you don't care about people who still care about Python2 code
> correctness and Python3 correctness at the same time? It
> must be a clear minority that I am in.

Hey, I'm finally in a minority.  I have a code base that has to remain
in Python 2, too.  The issue is included code (via PIP) which isn't
Python-3 safe yet.

From me at jamescooke.info  Mon Jul 16 16:30:18 2018
From: me at jamescooke.info (James Cooke)
Date: Mon, 16 Jul 2018 21:30:18 +0100
Subject: [code-quality] pylint-unittest plugin to detect less than
 optimal usage of assertions in your unittest usage
In-Reply-To: <CABKJOiy6mgTSZDH2CkK8Hz8xsK363j3SyY0+uSP9rW90u6iZpQ@mail.gmail.com>
References: <CABKJOiy6mgTSZDH2CkK8Hz8xsK363j3SyY0+uSP9rW90u6iZpQ@mail.gmail.com>
Message-ID: <1531773018.627530.1442758424.59220D45@webmail.messagingengine.com>

Hi Federico,

This looks like an interesting plugin - thanks for sharing! It's great to see tools that aim to improve the quality of tests (over and above regular linting).

Personally, I've moved away from Unittest to pytest so this plugin is not so relevant for my usual testing work. __But__ (as a bit of a TDD nut) I'm interested to know more about some of the issues you found getting TDD up and running for your build of the plugin... Could you share what aspects took you longer than expected or were problematic? Are there any places where you think community effort could be directed to help more people create plugins?

Cheers,

James




On Tue, 26 Jun 2018, at 11:15 PM, Federico Bond wrote:
> Hello,
> 
> I wrote a Pylint plugin to detect less than optimal usage of unittest
> assertions, for example writing self.assertEqual(x, None) instead of
> self.assertIsNone(x) or using deprecated aliases. It's published in
> PyPI under the name pylint-unittest and is also available on GitHub
> here:
> 
> https://github.com/federicobond/pylint-unittest
> 
> I would love to hear your feedback on it. Also, it took me longer than
> I expected to put together the necessary boilerplate for doing
> test-driven development on this plugin, so I hope it can serve as a
> good base for others too. I feel that the way pylint-django tests are
> structured is too awkward for newcomers.
> 
> Thank you!
> 
> Federico
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality

From kay.hayen at gmail.com  Tue Jul 17 03:32:13 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Tue, 17 Jul 2018 09:32:13 +0200
Subject: [code-quality] pylint 2.0 / astroid 2.0 released!
In-Reply-To: <1e2caddf-bb77-d6f1-d287-fbcfb0c2cd9d@satchell.net>
References: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
 <CAMEZBD+meqjOifje8g8oEmPqsfTqCyyZOBMVR1zthMrQdDO+Dw@mail.gmail.com>
 <1e2caddf-bb77-d6f1-d287-fbcfb0c2cd9d@satchell.net>
Message-ID: <CAMEZBD+xfJmdOy0-zBW=Rm=ds1upL2aQFy-Kug65zuG8SgJGkQ@mail.gmail.com>

Hello Stephen,

> > But I assume,
> > you don't care about people who still care about Python2 code
> > correctness and Python3 correctness at the same time? It
> > must be a clear minority that I am in.
>
> Hey, I'm finally in a minority.  I have a code base that has to remain
> in Python 2, too.  The issue is included code (via PIP) which isn't
> Python-3 safe yet.

But to be really in the minority, you have to run your code in Python2
and Python3 both.

And running PyLint for only Python3 wouldn't cut it, because testing
for Python2 regressions would burn through massive amounts of CPU.

I am almost thinking, that minority is just me. :)

Yours,
Kay

From kay.hayen at gmail.com  Tue Jul 17 03:38:13 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Tue, 17 Jul 2018 09:38:13 +0200
Subject: [code-quality] PyLint and Travis
Message-ID: <CAMEZBD+xn+YsE4xr6tgURiBOyujmiE5UqHQ7C8po=S7hyLPdtg@mail.gmail.com>

Hello there,

so I have added PyLint checks to travis. It nicely makes sure that PRs
I get submitted become clean.

However, for each PyLint release, e.g. 2.0.0, there will be a bunch of
findings that are new, and will to be found, leading to the Travis
builds to fail due to PyLint, all the time now.

How to approach that. Is there a way I could have enforced using 1.9.2
on the "master" branch for Travis (and probably "develop" too), and
use the latest greatest PyLint for "factory" only. Anyone know if that
is possible, somehow, anybody doing something like that? Or maybe
install a given version, but make it an error if that version is not
the most recent on only the factory branch, what are people doing in
this regard?

Yours,
Kay

From me at the-compiler.org  Tue Jul 17 03:44:05 2018
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 17 Jul 2018 09:44:05 +0200
Subject: [code-quality] PyLint and Travis
In-Reply-To: <CAMEZBD+xn+YsE4xr6tgURiBOyujmiE5UqHQ7C8po=S7hyLPdtg@mail.gmail.com>
References: <CAMEZBD+xn+YsE4xr6tgURiBOyujmiE5UqHQ7C8po=S7hyLPdtg@mail.gmail.com>
Message-ID: <20180717074405.cz3tkede7g7ithez@hooch.localdomain>

Hey,

On Tue, Jul 17, 2018 at 09:38:13AM +0200, Kay Hayen wrote:
> However, for each PyLint release, e.g. 2.0.0, there will be a bunch of
> findings that are new, and will to be found, leading to the Travis
> builds to fail due to PyLint, all the time now.
> 
> How to approach that. Is there a way I could have enforced using 1.9.2
> on the "master" branch for Travis (and probably "develop" too), and
> use the latest greatest PyLint for "factory" only. Anyone know if that
> is possible, somehow, anybody doing something like that? Or maybe
> install a given version, but make it an error if that version is not
> the most recent on only the factory branch, what are people doing in
> this regard?

You'd usually use requirements.txt files with exact version pinning -
ideally not only for pylint, but for all your dependencies and tools, to
ensure deterministic, reproducable results.

Then you can use https://requires.io/ or https://pyup.io/ to get
notifications (or pull requests) to periodically update the pinned
versions.

Florian

-- 
https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
         I love long mails! | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/code-quality/attachments/20180717/fdc9e23f/attachment.sig>

From pcmanticore at gmail.com  Tue Jul 17 04:50:23 2018
From: pcmanticore at gmail.com (Claudiu Popa)
Date: Tue, 17 Jul 2018 10:50:23 +0200
Subject: [code-quality] pylint 2.0 / astroid 2.0 released!
In-Reply-To: <CAMEZBD+xfJmdOy0-zBW=Rm=ds1upL2aQFy-Kug65zuG8SgJGkQ@mail.gmail.com>
References: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
 <CAMEZBD+meqjOifje8g8oEmPqsfTqCyyZOBMVR1zthMrQdDO+Dw@mail.gmail.com>
 <1e2caddf-bb77-d6f1-d287-fbcfb0c2cd9d@satchell.net>
 <CAMEZBD+xfJmdOy0-zBW=Rm=ds1upL2aQFy-Kug65zuG8SgJGkQ@mail.gmail.com>
Message-ID: <CAMy=CLpQV7=vNukqvgLoEs=UXaZKW5RYzrwRySWRp9DwmMScZQ@mail.gmail.com>

Hi,

Another alternative would be to pin pylint for now to 1.9
so that it works out of the box for both Python 2 and 3. Also
forgot to mention that we have plans to add support of linting
Python 2 files while the running interpreter is Python 3
but we didn't have enough time before release to implement
that: https://github.com/PyCQA/pylint/issues/2070. Once
we have that feature, you can just have pylint 2.X installed
and run it for both Python 2 and 3 linting.


On 17 July 2018 at 09:32, Kay Hayen <kay.hayen at gmail.com> wrote:
> Hello Stephen,
>
>> > But I assume,
>> > you don't care about people who still care about Python2 code
>> > correctness and Python3 correctness at the same time? It
>> > must be a clear minority that I am in.
>>
>> Hey, I'm finally in a minority.  I have a code base that has to remain
>> in Python 2, too.  The issue is included code (via PIP) which isn't
>> Python-3 safe yet.
>
> But to be really in the minority, you have to run your code in Python2
> and Python3 both.
>
> And running PyLint for only Python3 wouldn't cut it, because testing
> for Python2 regressions would burn through massive amounts of CPU.
>
> I am almost thinking, that minority is just me. :)
>
> Yours,
> Kay
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality

From kay.hayen at gmail.com  Tue Jul 17 05:06:37 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Tue, 17 Jul 2018 11:06:37 +0200
Subject: [code-quality] pylint 2.0 / astroid 2.0 released!
In-Reply-To: <CAMy=CLpQV7=vNukqvgLoEs=UXaZKW5RYzrwRySWRp9DwmMScZQ@mail.gmail.com>
References: <CAMy=CLpwGn3Ts40hUU+01MRCap-21vOEdZ3PzJbG9p86GOCjYw@mail.gmail.com>
 <CAMEZBD+meqjOifje8g8oEmPqsfTqCyyZOBMVR1zthMrQdDO+Dw@mail.gmail.com>
 <1e2caddf-bb77-d6f1-d287-fbcfb0c2cd9d@satchell.net>
 <CAMEZBD+xfJmdOy0-zBW=Rm=ds1upL2aQFy-Kug65zuG8SgJGkQ@mail.gmail.com>
 <CAMy=CLpQV7=vNukqvgLoEs=UXaZKW5RYzrwRySWRp9DwmMScZQ@mail.gmail.com>
Message-ID: <CAMEZBDLLmiConq57p5gotgAvMx7YA0qWDyQk-VmnLQ87JJapCA@mail.gmail.com>

Hello Claudiu,

> Also
> forgot to mention that we have plans to add support of linting
> Python 2 files while the running interpreter is Python 3
> but we didn't have enough time before release to implement
> that: https://github.com/PyCQA/pylint/issues/2070. Once
> we have that feature, you can just have pylint 2.X installed
> and run it for both Python 2 and 3 linting.

That's great, thanks for going there. Subscribed to the issue. That
will solve all the
problems for me. I hope somebody tackles it. But just to be clear. I
totally get it if
it were not to happen.

For Nuitka I have chosen to run with the language version that I compile, so run
time computations need not be abstracted. One idea I had was to have a slave
Python interpreter on the target OS, target Python version, that does
part of the
work, e.g. "1+2L", while also caching results. So far, this has proven
too crazy,
but would enable cross compilation maybe.

Not sure how much compile time computations PyLint does. I assume it is quite
a lot.

Yours,
Kay

From kay.hayen at gmail.com  Wed Jul 18 03:01:39 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Wed, 18 Jul 2018 09:01:39 +0200
Subject: [code-quality] PyLint and Travis
In-Reply-To: <20180717074405.cz3tkede7g7ithez@hooch.localdomain>
References: <CAMEZBD+xn+YsE4xr6tgURiBOyujmiE5UqHQ7C8po=S7hyLPdtg@mail.gmail.com>
 <20180717074405.cz3tkede7g7ithez@hooch.localdomain>
Message-ID: <CAMEZBDLXCCUKaa3MD8tAnaLTHoezeOPmx1cAYz0QjLV03KrisA@mail.gmail.com>

Hello Florian,

thanks for your reply.

> > How to approach that. Is there a way I could have enforced using 1.9.2
> > on the "master" branch for Travis (and probably "develop" too), and
> > use the latest greatest PyLint for "factory" only. Anyone know if that
> > is possible, somehow, anybody doing something like that? Or maybe
> > install a given version, but make it an error if that version is not
> > the most recent on only the factory branch, what are people doing in
> > this regard?
>
> You'd usually use requirements.txt files with exact version pinning -
> ideally not only for pylint, but for all your dependencies and tools, to
> ensure deterministic, reproducable results.
>
> Then you can use https://requires.io/ or https://pyup.io/ to get
> notifications (or pull requests) to periodically update the pinned
> versions.

That sounds very nice. But you wouldn't normally put pylint into
the standard requirements, would you, so you would have a dedicated,
separate requirement file for it, to use with these services?

Right now, I am using on inline copies of scons which are used on
platforms where apt-get install scons won't work. And I the same with
appdirs. So I have no need yet for such files.

I just added one with PyLint now, before I was doing this in the install
second of Travis: python -c 'import sys;exit(sys.version_info[:2] not
in ((2,6), (3,3), (3,6)))' || pip install pylint

I blacklisted 3.6 for an error message that was not reproducible
outside of Travis. Obviously that was with
no 2.x version of PyLint. With pip syntax this might be more easily
expressed and commented too. This is
what I am trying right now:

# PyLint wouldn't be installable on 2.6 and not work with 3.3
pylint == 1.9.2 ; python_version < '2.7'
pylint == 2.0.0 ; python_version >= '3.4'

That approach of externally having these checked, makes sense to me
however. And I will
use a "requirements.txt" for for optional requirements too now. Nuitka
will just happen to work
without them installed too. Getting those notifications and even PRs
seems fine by me.

Yours,
Kay

From me at the-compiler.org  Wed Jul 18 03:47:42 2018
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 18 Jul 2018 09:47:42 +0200
Subject: [code-quality] PyLint and Travis
In-Reply-To: <CAMEZBDLXCCUKaa3MD8tAnaLTHoezeOPmx1cAYz0QjLV03KrisA@mail.gmail.com>
References: <CAMEZBD+xn+YsE4xr6tgURiBOyujmiE5UqHQ7C8po=S7hyLPdtg@mail.gmail.com>
 <20180717074405.cz3tkede7g7ithez@hooch.localdomain>
 <CAMEZBDLXCCUKaa3MD8tAnaLTHoezeOPmx1cAYz0QjLV03KrisA@mail.gmail.com>
Message-ID: <20180718074742.4ps2vioq5at4pxrx@hooch.localdomain>

On Wed, Jul 18, 2018 at 09:01:39AM +0200, Kay Hayen wrote:
> Hello Florian,
> 
> thanks for your reply.
> 
> > > How to approach that. Is there a way I could have enforced using 1.9.2
> > > on the "master" branch for Travis (and probably "develop" too), and
> > > use the latest greatest PyLint for "factory" only. Anyone know if that
> > > is possible, somehow, anybody doing something like that? Or maybe
> > > install a given version, but make it an error if that version is not
> > > the most recent on only the factory branch, what are people doing in
> > > this regard?
> >
> > You'd usually use requirements.txt files with exact version pinning -
> > ideally not only for pylint, but for all your dependencies and tools, to
> > ensure deterministic, reproducable results.
> >
> > Then you can use https://requires.io/ or https://pyup.io/ to get
> > notifications (or pull requests) to periodically update the pinned
> > versions.
> 
> That sounds very nice. But you wouldn't normally put pylint into
> the standard requirements, would you, so you would have a dedicated,
> separate requirement file for it, to use with these services?

I often see a requirements.txt (with runtime dependencies) and a
requirements-dev.txt (with test runners, linters, etc.) in projects.

I personally like to go even further and have one requirements file for
every job on Travis (i.e. tests/pylint/flake8/...):
https://github.com/qutebrowser/qutebrowser/tree/master/misc/requirements

I also have a script to automatically rebuild them, but you're probably
not going to need that if you just rely in pyup/requires.io:
https://github.com/qutebrowser/qutebrowser/blob/master/scripts/dev/recompile_requirements.py

Florian

-- 
https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
         I love long mails! | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/code-quality/attachments/20180718/40df92fe/attachment.sig>

From kay.hayen at gmail.com  Wed Jul 18 09:32:55 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Wed, 18 Jul 2018 15:32:55 +0200
Subject: [code-quality] PyLint and Travis
In-Reply-To: <20180718074742.4ps2vioq5at4pxrx@hooch.localdomain>
References: <CAMEZBD+xn+YsE4xr6tgURiBOyujmiE5UqHQ7C8po=S7hyLPdtg@mail.gmail.com>
 <20180717074405.cz3tkede7g7ithez@hooch.localdomain>
 <CAMEZBDLXCCUKaa3MD8tAnaLTHoezeOPmx1cAYz0QjLV03KrisA@mail.gmail.com>
 <20180718074742.4ps2vioq5at4pxrx@hooch.localdomain>
Message-ID: <CAMEZBD+eBB+m3Jd4rEGU_Wn7=w6Dhvy-Cd8Q56xs+Yp5D_eXfw@mail.gmail.com>

Hello Florian,

> > That sounds very nice. But you wouldn't normally put pylint into
> > the standard requirements, would you, so you would have a dedicated,
> > separate requirement file for it, to use with these services?
>
> I often see a requirements.txt (with runtime dependencies) and a
> requirements-dev.txt (with test runners, linters, etc.) in projects.

So I went with that approach, which requires.io also supported out of
the box, very nice.

> I personally like to go even further and have one requirements file for
> every job on Travis (i.e. tests/pylint/flake8/...):
> https://github.com/qutebrowser/qutebrowser/tree/master/misc/requirements

Yes, sparing resources for them by specializing totally makes sense. I
only have one job, but for all Python versions there, and I think I
should have one dedicated for Travis, so I can add "redbaron" to
development without making Travis download stuff not needed by it.
These files can include one another as I have seen, so no duplication
needed.

Anyway, thanks for the input. I had read of these things, but never
realized I should have the issue myself.

Yours,
Kay

From federico.bond at gmail.com  Mon Jul 16 18:30:00 2018
From: federico.bond at gmail.com (Federico Bond)
Date: Mon, 16 Jul 2018 19:30:00 -0300
Subject: [code-quality] pylint-unittest plugin to detect less than
 optimal usage of assertions in your unittest usage
In-Reply-To: <1531773018.627530.1442758424.59220D45@webmail.messagingengine.com>
References: <CABKJOiy6mgTSZDH2CkK8Hz8xsK363j3SyY0+uSP9rW90u6iZpQ@mail.gmail.com>
 <1531773018.627530.1442758424.59220D45@webmail.messagingengine.com>
Message-ID: <CABKJOizoO_jEQVMAMyxMmaMB5aZT3qshXTFMdgxoxFHtLuWixA@mail.gmail.com>

Thanks James! From what I recall, one thing that tripped me up is
that pytest is never mentioned in the docs for writing a checker/plugin,
despite being required by the Pylint test framework. But mostly it was the
lack of examples for how to set everything up beyond what's mentioned in
the docs.

A clean boilerplate for pylint plugin development would have come super
handy, because pylint-django does things quite differently.

On Mon, Jul 16, 2018 at 5:30 PM James Cooke <me at jamescooke.info> wrote:

> Hi Federico,
>
> This looks like an interesting plugin - thanks for sharing! It's great to
> see tools that aim to improve the quality of tests (over and above regular
> linting).
>
> Personally, I've moved away from Unittest to pytest so this plugin is not
> so relevant for my usual testing work. __But__ (as a bit of a TDD nut) I'm
> interested to know more about some of the issues you found getting TDD up
> and running for your build of the plugin... Could you share what aspects
> took you longer than expected or were problematic? Are there any places
> where you think community effort could be directed to help more people
> create plugins?
>
> Cheers,
>
> James
>
>
>
>
> On Tue, 26 Jun 2018, at 11:15 PM, Federico Bond wrote:
> > Hello,
> >
> > I wrote a Pylint plugin to detect less than optimal usage of unittest
> > assertions, for example writing self.assertEqual(x, None) instead of
> > self.assertIsNone(x) or using deprecated aliases. It's published in
> > PyPI under the name pylint-unittest and is also available on GitHub
> > here:
> >
> > https://github.com/federicobond/pylint-unittest
> >
> > I would love to hear your feedback on it. Also, it took me longer than
> > I expected to put together the necessary boilerplate for doing
> > test-driven development on this plugin, so I hope it can serve as a
> > good base for others too. I feel that the way pylint-django tests are
> > structured is too awkward for newcomers.
> >
> > Thank you!
> >
> > Federico
> > _______________________________________________
> > 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: <http://mail.python.org/pipermail/code-quality/attachments/20180716/fecb70d4/attachment.html>

From kay.hayen at gmail.com  Sun Jul 22 04:10:45 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Sun, 22 Jul 2018 10:10:45 +0200
Subject: [code-quality] Astroid 2.0.1 vs 2.0.0 changes PyLint
Message-ID: <CAMEZBD+iYDoggtNnGpt26qmudaAsSwU0Jj366FR3K4iKhfzm1A@mail.gmail.com>

Hello there,

I think this is not the first time this has happened to me. I am
running PyLint on Travis, and as of recently, I fixed the PyLint
version to be ==2.0.0 which is still up to date. However, now it
installs Astroid 2.0.1 which causes this:


nuitka/nodes/NodeBases.py:273 E0237 assigning-non-slot
NodeBase.setCompatibleSourceReference Assigning to attribute
'effective_source_ref' not defined in class slots
nuitka/nodes/NodeBases.py:272 I0021 useless-suppression  Useless
suppression of 'attribute-defined-outside-init'

The name or kind of message that PyLint outputs changed here it seems.

Plus I am getting what I consider a false alarm:

nuitka/Errors.py:37 E1133 not-an-iterable NuitkaNodeError.__str__
Non-iterable value self.args is used in an iterating context

This is self.args from Exception, as can be seen in the code here:

class NuitkaErrorBase(Exception):
    pass


class NuitkaNodeError(NuitkaErrorBase):

    # Try to output more information about nodes passed.
    def __str__(self):
        from nuitka.codegen.Indentation import indented

        parts = [""]

        for arg in self.args:
            if hasattr(arg, "asXmlText"):
                parts.append(indented("\n%s\n" % arg.asXmlText()))
            else:
                parts.append(arg)

        parts.append("")
        parts.append("The above information should be included in a
bug report.")

        return '\n'.join(parts)

And then another regression:

nuitka/nodes/NodeMetaClasses.py:66 E1121 too-many-function-args
NodeCheckMetaClass.__new__ Too many positional arguments for
classmethod call

for this:
    return ABCMeta.__new__(cls, name, bases, dictionary)

But my question basically it, do I need to also fixate the astroid
version, so that I can be sure that a PyLint 2.0.0 is behaving like
another PyLint 2.0.0 ? This has been driving me nuts this morning,
sort of.

Yours,
Kay

From kay.hayen at gmail.com  Sun Jul 22 04:16:04 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Sun, 22 Jul 2018 10:16:04 +0200
Subject: [code-quality] Astroid 2.0.1 vs 2.0.0 changes PyLint
In-Reply-To: <CAMEZBD+iYDoggtNnGpt26qmudaAsSwU0Jj366FR3K4iKhfzm1A@mail.gmail.com>
References: <CAMEZBD+iYDoggtNnGpt26qmudaAsSwU0Jj366FR3K4iKhfzm1A@mail.gmail.com>
Message-ID: <CAMEZBDKDcmDZcMMVS73ypx9KGvPGTgxdQ2D0ST2miaW7kBefgQ@mail.gmail.com>

Hello there,

> nuitka/nodes/NodeBases.py:273 E0237 assigning-non-slot
> NodeBase.setCompatibleSourceReference Assigning to attribute
> 'effective_source_ref' not defined in class slots
> nuitka/nodes/NodeBases.py:272 I0021 useless-suppression  Useless
> suppression of 'attribute-defined-outside-init'

The code of mine does this as of recently:

    __slots__ = "parent", "source_ref"

    # Avoid the attribute unless it's really necessary.
    if Options.isFullCompat():
        __slots__ += ("effective_source_ref",)

That saves a bunch of memory. Basically I have an optional slot, that
is only assigned when necessary, when Nuitka is run in a non-default
mode used for testing.

But PyLint now goes with the first slot declaration and complains. So
that is a bug in a new feature or a regression.

Yours,
Kay

From pcmanticore at gmail.com  Sun Jul 22 11:57:56 2018
From: pcmanticore at gmail.com (Claudiu Popa)
Date: Sun, 22 Jul 2018 17:57:56 +0200
Subject: [code-quality] Astroid 2.0.1 vs 2.0.0 changes PyLint
In-Reply-To: <CAMEZBDKDcmDZcMMVS73ypx9KGvPGTgxdQ2D0ST2miaW7kBefgQ@mail.gmail.com>
References: <CAMEZBD+iYDoggtNnGpt26qmudaAsSwU0Jj366FR3K4iKhfzm1A@mail.gmail.com>
 <CAMEZBDKDcmDZcMMVS73ypx9KGvPGTgxdQ2D0ST2miaW7kBefgQ@mail.gmail.com>
Message-ID: <CAMy=CLr-4Gjb=rR==v8auzKymvVcHOqjsZ8Xfvdh4RkU22D6qA@mail.gmail.com>

Hi Kay,

The 2.0 vs 2.0.1 problem you're experiencing with astroid was a
problem with the 2.0 release. Due to a mistake in the release process,
the wheel for 2.0 was in fact the last dev release of astroid. The .tar.gz
sdist though was containing the actual 2.0 code. Not sure how
the dev release got to be marked as 2.0 but only for the wheel file,
but we added some additional documentation in the release process
to ensure this doesn't happen again (although ideally we'd move
the release to be an automatic process rather than manual as it is now)

For the other issues, I suggest opening separate issues on the bug tracker
since otherwise they can get lost here.

Sorry for the trouble.

Cheers,
Claudiu



On 22 July 2018 at 10:16, Kay Hayen <kay.hayen at gmail.com> wrote:
> Hello there,
>
>> nuitka/nodes/NodeBases.py:273 E0237 assigning-non-slot
>> NodeBase.setCompatibleSourceReference Assigning to attribute
>> 'effective_source_ref' not defined in class slots
>> nuitka/nodes/NodeBases.py:272 I0021 useless-suppression  Useless
>> suppression of 'attribute-defined-outside-init'
>
> The code of mine does this as of recently:
>
>     __slots__ = "parent", "source_ref"
>
>     # Avoid the attribute unless it's really necessary.
>     if Options.isFullCompat():
>         __slots__ += ("effective_source_ref",)
>
> That saves a bunch of memory. Basically I have an optional slot, that
> is only assigned when necessary, when Nuitka is run in a non-default
> mode used for testing.
>
> But PyLint now goes with the first slot declaration and complains. So
> that is a bug in a new feature or a regression.
>
> Yours,
> Kay
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality

From kay.hayen at gmail.com  Mon Jul 23 02:45:45 2018
From: kay.hayen at gmail.com (Kay Hayen)
Date: Mon, 23 Jul 2018 08:45:45 +0200
Subject: [code-quality] Astroid 2.0.1 vs 2.0.0 changes PyLint
In-Reply-To: <CAMy=CLr-4Gjb=rR==v8auzKymvVcHOqjsZ8Xfvdh4RkU22D6qA@mail.gmail.com>
References: <CAMEZBD+iYDoggtNnGpt26qmudaAsSwU0Jj366FR3K4iKhfzm1A@mail.gmail.com>
 <CAMEZBDKDcmDZcMMVS73ypx9KGvPGTgxdQ2D0ST2miaW7kBefgQ@mail.gmail.com>
 <CAMy=CLr-4Gjb=rR==v8auzKymvVcHOqjsZ8Xfvdh4RkU22D6qA@mail.gmail.com>
Message-ID: <CAMEZBDK5UzhiQ7qGaev1amVVFMkpc3DT_Ryc1WvjDtAjJh2zQw@mail.gmail.com>

Hello Claudiu,

> The 2.0 vs 2.0.1 problem you're experiencing with astroid was a
> problem with the 2.0 release. Due to a mistake in the release process,
> the wheel for 2.0 was in fact the last dev release of astroid. The .tar.gz
> sdist though was containing the actual 2.0 code. Not sure how
> the dev release got to be marked as 2.0 but only for the wheel file,
> but we added some additional documentation in the release process
> to ensure this doesn't happen again (although ideally we'd move
> the release to be an automatic process rather than manual as it is now)
>
> For the other issues, I suggest opening separate issues on the bug tracker
> since otherwise they can get lost here.

First of all, shit happens, and not a huge problem of course. I have
done similar. Automation is fine, but not necessary less error prone.
My static web site deployment
e.g. managed to revert to 2 years old site due to a wrongly set RTC
clock, turning all of 2 years of posts into drafts. But it it is less
work, and you got a machine to
blame. ;-)

I was mainly wondering if Astroid had an independent release process.
And I was wondering if there shouldn't have been a 2.0.1 release then
for PyLint too.

What's bound to be happening is that lots of people have "pylint"
latest installed, but not the real thing. And nothing can make them
notice.

A bump of version on PyPI would be nice, not sure if you want to go
2.0.1 there too, might be used in your roadmap thinking already, or of
2.0.0a is even allowed anymore these days.

I was of course going to report the issues to the bug tracker and just
did. Unfortunately it also indicates that it's not a minor thing, that
is changed, like a forgotten version bump,
clearly more is in there missing for people who installed it during
the time the wheel was not updated.

Yours,
Kay

From pcmanticore at gmail.com  Mon Jul 23 03:34:17 2018
From: pcmanticore at gmail.com (Claudiu Popa)
Date: Mon, 23 Jul 2018 09:34:17 +0200
Subject: [code-quality] Astroid 2.0.1 vs 2.0.0 changes PyLint
In-Reply-To: <CAMEZBDK5UzhiQ7qGaev1amVVFMkpc3DT_Ryc1WvjDtAjJh2zQw@mail.gmail.com>
References: <CAMEZBD+iYDoggtNnGpt26qmudaAsSwU0Jj366FR3K4iKhfzm1A@mail.gmail.com>
 <CAMEZBDKDcmDZcMMVS73ypx9KGvPGTgxdQ2D0ST2miaW7kBefgQ@mail.gmail.com>
 <CAMy=CLr-4Gjb=rR==v8auzKymvVcHOqjsZ8Xfvdh4RkU22D6qA@mail.gmail.com>
 <CAMEZBDK5UzhiQ7qGaev1amVVFMkpc3DT_Ryc1WvjDtAjJh2zQw@mail.gmail.com>
Message-ID: <CAMy=CLob62YgB+-vRYrwPdk5ZDaVF9ST37bqoN5u169Nh1kvZg@mail.gmail.com>

Hi Kay,

Astroid pretty much has an independent release process,
but when necessary we release them both together, for instance
when the API of astroid changes or when there's an important
bug fix that all pylint users should have.

I just bumped pylint to 2.0.1 as well, which includes a fix for a crash
that was occurring when inferring `next()`. It also bumps the dependency
of astroid to 2.0.1 so this should clear the installations that still uses
the dev release of astroid.

Thanks for creating those issues! I took a look at a couple of them and
they seem genuine bugs.

Thanks again!
Claudiu

On 23 July 2018 at 08:45, Kay Hayen <kay.hayen at gmail.com> wrote:
> Hello Claudiu,
>
>> The 2.0 vs 2.0.1 problem you're experiencing with astroid was a
>> problem with the 2.0 release. Due to a mistake in the release process,
>> the wheel for 2.0 was in fact the last dev release of astroid. The .tar.gz
>> sdist though was containing the actual 2.0 code. Not sure how
>> the dev release got to be marked as 2.0 but only for the wheel file,
>> but we added some additional documentation in the release process
>> to ensure this doesn't happen again (although ideally we'd move
>> the release to be an automatic process rather than manual as it is now)
>>
>> For the other issues, I suggest opening separate issues on the bug tracker
>> since otherwise they can get lost here.
>
> First of all, shit happens, and not a huge problem of course. I have
> done similar. Automation is fine, but not necessary less error prone.
> My static web site deployment
> e.g. managed to revert to 2 years old site due to a wrongly set RTC
> clock, turning all of 2 years of posts into drafts. But it it is less
> work, and you got a machine to
> blame. ;-)
>
> I was mainly wondering if Astroid had an independent release process.
> And I was wondering if there shouldn't have been a 2.0.1 release then
> for PyLint too.
>
> What's bound to be happening is that lots of people have "pylint"
> latest installed, but not the real thing. And nothing can make them
> notice.
>
> A bump of version on PyPI would be nice, not sure if you want to go
> 2.0.1 there too, might be used in your roadmap thinking already, or of
> 2.0.0a is even allowed anymore these days.
>
> I was of course going to report the issues to the bug tracker and just
> did. Unfortunately it also indicates that it's not a minor thing, that
> is changed, like a forgotten version bump,
> clearly more is in there missing for people who installed it during
> the time the wheel was not updated.
>
> Yours,
> Kay

From atodorov at mrsenko.com  Tue Jul 24 17:23:30 2018
From: atodorov at mrsenko.com (Alexander Todorov)
Date: Wed, 25 Jul 2018 00:23:30 +0300
Subject: [code-quality] Need help with strange test failure for pylint-django
Message-ID: <f300b797-bfc8-074a-8403-355bc1acff0e@mrsenko.com>

Hi folks,
I need help debugging a strange test failure in pylint-django that started 
happening after the upgrade to pylint/astroid 2.0.

For all I can tell we've already adjusted the code and this failure is happening 
randomly. pylint-django's test used uses the test_functional.LintModuleTest 
class from pylint (I know it isn't public interface) and executes against input 
files comparing the linter results with expected.

The error that we get is:

E           Failed: Wrong results for file "func_noerror_foreignkeys":
E
E           Unexpected in testdata:
E             27: no-member

The strange thing is that on one test job in Travis this passed with Python 3.4 
and Django 2.0 (see job #447.3):
https://travis-ci.org/PyCQA/pylint-django/builds/407129036

and on the next commit this failed on Python 3.4/Django 2.0 (see #448.3):
https://travis-ci.org/PyCQA/pylint-django/builds/407800899

however it passed on 3.5 + Django 2.0.

The two test jobs use the same code (minor differences in commits due to 
squash/conflicts).

When the linter is executed manually against the offending file it produces a 
10/10 score.


If I modify the test suite like so:

--- a/pylint_django/tests/test_func.py
+++ b/pylint_django/tests/test_func.py
@@ -43,6 +43,8 @@ def get_tests(input_dir='input', sort=False):

      suite = []
      for fname in os.listdir(input_dir):
+        if fname.find('func_noerror_foreign') == -1:
+            continue
          if fname != '__init__.py' and fname.endswith('.py'):
              suite.append(test_functional.FunctionalTestFile(input_dir, fname))

then I get only a subset of the tests executed (including the offending one) and 
this time it passes.


Anyone seen such erratic behaviour ?  I think this is a flaky test but I have no 
idea how to approach debugging that.


For the record this is blocking us from releasing a new version of pylint-django 
so any help is appreciated.

--
Alex


From me at jamescooke.info  Wed Jul 25 11:16:37 2018
From: me at jamescooke.info (James Cooke)
Date: Wed, 25 Jul 2018 16:16:37 +0100
Subject: [code-quality] Need help with strange test failure for
 pylint-django
In-Reply-To: <f300b797-bfc8-074a-8403-355bc1acff0e@mrsenko.com>
References: <f300b797-bfc8-074a-8403-355bc1acff0e@mrsenko.com>
Message-ID: <1532531797.1656665.1452567816.598E9F90@webmail.messagingengine.com>

Update for those interested, the solution is here with explanation: https://github.com/PyCQA/pylint-django/pull/183/commits/538546044ac5a9785dc85369394d2de8c78349fc

Cheers,

James



On Tue, 24 Jul 2018, at 10:23 PM, Alexander Todorov wrote:
> Hi folks,
> I need help debugging a strange test failure in pylint-django that started 
> happening after the upgrade to pylint/astroid 2.0.
> 
> For all I can tell we've already adjusted the code and this failure is 
> happening 
> randomly. pylint-django's test used uses the 
> test_functional.LintModuleTest 
> class from pylint (I know it isn't public interface) and executes 
> against input 
> files comparing the linter results with expected.
> 
> The error that we get is:
> 
> E           Failed: Wrong results for file "func_noerror_foreignkeys":
> E
> E           Unexpected in testdata:
> E             27: no-member
> 
> The strange thing is that on one test job in Travis this passed with Python 3.4 
> and Django 2.0 (see job #447.3):
> https://travis-ci.org/PyCQA/pylint-django/builds/407129036
> 
> and on the next commit this failed on Python 3.4/Django 2.0 (see #448.3):
> https://travis-ci.org/PyCQA/pylint-django/builds/407800899
> 
> however it passed on 3.5 + Django 2.0.
> 
> The two test jobs use the same code (minor differences in commits due to 
> squash/conflicts).
> 
> When the linter is executed manually against the offending file it produces a 
> 10/10 score.
> 
> 
> If I modify the test suite like so:
> 
> --- a/pylint_django/tests/test_func.py
> +++ b/pylint_django/tests/test_func.py
> @@ -43,6 +43,8 @@ def get_tests(input_dir='input', sort=False):
> 
>       suite = []
>       for fname in os.listdir(input_dir):
> +        if fname.find('func_noerror_foreign') == -1:
> +            continue
>           if fname != '__init__.py' and fname.endswith('.py'):
>               suite.append(test_functional.FunctionalTestFile(input_dir, fname))
> 
> then I get only a subset of the tests executed (including the offending 
> one) and 
> this time it passes.
> 
> 
> Anyone seen such erratic behaviour ?  I think this is a flaky test but I 
> have no 
> idea how to approach debugging that.
> 
> 
> For the record this is blocking us from releasing a new version of 
> pylint-django 
> so any help is appreciated.
> 
> --
> Alex
> 
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality