From sylvain.thenault at logilab.fr  Mon Dec  2 10:07:23 2013
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Mon, 2 Dec 2013 10:07:23 +0100
Subject: [code-quality] Compatibility question
In-Reply-To: <6610AECCD68CAF4DB5A8FB337ADCD62907552DB3@SACMBXIP02.sdcorp.global.sandisk.com>
References: <6610AECCD68CAF4DB5A8FB337ADCD62907552DB3@SACMBXIP02.sdcorp.global.sandisk.com>
Message-ID: <20131202090723.GB2640@logilab.fr>

On 29 novembre 12:02, Ron Burnett wrote:
> Sir/Madam

Hi,
 
> I am interested in determining whether asteroid 1.0.1 can be installed via the command:
> 
> python setup.py install
> 
> when you are using python 2.4?

no, pylint/astroid are not compatible with python < 2.5 (and even 2.5 is known
to be broken, but that should be easily fixable).

-- 
Sylvain Th?nault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, M?th. Agiles: http://www.logilab.fr/formations
D?veloppement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

From laurent at bachelier.name  Wed Dec 11 17:59:22 2013
From: laurent at bachelier.name (Laurent Bachelier)
Date: Wed, 11 Dec 2013 17:59:22 +0100
Subject: [code-quality] pyflakes development dead again?
Message-ID: <52A899EA.4000900@bachelier.name>

It's been 5 months since the last commit on
https://github.com/pyflakes/pyflakes and the critical bugs are starting
to pile up.

From patrick at qumulo.com  Mon Dec 23 06:22:41 2013
From: patrick at qumulo.com (Patrick Jakubowski)
Date: Sun, 22 Dec 2013 21:22:41 -0800
Subject: [code-quality] pylint: disable for too-many-lines must go on first
	line of module?
Message-ID: <BED75F24-D9C9-4EE0-8391-98D3DC29E4FA@qumulo.com>

Hi all,

I'm upgrading from pylint 0.27.0 to 1.0.0 in my company's code base and I've run into a bit of an issue. For several of our modules, we use 'pylint: disable=C0302', to disable the too-many-lines error for the module. In pylint 0.26 this worked just fine as long as we put the line somewhere at the top of the module before any imports, like so:

#! /usr/bin/env python
# pylint: disable=C0302
<rest of code>

However, after upgrading to 1.0.0 it seems that the disable comment for C0302 HAS to go on the first line. This gets awkward because one has to mix it with the shebang line, like so:

#! /usr/bin/env python # pylint: disable=C0302
<rest of code>

I have a feeling that this will be difficult and awkward for other developers in our code base to figure out. It's also very strange because module-wide suppression of other errors (e.g. W0223) continue to work even if they are not on the very first line. Is this a bug or is there some other way to accomplish a module-wide suppression of C0302 without mixing it with the shebang?

Thanks,
Patrick Jakubowski

From graffatcolmingov at gmail.com  Tue Dec 24 21:10:48 2013
From: graffatcolmingov at gmail.com (Ian Cordasco)
Date: Tue, 24 Dec 2013 14:10:48 -0600
Subject: [code-quality] pylint: disable for too-many-lines must go on
 first line of module?
In-Reply-To: <BED75F24-D9C9-4EE0-8391-98D3DC29E4FA@qumulo.com>
References: <BED75F24-D9C9-4EE0-8391-98D3DC29E4FA@qumulo.com>
Message-ID: <CAN-Kwu1DqOWzCYV36KkhpFim0744iMp=LkgTEWqQnUBBa-GD5g@mail.gmail.com>

Sorry this took so long to get through moderation Patrick. In the
future, if you're on the list you can post to it.

On Sun, Dec 22, 2013 at 11:22 PM, Patrick Jakubowski <patrick at qumulo.com> wrote:
> Hi all,
>
> I'm upgrading from pylint 0.27.0 to 1.0.0 in my company's code base and I've run into a bit of an issue. For several of our modules, we use 'pylint: disable=C0302', to disable the too-many-lines error for the module. In pylint 0.26 this worked just fine as long as we put the line somewhere at the top of the module before any imports, like so:
>
> #! /usr/bin/env python
> # pylint: disable=C0302
> <rest of code>
>
> However, after upgrading to 1.0.0 it seems that the disable comment for C0302 HAS to go on the first line. This gets awkward because one has to mix it with the shebang line, like so:
>
> #! /usr/bin/env python # pylint: disable=C0302
> <rest of code>
>
> I have a feeling that this will be difficult and awkward for other developers in our code base to figure out. It's also very strange because module-wide suppression of other errors (e.g. W0223) continue to work even if they are not on the very first line. Is this a bug or is there some other way to accomplish a module-wide suppression of C0302 without mixing it with the shebang?
>
> Thanks,
> Patrick Jakubowski
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality