From sylvain.thenault at logilab.fr  Mon Jan  6 12:07:54 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Mon, 6 Jan 2014 12:07:54 +0100
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: <20140106110754.GB3458@logilab.fr>

On 22 d?cembre 21:22, Patrick Jakubowski wrote:
> Hi all,

Hi Patrick,
 
> 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?

this sounds like a regression to me. Did you open an issue on the Bitbucket's
tracker ? (https://bitbucket.org/logilab/pylint/issues)

-- 
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 kay.hayen at gmail.com  Sun Jan 12 15:57:04 2014
From: kay.hayen at gmail.com (Kay Hayen)
Date: Sun, 12 Jan 2014 15:57:04 +0100
Subject: [code-quality] pylint: Else clause on a loop without break statement
Message-ID: <52D2AD40.9080409@gmail.com>


Hello,

often I write code like this:

def _areConstants(expressions):
     for expression in expressions:
         if not expression.isExpressionConstantRef():
             return False

         if expression.isMutable():
             return False
     else:
         return True

That is to search in an iterable, and return based on finding something, 
or returning in the alternative, I specifically prefer the "else:" 
branch over merely putting it after the "for" loop.

This triggers the above message, which I consider flawed, because as 
soon as there is a "raise", or "return", that should be good enough as 
well. Basically any aborting statement, not only break.

I wanted to hear your opinion on this, pylint bug, or only in my mind.

Yours,
Kay

From graffatcolmingov at gmail.com  Sun Jan 12 16:12:17 2014
From: graffatcolmingov at gmail.com (Ian Cordasco)
Date: Sun, 12 Jan 2014 09:12:17 -0600
Subject: [code-quality] pylint: Else clause on a loop without break
	statement
In-Reply-To: <52D2AD40.9080409@gmail.com>
References: <52D2AD40.9080409@gmail.com>
Message-ID: <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>

I don't see any mesage from pylint in your email, could you post it again?

Regardless, I think what you're disagreeing with is the language
specification. The documentation specifies that the `else` is only
triggered on breaks:
http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops

On Sun, Jan 12, 2014 at 8:57 AM, Kay Hayen <kay.hayen at gmail.com> wrote:
>
> Hello,
>
> often I write code like this:
>
> def _areConstants(expressions):
>     for expression in expressions:
>         if not expression.isExpressionConstantRef():
>             return False
>
>         if expression.isMutable():
>             return False
>     else:
>         return True
>
> That is to search in an iterable, and return based on finding something, or
> returning in the alternative, I specifically prefer the "else:" branch over
> merely putting it after the "for" loop.
>
> This triggers the above message, which I consider flawed, because as soon as
> there is a "raise", or "return", that should be good enough as well.
> Basically any aborting statement, not only break.
>
> I wanted to hear your opinion on this, pylint bug, or only in my mind.
>
> Yours,
> Kay
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality

From carl.crowder at gmail.com  Sun Jan 12 16:13:03 2014
From: carl.crowder at gmail.com (Carl Crowder)
Date: Sun, 12 Jan 2014 16:13:03 +0100
Subject: [code-quality] pylint: Else clause on a loop without break
	statement
In-Reply-To: <52D2AD40.9080409@gmail.com>
References: <52D2AD40.9080409@gmail.com>
Message-ID: <CAK2BMQvGAK_D4V63ebTS3u+iJ4TZn5VWt11onb6_eR8L362kRw@mail.gmail.com>

This came up once before, and I think the reasoning is that a for loop
without a break statement means the 'else' is redundant.

In your example, you can remove the 'else' and it would be functionally the
same.


On 12 January 2014 15:57, Kay Hayen <kay.hayen at gmail.com> wrote:

>
> Hello,
>
> often I write code like this:
>
> def _areConstants(expressions):
>     for expression in expressions:
>         if not expression.isExpressionConstantRef():
>             return False
>
>         if expression.isMutable():
>             return False
>     else:
>         return True
>
> That is to search in an iterable, and return based on finding something,
> or returning in the alternative, I specifically prefer the "else:" branch
> over merely putting it after the "for" loop.
>
> This triggers the above message, which I consider flawed, because as soon
> as there is a "raise", or "return", that should be good enough as well.
> Basically any aborting statement, not only break.
>
> I wanted to hear your opinion on this, pylint bug, or only in my mind.
>
> Yours,
> Kay
> _______________________________________________
> 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/20140112/25310dfa/attachment.html>

From carl.crowder at gmail.com  Sun Jan 12 16:18:48 2014
From: carl.crowder at gmail.com (Carl Crowder)
Date: Sun, 12 Jan 2014 16:18:48 +0100
Subject: [code-quality] pylint: Else clause on a loop without break
	statement
In-Reply-To: <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>
References: <52D2AD40.9080409@gmail.com>
 <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>
Message-ID: <CAK2BMQsW-45o7kMi282v-4Hj9O2mv7SV-08PAXzU87XR29sqmg@mail.gmail.com>

Ian, it's the opposite - 'else' is only triggered if *no* break statement
is encountered.


On 12 January 2014 16:12, Ian Cordasco <graffatcolmingov at gmail.com> wrote:

> I don't see any mesage from pylint in your email, could you post it again?
>
> Regardless, I think what you're disagreeing with is the language
> specification. The documentation specifies that the `else` is only
> triggered on breaks:
>
> http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops
>
> On Sun, Jan 12, 2014 at 8:57 AM, Kay Hayen <kay.hayen at gmail.com> wrote:
> >
> > Hello,
> >
> > often I write code like this:
> >
> > def _areConstants(expressions):
> >     for expression in expressions:
> >         if not expression.isExpressionConstantRef():
> >             return False
> >
> >         if expression.isMutable():
> >             return False
> >     else:
> >         return True
> >
> > That is to search in an iterable, and return based on finding something,
> or
> > returning in the alternative, I specifically prefer the "else:" branch
> over
> > merely putting it after the "for" loop.
> >
> > This triggers the above message, which I consider flawed, because as
> soon as
> > there is a "raise", or "return", that should be good enough as well.
> > Basically any aborting statement, not only break.
> >
> > I wanted to hear your opinion on this, pylint bug, or only in my mind.
> >
> > Yours,
> > Kay
> > _______________________________________________
> > code-quality mailing list
> > code-quality at python.org
> > https://mail.python.org/mailman/listinfo/code-quality
> _______________________________________________
> 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/20140112/cba8a048/attachment.html>

From graffatcolmingov at gmail.com  Sun Jan 12 16:21:58 2014
From: graffatcolmingov at gmail.com (Ian Cordasco)
Date: Sun, 12 Jan 2014 09:21:58 -0600
Subject: [code-quality] pylint: Else clause on a loop without break
	statement
In-Reply-To: <CAK2BMQsW-45o7kMi282v-4Hj9O2mv7SV-08PAXzU87XR29sqmg@mail.gmail.com>
References: <52D2AD40.9080409@gmail.com>
 <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>
 <CAK2BMQsW-45o7kMi282v-4Hj9O2mv7SV-08PAXzU87XR29sqmg@mail.gmail.com>
Message-ID: <CAN-Kwu3s8WCy4uA1zEdbtJRV0iSx18Quc=rjTAy_tCHiZ9Rk_Q@mail.gmail.com>

Woops. Sorry for the confusion. I never end up using that particular
construct so I never get it right.

On Sun, Jan 12, 2014 at 9:18 AM, Carl Crowder <carl.crowder at gmail.com> wrote:
> Ian, it's the opposite - 'else' is only triggered if *no* break statement is
> encountered.
>
>
> On 12 January 2014 16:12, Ian Cordasco <graffatcolmingov at gmail.com> wrote:
>>
>> I don't see any mesage from pylint in your email, could you post it again?
>>
>> Regardless, I think what you're disagreeing with is the language
>> specification. The documentation specifies that the `else` is only
>> triggered on breaks:
>>
>> http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops
>>
>> On Sun, Jan 12, 2014 at 8:57 AM, Kay Hayen <kay.hayen at gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > often I write code like this:
>> >
>> > def _areConstants(expressions):
>> >     for expression in expressions:
>> >         if not expression.isExpressionConstantRef():
>> >             return False
>> >
>> >         if expression.isMutable():
>> >             return False
>> >     else:
>> >         return True
>> >
>> > That is to search in an iterable, and return based on finding something,
>> > or
>> > returning in the alternative, I specifically prefer the "else:" branch
>> > over
>> > merely putting it after the "for" loop.
>> >
>> > This triggers the above message, which I consider flawed, because as
>> > soon as
>> > there is a "raise", or "return", that should be good enough as well.
>> > Basically any aborting statement, not only break.
>> >
>> > I wanted to hear your opinion on this, pylint bug, or only in my mind.
>> >
>> > Yours,
>> > Kay
>> > _______________________________________________
>> > code-quality mailing list
>> > code-quality at python.org
>> > https://mail.python.org/mailman/listinfo/code-quality
>> _______________________________________________
>> code-quality mailing list
>> code-quality at python.org
>> https://mail.python.org/mailman/listinfo/code-quality
>
>

From pludemann at google.com  Sun Jan 12 18:45:25 2014
From: pludemann at google.com (Peter Ludemann)
Date: Sun, 12 Jan 2014 09:45:25 -0800
Subject: [code-quality] pylint: Else clause on a loop without break
	statement
In-Reply-To: <CAN-Kwu3s8WCy4uA1zEdbtJRV0iSx18Quc=rjTAy_tCHiZ9Rk_Q@mail.gmail.com>
References: <52D2AD40.9080409@gmail.com>
 <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>
 <CAK2BMQsW-45o7kMi282v-4Hj9O2mv7SV-08PAXzU87XR29sqmg@mail.gmail.com>
 <CAN-Kwu3s8WCy4uA1zEdbtJRV0iSx18Quc=rjTAy_tCHiZ9Rk_Q@mail.gmail.com>
Message-ID: <CACsRUKKCW87GWheO1W6A4aGpQ3wFULnEGLU0zwDHO3mZZWqnKg@mail.gmail.com>

def _areConstants(expressions):
    return all(_isConstant(expression) for expression in expressions)

def _isConstant(expression):
    return expression.isExpressionConstantRef() and not
expression.isMutable()

?

When I tried to understand the OP's code, I had to mentally step through
the code and assemble the meaning, whereas the above code requires no such
work (it probably takes a bit longer per-line, but less time over-all).

If you're asking about whether pylint should complain about the OP's code,
I think that it shouldn't -- in the semantics of for/else, return and break
are similar and rewriting OP's code to suppress the warnings is not an
improvement:

def _areConstants(expressions):
    for expression in expressions:
        if not expression.isExpressionConstantRef():
            break
        if expression.isMutable():
            break
    else:
        return True
    return False


(Caveat: none of this code has been tested)




On 12 January 2014 07:21, Ian Cordasco <graffatcolmingov at gmail.com> wrote:

> Woops. Sorry for the confusion. I never end up using that particular
> construct so I never get it right.
>
> On Sun, Jan 12, 2014 at 9:18 AM, Carl Crowder <carl.crowder at gmail.com>
> wrote:
> > Ian, it's the opposite - 'else' is only triggered if *no* break
> statement is
> > encountered.
> >
> >
> > On 12 January 2014 16:12, Ian Cordasco <graffatcolmingov at gmail.com>
> wrote:
> >>
> >> I don't see any mesage from pylint in your email, could you post it
> again?
> >>
> >> Regardless, I think what you're disagreeing with is the language
> >> specification. The documentation specifies that the `else` is only
> >> triggered on breaks:
> >>
> >>
> http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops
> >>
> >> On Sun, Jan 12, 2014 at 8:57 AM, Kay Hayen <kay.hayen at gmail.com> wrote:
> >> >
> >> > Hello,
> >> >
> >> > often I write code like this:
> >> >
> >> > def _areConstants(expressions):
> >> >     for expression in expressions:
> >> >         if not expression.isExpressionConstantRef():
> >> >             return False
> >> >
> >> >         if expression.isMutable():
> >> >             return False
> >> >     else:
> >> >         return True
> >> >
> >> > That is to search in an iterable, and return based on finding
> something,
> >> > or
> >> > returning in the alternative, I specifically prefer the "else:" branch
> >> > over
> >> > merely putting it after the "for" loop.
> >> >
> >> > This triggers the above message, which I consider flawed, because as
> >> > soon as
> >> > there is a "raise", or "return", that should be good enough as well.
> >> > Basically any aborting statement, not only break.
> >> >
> >> > I wanted to hear your opinion on this, pylint bug, or only in my mind.
> >> >
> >> > Yours,
> >> > Kay
> >> > _______________________________________________
> >> > code-quality mailing list
> >> > code-quality at python.org
> >> > https://mail.python.org/mailman/listinfo/code-quality
> >> _______________________________________________
> >> code-quality mailing list
> >> code-quality at python.org
> >> https://mail.python.org/mailman/listinfo/code-quality
> >
> >
> _______________________________________________
> 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/20140112/4dea4609/attachment.html>

From carl.crowder at gmail.com  Sun Jan 12 19:04:29 2014
From: carl.crowder at gmail.com (Carl Crowder)
Date: Sun, 12 Jan 2014 19:04:29 +0100
Subject: [code-quality] pylint: Else clause on a loop without break
	statement
In-Reply-To: <CACsRUKKCW87GWheO1W6A4aGpQ3wFULnEGLU0zwDHO3mZZWqnKg@mail.gmail.com>
References: <52D2AD40.9080409@gmail.com>
 <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>
 <CAK2BMQsW-45o7kMi282v-4Hj9O2mv7SV-08PAXzU87XR29sqmg@mail.gmail.com>
 <CAN-Kwu3s8WCy4uA1zEdbtJRV0iSx18Quc=rjTAy_tCHiZ9Rk_Q@mail.gmail.com>
 <CACsRUKKCW87GWheO1W6A4aGpQ3wFULnEGLU0zwDHO3mZZWqnKg@mail.gmail.com>
Message-ID: <20C76AFE-CCB0-4E00-A929-8B49D78DC454@gmail.com>

I think the point is that Pylint does not only say "this is wrong", but also says "are you sure this is right?". These things are usually warnings but perhaps 'code smell' is a better name. Because, in this case, the 'else' isn't strictly necessary, Pylint (correctly, in my opinion) raises a warning which effectively says "This 'else' clause does not actually need to be there - did you do it on purpose, or have some break statements been refactored away or something?". I consider it more like a code review, in which the reviewer tentatively asks "this looks odd - is it deliberate?" simply to verify in case it was not. 

It's pretty easy to suppress the warning either on this line alone or on the entire project if this is your code style, so I prefer the case where Pylint catches a real error but may be to hasty for some users. I think Pylint should be regarded as producing both actual errors as output but also advisories and questions.

On 12.01.2014, at 18:45, Peter Ludemann <pludemann at google.com> wrote:

> def _areConstants(expressions):
>     return all(_isConstant(expression) for expression in expressions)
> 
> def _isConstant(expression):
>     return expression.isExpressionConstantRef() and not expression.isMutable()
> 
> ?
> 
> When I tried to understand the OP's code, I had to mentally step through the code and assemble the meaning, whereas the above code requires no such work (it probably takes a bit longer per-line, but less time over-all).
> 
> If you're asking about whether pylint should complain about the OP's code, I think that it shouldn't -- in the semantics of for/else, return and break are similar and rewriting OP's code to suppress the warnings is not an improvement:
> 
> def _areConstants(expressions):
>     for expression in expressions:
>         if not expression.isExpressionConstantRef():
>             break
>         if expression.isMutable():
>             break
>     else:
>         return True
>     return False
> 
> (Caveat: none of this code has been tested)
> 
> 
> 
> 
> On 12 January 2014 07:21, Ian Cordasco <graffatcolmingov at gmail.com> wrote:
> Woops. Sorry for the confusion. I never end up using that particular
> construct so I never get it right.
> 
> On Sun, Jan 12, 2014 at 9:18 AM, Carl Crowder <carl.crowder at gmail.com> wrote:
> > Ian, it's the opposite - 'else' is only triggered if *no* break statement is
> > encountered.
> >
> >
> > On 12 January 2014 16:12, Ian Cordasco <graffatcolmingov at gmail.com> wrote:
> >>
> >> I don't see any mesage from pylint in your email, could you post it again?
> >>
> >> Regardless, I think what you're disagreeing with is the language
> >> specification. The documentation specifies that the `else` is only
> >> triggered on breaks:
> >>
> >> http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops
> >>
> >> On Sun, Jan 12, 2014 at 8:57 AM, Kay Hayen <kay.hayen at gmail.com> wrote:
> >> >
> >> > Hello,
> >> >
> >> > often I write code like this:
> >> >
> >> > def _areConstants(expressions):
> >> >     for expression in expressions:
> >> >         if not expression.isExpressionConstantRef():
> >> >             return False
> >> >
> >> >         if expression.isMutable():
> >> >             return False
> >> >     else:
> >> >         return True
> >> >
> >> > That is to search in an iterable, and return based on finding something,
> >> > or
> >> > returning in the alternative, I specifically prefer the "else:" branch
> >> > over
> >> > merely putting it after the "for" loop.
> >> >
> >> > This triggers the above message, which I consider flawed, because as
> >> > soon as
> >> > there is a "raise", or "return", that should be good enough as well.
> >> > Basically any aborting statement, not only break.
> >> >
> >> > I wanted to hear your opinion on this, pylint bug, or only in my mind.
> >> >
> >> > Yours,
> >> > Kay
> >> > _______________________________________________
> >> > code-quality mailing list
> >> > code-quality at python.org
> >> > https://mail.python.org/mailman/listinfo/code-quality
> >> _______________________________________________
> >> code-quality mailing list
> >> code-quality at python.org
> >> https://mail.python.org/mailman/listinfo/code-quality
> >
> >
> _______________________________________________
> 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/20140112/c291c14f/attachment-0001.html>

From marc at rintsch.de  Sun Jan 12 23:51:56 2014
From: marc at rintsch.de (Marc 'BlackJack' Rintsch)
Date: Sun, 12 Jan 2014 23:51:56 +0100
Subject: [code-quality] pylint: Else clause on a loop without break
	statement
In-Reply-To: <CACsRUKKCW87GWheO1W6A4aGpQ3wFULnEGLU0zwDHO3mZZWqnKg@mail.gmail.com>
References: <52D2AD40.9080409@gmail.com>
 <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>
 <CAK2BMQsW-45o7kMi282v-4Hj9O2mv7SV-08PAXzU87XR29sqmg@mail.gmail.com>
 <CAN-Kwu3s8WCy4uA1zEdbtJRV0iSx18Quc=rjTAy_tCHiZ9Rk_Q@mail.gmail.com>
 <CACsRUKKCW87GWheO1W6A4aGpQ3wFULnEGLU0zwDHO3mZZWqnKg@mail.gmail.com>
Message-ID: <52D31C8C.6060900@rintsch.de>

On 12/01/14 18:45, Peter Ludemann wrote:
> If you're asking about whether pylint should complain about the OP's
> code, I think that it shouldn't -- in the semantics of for/else, return
> and break are similar and rewriting OP's code to suppress the warnings
> is not an improvement:
> 
>     def _areConstants(expressions):
>         for expression in expressions:
>             if not expression.isExpressionConstantRef():
>                 break
>             if expression.isMutable():
>                 break
>         else:
>             return True
>         return False

That's not an improvement but also not the obvious way to rewrite the
code to suppress the, IMHO legitimate, warning.  Instead of introducing
``break``\s for an unnecessary ``else`` clause one could also just
remove that unnecessary ``else``::

def _areConstants(expressions):
    for expression in expressions:
        if not expression.isExpressionConstantRef():
            return False
        if expression.isMutable():
            return False
    return True

Which improves the situation in a way, because now the fellow Python
coder doesn't wonder where the ``break`` should be or if the author
understood the semantics of ``else`` on loop constructs.

I would also avoid this question by using `all()` here.  :-)

Ciao,
	Marc 'BlackJack' Rintsch
-- 
?It was not a good idea to address any prayers to a Supreme Being.
 It would only attract his attention and might cause trouble.?
                                    -- Terry Pratchett, Small Gods

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/code-quality/attachments/20140112/5793d767/attachment.sig>

From kay.hayen at gmail.com  Mon Jan 13 01:17:22 2014
From: kay.hayen at gmail.com (Kay Hayen)
Date: Mon, 13 Jan 2014 01:17:22 +0100
Subject: [code-quality] pylint: Else clause on a loop without break
	statement
In-Reply-To: <52D31C8C.6060900@rintsch.de>
References: <52D2AD40.9080409@gmail.com>
 <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>
 <CAK2BMQsW-45o7kMi282v-4Hj9O2mv7SV-08PAXzU87XR29sqmg@mail.gmail.com>
 <CAN-Kwu3s8WCy4uA1zEdbtJRV0iSx18Quc=rjTAy_tCHiZ9Rk_Q@mail.gmail.com>
 <CACsRUKKCW87GWheO1W6A4aGpQ3wFULnEGLU0zwDHO3mZZWqnKg@mail.gmail.com>
 <52D31C8C.6060900@rintsch.de>
Message-ID: <CAMEZBDKC9pAS7noQJttC0SpAoMC1VDUjH=mcCUShp0oc1gX7rA@mail.gmail.com>

Hello,

thanks for all the replies.

Of course I am aware that my use of the "else:" is different from the
"break" case
when it comes to "return". For return, the "else:" is not needed, as it
won't continue
the execution.

>     def _areConstants(expressions):
> >         for expression in expressions:
> >             if not expression.isExpressionConstantRef():
> >                 break
> >             if expression.isMutable():
> >                 break
> >         else:
> >             return True
> >         return False
>
> That's not an improvement but also not the obvious way to rewrite the
> code to suppress the, IMHO legitimate, warning.  Instead of introducing
> ``break``\s for an unnecessary ``else`` clause one could also just
> remove that unnecessary ``else``::
>

Mind you, I am using the "else:" specifically to express, that I expect the
loop
to return based on one element. I agree with you that the suggested code is
making that hard to discern and that removing the "else" clause is an
option.

The thing is, I developed a style, where a return in the loop always leads
to
a return in a else. It's the pick and choose method. So any time, I make
decisions based on an iterable, I do it like that.

def _areConstants(expressions):
>     for expression in expressions:
>         if not expression.isExpressionConstantRef():
>             return False
>         if expression.isMutable():
>             return False
>     return True
>
> Which improves the situation in a way, because now the fellow Python
> coder doesn't wonder where the ``break`` should be or if the author
> understood the semantics of ``else`` on loop constructs.
>

That precisely is the question. Is the "else" an emphasis, or is it an error
indicator. I can assure you that I did it on purpose. But if nobody gets
that,
it kinds of misses the point.

I take the general feedback to say "yes, using else: without need is a style
problem". So I will try and give it up. :-)


> I would also avoid this question by using `all()` here.  :-)
>

I learned of "any" and "all" relatively late. I agree for booleans it's the
better
choice, but it's another subject. Many times, it's not a boolean return
value.

Yours,
Kay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20140113/722b5466/attachment.html>

From pludemann at google.com  Mon Jan 13 05:31:08 2014
From: pludemann at google.com (Peter Ludemann)
Date: Sun, 12 Jan 2014 20:31:08 -0800
Subject: [code-quality] pylint: Else clause on a loop without break
	statement
In-Reply-To: <CAMEZBDKC9pAS7noQJttC0SpAoMC1VDUjH=mcCUShp0oc1gX7rA@mail.gmail.com>
References: <52D2AD40.9080409@gmail.com>
 <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>
 <CAK2BMQsW-45o7kMi282v-4Hj9O2mv7SV-08PAXzU87XR29sqmg@mail.gmail.com>
 <CAN-Kwu3s8WCy4uA1zEdbtJRV0iSx18Quc=rjTAy_tCHiZ9Rk_Q@mail.gmail.com>
 <CACsRUKKCW87GWheO1W6A4aGpQ3wFULnEGLU0zwDHO3mZZWqnKg@mail.gmail.com>
 <52D31C8C.6060900@rintsch.de>
 <CAMEZBDKC9pAS7noQJttC0SpAoMC1VDUjH=mcCUShp0oc1gX7rA@mail.gmail.com>
Message-ID: <CACsRUKLmq+A+U+JzE3mh+918THHrem2siBeNOJzzLAFW2NWB_w@mail.gmail.com>

On 12 January 2014 16:17, Kay Hayen <kay.hayen at gmail.com> wrote:

>
> Hello,
>
> thanks for all the replies.
>
> Of course I am aware that my use of the "else:" is different from the
> "break" case
> when it comes to "return". For return, the "else:" is not needed, as it
> won't continue
> the execution.
>
> >     def _areConstants(expressions):
>> >         for expression in expressions:
>> >             if not expression.isExpressionConstantRef():
>> >                 break
>> >             if expression.isMutable():
>> >                 break
>> >         else:
>> >             return True
>> >         return False
>>
>> That's not an improvement but also not the obvious way to rewrite the
>> code to suppress the, IMHO legitimate, warning.  Instead of introducing
>> ``break``\s for an unnecessary ``else`` clause one could also just
>> remove that unnecessary ``else``::
>>
>
> Mind you, I am using the "else:" specifically to express, that I expect
> the loop
> to return based on one element. I agree with you that the suggested code is
> making that hard to discern and that removing the "else" clause is an
> option.
>

I'm reversing my earlier opinion ... if all the ways of breaking out of the
loop are "return", the "else" is not needed and Pylint should point this
out.


>
> The thing is, I developed a style, where a return in the loop always leads
> to
> a return in a else. It's the pick and choose method. So any time, I make
> decisions based on an iterable, I do it like that.
>
> def _areConstants(expressions):
>>     for expression in expressions:
>>         if not expression.isExpressionConstantRef():
>>             return False
>>         if expression.isMutable():
>>             return False
>>     return True
>>
>> Which improves the situation in a way, because now the fellow Python
>> coder doesn't wonder where the ``break`` should be or if the author
>> understood the semantics of ``else`` on loop constructs.
>>
>
> That precisely is the question. Is the "else" an emphasis, or is it an
> error
> indicator. I can assure you that I did it on purpose. But if nobody gets
> that,
> it kinds of misses the point.
>
> I take the general feedback to say "yes, using else: without need is a
> style
> problem". So I will try and give it up. :-)
>
>
>> I would also avoid this question by using `all()` here.  :-)
>>
>
> I learned of "any" and "all" relatively late. I agree for booleans it's
> the better
> choice, but it's another subject. Many times, it's not a boolean return
> value.
>

"Any" and "all" are just special cases of "max" and "min". ;)
And there are many other tools for processing lists without for-loops,
e.g.: http://docs.python.org/3/library/itertools.html#itertools-recipes

- peter


>
> Yours,
> Kay
>
>
> _______________________________________________
> 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/20140112/438cc8ea/attachment-0001.html>

From sylvain.thenault at logilab.fr  Mon Jan 13 10:47:39 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Mon, 13 Jan 2014 10:47:39 +0100
Subject: [code-quality] pylint: Else clause on a loop without break
 statement
In-Reply-To: <20C76AFE-CCB0-4E00-A929-8B49D78DC454@gmail.com>
References: <52D2AD40.9080409@gmail.com>
 <CAN-Kwu3mW+393fTt1MJRonGy5nzHjnXv_XXFCAFSTZ7R4=gFaw@mail.gmail.com>
 <CAK2BMQsW-45o7kMi282v-4Hj9O2mv7SV-08PAXzU87XR29sqmg@mail.gmail.com>
 <CAN-Kwu3s8WCy4uA1zEdbtJRV0iSx18Quc=rjTAy_tCHiZ9Rk_Q@mail.gmail.com>
 <CACsRUKKCW87GWheO1W6A4aGpQ3wFULnEGLU0zwDHO3mZZWqnKg@mail.gmail.com>
 <20C76AFE-CCB0-4E00-A929-8B49D78DC454@gmail.com>
Message-ID: <20140113094739.GC2832@logilab.fr>

On 12 janvier 19:04, Carl Crowder wrote:
> I think the point is that Pylint does not only say "this is wrong", but also says "are you sure this is right?". These things are usually warnings but perhaps 'code smell' is a better name. Because, in this case, the 'else' isn't strictly necessary, Pylint (correctly, in my opinion) raises a warning which effectively says "This 'else' clause does not actually need to be there - did you do it on purpose, or have some break statements been refactored away or something?". I consider it more like a code review, in which the reviewer tentatively asks "this looks odd - is it deliberate?" simply to verify in case it was not. 
> 
> It's pretty easy to suppress the warning either on this line alone or on the entire project if this is your code style, so I prefer the case where Pylint catches a real error but may be to hasty for some users. I think Pylint should be regarded as producing both actual errors as output but also advisories and questions.

That's exactly the point: pylint does only tell you "buddy, there may be here
something weird or/and that could be written differently", and that's perfectly
fine to shut him down if you feel it's ok.
-- 
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 zunbeltz at gmail.com  Thu Jan 16 10:32:52 2014
From: zunbeltz at gmail.com (Zunbeltz Izaola)
Date: Thu, 16 Jan 2014 10:32:52 +0100
Subject: [code-quality] pylint and gtk3
Message-ID: <52D7A744.3090002@gmail.com>

Dear all,

I read that pylint can handle the gobject introspection thanks to 
astroid and pylint-brain.
I installed version 1.1 of pylint and py2gi.py is installed in my system.
But, I don't understand how to enable the use of py2gi, because I still 
have the E1101

Instance of 'Box' has no 'pack_start' member (no-member)


Thanks in advance for your help,

Zunbeltz

-- 
Zunbeltz Izaola


From mhamilt at sandia.gov  Thu Jan 16 18:50:22 2014
From: mhamilt at sandia.gov (Mark E. Hamilton)
Date: Thu, 16 Jan 2014 10:50:22 -0700
Subject: [code-quality] Change in error messages in pylint 1.1
Message-ID: <52D81BDE.8080008@sandia.gov>

Hi,

When we updated to pylint 1.1 many of the messages changed. In 
particular, the invalid-name (C0103) message used to say:

... Invalid name "Test_which" for type class (should match 
[A-Z_][a-zA-Z0-9]+$)

which was really useful, since (if you understand regular expressions) 
it tells the user exactly what the name pattern should be. Now, however, 
it only says:

... Invalid class name "Test_which"

This is less than useful, since as a user I might not know where to go 
to find out what the RE is that was matched against. The messages 
generated by --list-msgs only shows the general message:

:invalid-name (C0103): *Invalid %s name "%s"*
   Used when the name doesn't match the regular expression associated to 
its type
   (constant, variable, class...).

which doesn't help.

The default REs show up in the --long-help output, but a user has to run 
that manually, then look for the option which affects the particular 
message he is seeing.

Is there a way simple way to get the REs on the generated html pages again?

-- 
----------------
Mark E. Hamilton
Senior Member of Technical Staff
Sandia National Laboratories
505-844-7666

From sylvain.thenault at logilab.fr  Fri Jan 17 07:32:12 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Fri, 17 Jan 2014 07:32:12 +0100
Subject: [code-quality] Change in error messages in pylint 1.1
In-Reply-To: <52D81BDE.8080008@sandia.gov>
References: <52D81BDE.8080008@sandia.gov>
Message-ID: <20140117063212.GA2604@logilab.fr>

On 16 janvier 10:50, Mark E. Hamilton wrote:
> Hi,

Hi Mark,
 
> When we updated to pylint 1.1 many of the messages changed. In
> particular, the invalid-name (C0103) message used to say:
> 
> ... Invalid name "Test_which" for type class (should match
> [A-Z_][a-zA-Z0-9]+$)
> 
> which was really useful, since (if you understand regular
> expressions) it tells the user exactly what the name pattern should
> be. Now, however, it only says:
> 
> ... Invalid class name "Test_which"
> 
> This is less than useful, since as a user I might not know where to
> go to find out what the RE is that was matched against. The messages
> generated by --list-msgs only shows the general message:
> 
> :invalid-name (C0103): *Invalid %s name "%s"*
>   Used when the name doesn't match the regular expression associated
> to its type
>   (constant, variable, class...).
> 
> which doesn't help.
> 
> The default REs show up in the --long-help output, but a user has to
> run that manually, then look for the option which affects the
> particular message he is seeing.
> 
> Is there a way simple way to get the REs on the generated html pages again?

I'm afraid not. You should file an issue in the bitbucket tracker:
https://bitbucket.org/logilab/pylint

Thank you for your feedback, regards,
-- 
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 sylvain.thenault at logilab.fr  Fri Jan 17 07:42:00 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Fri, 17 Jan 2014 07:42:00 +0100
Subject: [code-quality] pylint and gtk3
In-Reply-To: <52D7A744.3090002@gmail.com>
References: <52D7A744.3090002@gmail.com>
Message-ID: <20140117064200.GC2604@logilab.fr>

On 16 janvier 10:32, Zunbeltz Izaola wrote:
> Dear all,
> 
> I read that pylint can handle the gobject introspection thanks to
> astroid and pylint-brain.
> I installed version 1.1 of pylint and py2gi.py is installed in my system.
> But, I don't understand how to enable the use of py2gi, because I
> still have the E1101
> 
> Instance of 'Box' has no 'pack_start' member (no-member)

The py2gi module should be enabled by default. Maybe your case isn't covered by
it? You may want to open an issue on pylint-brain
(https://bitbucket.org/logilab/pylint-brain/) with some code illustrating the
problem. Also, you may want to talk about that with
https://bitbucket.org/crobinso which is the original patch author.

-- 
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 sylvain.thenault at logilab.fr  Fri Jan 17 11:05:58 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Fri, 17 Jan 2014 11:05:58 +0100
Subject: [code-quality] pylint and gtk3
In-Reply-To: <52D8FDF7.8080603@gmail.com>
References: <52D7A744.3090002@gmail.com> <20140117064200.GC2604@logilab.fr>
 <52D8F54A.6020101@gmail.com> <20140117094540.GJ2604@logilab.fr>
 <52D8FDF7.8080603@gmail.com>
Message-ID: <20140117100558.GL2604@logilab.fr>

On 17 janvier 10:55, Zunbeltz Izaola wrote:
> No. I get the E1101 error. So it seems it is a problem with my system.
> 
> locate pylint shows that the only installed package is
> /usr/local/lib/python2.7/dist-packages/pylint-1.1.0.egg-info
> 
> I installed it with pip.

and it then works fine?

Notice gi support is provided by astroid.
-- 
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 zunbeltz at gmail.com  Fri Jan 17 10:55:03 2014
From: zunbeltz at gmail.com (Zunbeltz Izaola)
Date: Fri, 17 Jan 2014 10:55:03 +0100
Subject: [code-quality] pylint and gtk3
In-Reply-To: <20140117094540.GJ2604@logilab.fr>
References: <52D7A744.3090002@gmail.com> <20140117064200.GC2604@logilab.fr>
 <52D8F54A.6020101@gmail.com> <20140117094540.GJ2604@logilab.fr>
Message-ID: <52D8FDF7.8080603@gmail.com>

No. I get the E1101 error. So it seems it is a problem with my system.

locate pylint shows that the only installed package is
/usr/local/lib/python2.7/dist-packages/pylint-1.1.0.egg-info

I installed it with pip.

Zunbeltz



or., 2014.eko urtren 17a 10:45(e)an, Sylvain Th?nault(e)k idatzi zuen:
> On 17 janvier 10:18, Zunbeltz Izaola wrote:
>> Dear Sylvain,
>>
>> It is strange that the error is for all the methods of the gtk3 objects.
>> I import the Gtk namespace in the following way
>>
>>
>> from gi.repository import Gtk
>> from gi.repository import Gio
>>
>> Construction the basic objects, like Box(), is fine; but calling its
>> methods raises the error mensage.
>> This is why I think that brain was not enabled by default.
>> The tests at pylint-brain/test run fine.
>> The pylint --version output is
>>
>> pylint 1.1.0,
>> astroid 1.0.1, common 0.60.1
>> Python 2.7.5+ (default, Sep 19 2013, 13:49:51)
>> [GCC 4.8.1]
> [syt at orion ~]$ cat girepo.py
> from gi.repository import Gtk
> b = Gtk.Box()
> b.show_all()
> [syt at orion ~]$ pylint -rn girepo.py
> ************* Module girepo
> C:  1, 0: Missing module docstring (missing-docstring)
> C:  2, 0: Invalid constant name "b" (invalid-name)
>
>
> Does this work for you?


-- 
Zunbeltz Izaola


From zunbeltz at gmail.com  Fri Jan 17 11:13:32 2014
From: zunbeltz at gmail.com (Zunbeltz Izaola)
Date: Fri, 17 Jan 2014 11:13:32 +0100
Subject: [code-quality] pylint and gtk3
In-Reply-To: <20140117100558.GL2604@logilab.fr>
References: <52D7A744.3090002@gmail.com> <20140117064200.GC2604@logilab.fr>
 <52D8F54A.6020101@gmail.com> <20140117094540.GJ2604@logilab.fr>
 <52D8FDF7.8080603@gmail.com> <20140117100558.GL2604@logilab.fr>
Message-ID: <52D9024C.5040106@gmail.com>

No. pip says that pylint and astroid are up to date.
And it is NOT working find.

zunbeltz at zunbeltz-VPCF12E1E:~$ pylint -rn test.py
/usr/local/bin/pylint:5: UserWarning: Module dap was already imported 
from None, but /usr/lib/python2.7/dist-packages is being added to sys.path
   from pkg_resources import load_entry_point
No config file found, using default configuration
************* Module test
C:  1, 0: Missing module docstring (missing-docstring)
C:  2, 0: Invalid constant name "b" (invalid-name)
E:  3, 0: Instance of 'Box' has no 'show_all' member (no-member)


or., 2014.eko urtren 17a 11:05(e)an, Sylvain Th?nault(e)k idatzi zuen:
> On 17 janvier 10:55, Zunbeltz Izaola wrote:
>> No. I get the E1101 error. So it seems it is a problem with my system.
>>
>> locate pylint shows that the only installed package is
>> /usr/local/lib/python2.7/dist-packages/pylint-1.1.0.egg-info
>>
>> I installed it with pip.
> and it then works fine?
>
> Notice gi support is provided by astroid.


-- 
Zunbeltz Izaola


From sylvain.thenault at logilab.fr  Fri Jan 17 14:08:45 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Fri, 17 Jan 2014 14:08:45 +0100
Subject: [code-quality] pylint and gtk3
In-Reply-To: <52D9024C.5040106@gmail.com>
References: <52D7A744.3090002@gmail.com> <20140117064200.GC2604@logilab.fr>
 <52D8F54A.6020101@gmail.com> <20140117094540.GJ2604@logilab.fr>
 <52D8FDF7.8080603@gmail.com> <20140117100558.GL2604@logilab.fr>
 <52D9024C.5040106@gmail.com>
Message-ID: <20140117130845.GO2604@logilab.fr>

On 17 janvier 11:13, Zunbeltz Izaola wrote:
> No. pip says that pylint and astroid are up to date.
> And it is NOT working find.

do you have the py2gi.py file into astroid/brain ?
-- 
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 timothy.crosley at gmail.com  Sun Jan 19 16:50:32 2014
From: timothy.crosley at gmail.com (timothy crosley)
Date: Sun, 19 Jan 2014 10:50:32 -0500
Subject: [code-quality] Pyflakes forked to Frosted
Message-ID: <CANkC=g3ek+0a-wrTjb0SRhrF86iq8Z4A-7_mgsPMsVngpybpgw@mail.gmail.com>

Hi Everyone,

I just wanted to let you know, after Pyflakes seemed dead for about 5
months I created a fork called Frosted:

https://github.com/timothycrosley/frosted

While it seems that Pyflakes is somewhat alive again, In the fork a lot of
code has been simplified and a lot of necessary but missing features (such
as configuration) have been added. Additionally, I've merged in a lot of
improvements from the Pyflakes community at large. I will be working hard
to improve Frosted further, and any suggestions / feature improvements that
are recommended will be met with enthusiasm :).

While, I would be willing to merge the two projects at some later point, I
think in the short-term the rapid development and freedom working under a
new project name will bring - will be very beneficial. I have added Florent
Xicluna and Steven Myint as collaborators on the project, as these are both
developers I have high regard for, and remove the possibility of me being
the single source of failure for unmerged pull-requests.

So if you have time, please check out the project, request features, and
make pull requests. Lets make a great Python code checker even better!

Thanks!

Timothy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20140119/e1e557e1/attachment.html>

From graffatcolmingov at gmail.com  Sun Jan 19 17:35:58 2014
From: graffatcolmingov at gmail.com (Ian Cordasco)
Date: Sun, 19 Jan 2014 10:35:58 -0600
Subject: [code-quality] Pyflakes forked to Frosted
In-Reply-To: <CANkC=g3ek+0a-wrTjb0SRhrF86iq8Z4A-7_mgsPMsVngpybpgw@mail.gmail.com>
References: <CANkC=g3ek+0a-wrTjb0SRhrF86iq8Z4A-7_mgsPMsVngpybpgw@mail.gmail.com>
Message-ID: <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>

If you're going to continue to maintain this fork you should join the
mailing list so your messages do not need to be moderated.

That said, I have a few points of feedback for you:

Error numbers in tools such as pep8 and pyflakes (although flake8 adds
them to pyflakes) are usually not made to be entirely successive. For
the most part, there are groupings of errors. The best explanation of
this is pep8's documentation:
http://pep8.readthedocs.org/en/latest/intro.html#error-codes

Anything starting with E1 is related to indentation, anything starting
with E2 is related to whitespace. These are conceptually classes of
errors. PyLint also follows this convention if I remember correctly
and you would do well to do the same. The error codes that Flake8 adds
to PyFlakes follow that convention as well.

This probably also means that if you're following semver that this
will be a new major version bump since you're changing how items are
ignored.

On Sun, Jan 19, 2014 at 9:50 AM, timothy crosley
<timothy.crosley at gmail.com> wrote:
> Hi Everyone,
>
> I just wanted to let you know, after Pyflakes seemed dead for about 5 months
> I created a fork called Frosted:
>
> https://github.com/timothycrosley/frosted
>
> While it seems that Pyflakes is somewhat alive again, In the fork a lot of
> code has been simplified and a lot of necessary but missing features (such
> as configuration) have been added. Additionally, I've merged in a lot of
> improvements from the Pyflakes community at large. I will be working hard to
> improve Frosted further, and any suggestions / feature improvements that are
> recommended will be met with enthusiasm :).
>
> While, I would be willing to merge the two projects at some later point, I
> think in the short-term the rapid development and freedom working under a
> new project name will bring - will be very beneficial. I have added Florent
> Xicluna and Steven Myint as collaborators on the project, as these are both
> developers I have high regard for, and remove the possibility of me being
> the single source of failure for unmerged pull-requests.
>
> So if you have time, please check out the project, request features, and
> make pull requests. Lets make a great Python code checker even better!
>
> Thanks!
>
> Timothy
>
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality
>

From graffatcolmingov at gmail.com  Sun Jan 19 18:06:24 2014
From: graffatcolmingov at gmail.com (Ian Cordasco)
Date: Sun, 19 Jan 2014 11:06:24 -0600
Subject: [code-quality] Pyflakes forked to Frosted
In-Reply-To: <CANkC=g1qhXTYd4E6GZWRXxnzruX=KCX49Mn2xNbS4QzJVmtn3A@mail.gmail.com>
References: <CANkC=g3ek+0a-wrTjb0SRhrF86iq8Z4A-7_mgsPMsVngpybpgw@mail.gmail.com>
 <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>
 <CANkC=g1qhXTYd4E6GZWRXxnzruX=KCX49Mn2xNbS4QzJVmtn3A@mail.gmail.com>
Message-ID: <CAN-Kwu3rCALZsVZ+hyt6rBCWo+vRCuxunDyuKD9mKf1JLu9uqg@mail.gmail.com>

Also, feel free to list this mailing list in your readme. Pylint, pep8,
PyFlakes, mccabe, and Flake8 all use this as their project mailing lists.
On Jan 19, 2014 11:00 AM, "timothy crosley" <timothy.crosley at gmail.com>
wrote:

> Hi Ian,
>
> I do plan on maintaining this fork, and I had just subscribed and verified
> my email. I'm not sure why it still required moderation - is there a
> waiting period? Different subscription modes?
>
> In any case,
> Thanks for the helpful feedback! I will implement this conceptual error
> codes, as I agree it is more logical and standard.
> I am following semantic versioning so it will mean incrementing to new
> major version - but it shouldn't be too big of a deal as frosted does not
> yet have a large group of users.
>
> Thanks!
>
> Timothy
>
>
> On Sun, Jan 19, 2014 at 11:35 AM, Ian Cordasco <graffatcolmingov at gmail.com
> > wrote:
>
>> If you're going to continue to maintain this fork you should join the
>> mailing list so your messages do not need to be moderated.
>>
>> That said, I have a few points of feedback for you:
>>
>> Error numbers in tools such as pep8 and pyflakes (although flake8 adds
>> them to pyflakes) are usually not made to be entirely successive. For
>> the most part, there are groupings of errors. The best explanation of
>> this is pep8's documentation:
>> http://pep8.readthedocs.org/en/latest/intro.html#error-codes
>>
>> Anything starting with E1 is related to indentation, anything starting
>> with E2 is related to whitespace. These are conceptually classes of
>> errors. PyLint also follows this convention if I remember correctly
>> and you would do well to do the same. The error codes that Flake8 adds
>> to PyFlakes follow that convention as well.
>>
>> This probably also means that if you're following semver that this
>> will be a new major version bump since you're changing how items are
>> ignored.
>>
>> On Sun, Jan 19, 2014 at 9:50 AM, timothy crosley
>> <timothy.crosley at gmail.com> wrote:
>> > Hi Everyone,
>> >
>> > I just wanted to let you know, after Pyflakes seemed dead for about 5
>> months
>> > I created a fork called Frosted:
>> >
>> > https://github.com/timothycrosley/frosted
>> >
>> > While it seems that Pyflakes is somewhat alive again, In the fork a lot
>> of
>> > code has been simplified and a lot of necessary but missing features
>> (such
>> > as configuration) have been added. Additionally, I've merged in a lot of
>> > improvements from the Pyflakes community at large. I will be working
>> hard to
>> > improve Frosted further, and any suggestions / feature improvements
>> that are
>> > recommended will be met with enthusiasm :).
>> >
>> > While, I would be willing to merge the two projects at some later
>> point, I
>> > think in the short-term the rapid development and freedom working under
>> a
>> > new project name will bring - will be very beneficial. I have added
>> Florent
>> > Xicluna and Steven Myint as collaborators on the project, as these are
>> both
>> > developers I have high regard for, and remove the possibility of me
>> being
>> > the single source of failure for unmerged pull-requests.
>> >
>> > So if you have time, please check out the project, request features, and
>> > make pull requests. Lets make a great Python code checker even better!
>> >
>> > Thanks!
>> >
>> > Timothy
>> >
>> > _______________________________________________
>> > 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/20140119/be0a4f8d/attachment.html>

From timothy.crosley at gmail.com  Sun Jan 19 18:00:16 2014
From: timothy.crosley at gmail.com (timothy crosley)
Date: Sun, 19 Jan 2014 12:00:16 -0500
Subject: [code-quality] Pyflakes forked to Frosted
In-Reply-To: <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>
References: <CANkC=g3ek+0a-wrTjb0SRhrF86iq8Z4A-7_mgsPMsVngpybpgw@mail.gmail.com>
 <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>
Message-ID: <CANkC=g1qhXTYd4E6GZWRXxnzruX=KCX49Mn2xNbS4QzJVmtn3A@mail.gmail.com>

Hi Ian,

I do plan on maintaining this fork, and I had just subscribed and verified
my email. I'm not sure why it still required moderation - is there a
waiting period? Different subscription modes?

In any case,
Thanks for the helpful feedback! I will implement this conceptual error
codes, as I agree it is more logical and standard.
I am following semantic versioning so it will mean incrementing to new
major version - but it shouldn't be too big of a deal as frosted does not
yet have a large group of users.

Thanks!

Timothy


On Sun, Jan 19, 2014 at 11:35 AM, Ian Cordasco
<graffatcolmingov at gmail.com>wrote:

> If you're going to continue to maintain this fork you should join the
> mailing list so your messages do not need to be moderated.
>
> That said, I have a few points of feedback for you:
>
> Error numbers in tools such as pep8 and pyflakes (although flake8 adds
> them to pyflakes) are usually not made to be entirely successive. For
> the most part, there are groupings of errors. The best explanation of
> this is pep8's documentation:
> http://pep8.readthedocs.org/en/latest/intro.html#error-codes
>
> Anything starting with E1 is related to indentation, anything starting
> with E2 is related to whitespace. These are conceptually classes of
> errors. PyLint also follows this convention if I remember correctly
> and you would do well to do the same. The error codes that Flake8 adds
> to PyFlakes follow that convention as well.
>
> This probably also means that if you're following semver that this
> will be a new major version bump since you're changing how items are
> ignored.
>
> On Sun, Jan 19, 2014 at 9:50 AM, timothy crosley
> <timothy.crosley at gmail.com> wrote:
> > Hi Everyone,
> >
> > I just wanted to let you know, after Pyflakes seemed dead for about 5
> months
> > I created a fork called Frosted:
> >
> > https://github.com/timothycrosley/frosted
> >
> > While it seems that Pyflakes is somewhat alive again, In the fork a lot
> of
> > code has been simplified and a lot of necessary but missing features
> (such
> > as configuration) have been added. Additionally, I've merged in a lot of
> > improvements from the Pyflakes community at large. I will be working
> hard to
> > improve Frosted further, and any suggestions / feature improvements that
> are
> > recommended will be met with enthusiasm :).
> >
> > While, I would be willing to merge the two projects at some later point,
> I
> > think in the short-term the rapid development and freedom working under a
> > new project name will bring - will be very beneficial. I have added
> Florent
> > Xicluna and Steven Myint as collaborators on the project, as these are
> both
> > developers I have high regard for, and remove the possibility of me being
> > the single source of failure for unmerged pull-requests.
> >
> > So if you have time, please check out the project, request features, and
> > make pull requests. Lets make a great Python code checker even better!
> >
> > Thanks!
> >
> > Timothy
> >
> > _______________________________________________
> > 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/20140119/93224a73/attachment-0001.html>

From kay.hayen at gmail.com  Sun Jan 19 18:12:05 2014
From: kay.hayen at gmail.com (Kay Hayen)
Date: Sun, 19 Jan 2014 18:12:05 +0100
Subject: [code-quality] Pyflakes forked to Frosted
In-Reply-To: <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>
References: <CANkC=g3ek+0a-wrTjb0SRhrF86iq8Z4A-7_mgsPMsVngpybpgw@mail.gmail.com>
 <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>
Message-ID: <CAMEZBDKk4tV0fkkHVXrpYKT2uvEUNjxn22HG6TFBvzJio_ZBFw@mail.gmail.com>

Hello,

this was interesting to me:

Error numbers in tools such as pep8 and pyflakes (although flake8 adds
> them to pyflakes) are usually not made to be entirely successive. For
> the most part, there are groupings of errors. The best explanation of
> this is pep8's documentation:
> http://pep8.readthedocs.org/en/latest/intro.html#error-codes
>
> Anything starting with E1 is related to indentation, anything starting
> with E2 is related to whitespace. These are conceptually classes of
> errors. PyLint also follows this convention if I remember correctly
> and you would do well to do the same. The error codes that Flake8 adds
> to PyFlakes follow that convention as well.
>

So for my compiler Nuitka, there are very few warnings so far, mostly
because
it is very limited in its tracing abilities, but I am expanding this now,
and so far
I was kind of clueless on how to properly format error and warning messages.

It probably will a while, before I find the need to expand it, but it would
be good
to have a common ground, reusable data. For PyLint, these texts seem spread
out in the variables files.

Is there an easy way to access the PyLint warning/error message texts. Would
you be OK with me to grep these out of PyLint or Wiki, and use them under
ASF2
in my project as well. I would of course prefer, for these to exist a place
that makes
reuse easier.

Basically, I am saying, why isn't this some kind of standard. And can we
make it
one.

Yours,
Kay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20140119/9334196c/attachment.html>

From graffatcolmingov at gmail.com  Sun Jan 19 18:45:18 2014
From: graffatcolmingov at gmail.com (Ian Cordasco)
Date: Sun, 19 Jan 2014 11:45:18 -0600
Subject: [code-quality] Error codes (Was: Pyflakes forked to Frosted)
Message-ID: <CAN-Kwu3HNP1ymYAeOnnFyEr=vkVMV3mpU159+qT=ESq-85hgXQ@mail.gmail.com>

On Sun, Jan 19, 2014 at 11:12 AM, Kay Hayen <kay.hayen at gmail.com> wrote:
> Hello,
>
> this was interesting to me:
>
>> Error numbers in tools such as pep8 and pyflakes (although flake8 adds
>> them to pyflakes) are usually not made to be entirely successive. For
>> the most part, there are groupings of errors. The best explanation of
>> this is pep8's documentation:
>> http://pep8.readthedocs.org/en/latest/intro.html#error-codes
>>
>> Anything starting with E1 is related to indentation, anything starting
>> with E2 is related to whitespace. These are conceptually classes of
>> errors. PyLint also follows this convention if I remember correctly
>> and you would do well to do the same. The error codes that Flake8 adds
>> to PyFlakes follow that convention as well.
>
>
> So for my compiler Nuitka, there are very few warnings so far, mostly
> because
> it is very limited in its tracing abilities, but I am expanding this now,
> and so far
> I was kind of clueless on how to properly format error and warning messages.
>
> It probably will a while, before I find the need to expand it, but it would
> be good
> to have a common ground, reusable data. For PyLint, these texts seem spread
> out in the variables files.

You would do best to research (and possibly revive) past conversations
on this list about a standardization of error messages. I believe the
standard that Flake8 uses is also pep8's format (which is similar to
PyLint). pep257 also has a rewrite branch to use that format. Trying
to create a standard about something so subjective is difficult and it
becomes more difficult when tools like pep8 support providing your own
formatter.

> Is there an easy way to access the PyLint warning/error message texts.

I would hope so, but I do not personally know.

> Would you be OK with me to grep these out of PyLint or Wiki, and use them under
> ASF2
> in my project as well. I would of course prefer, for these to exist a place
> that makes
> reuse easier.

I cannot grant you permission to do this because I am not associated
with the project. For others reading the list, the ASF2 refers to
https://www.apache.org/licenses/LICENSE-2.0, also known as the Apache
License 2.0. I'm also a bit fuzzy on the compatibility of the LGPL2.1
with Apache 2.0. I'm also not entirely certain how PyLint's error
codes would benefit your project.

> Basically, I am saying, why isn't this some kind of standard. And can we
> make it
> one.

Standardizing anything is difficult. People rarely agree on anything.
One way to achieve your standard, however, may be to write a package
(ideally permissively licensed like Nuitka) that provides formatters
for the more popular options, i.e., pep8 and pyflakes. Then simply
encourage those writing similar tools to use that to reduce code
duplication and possible errors. If your module achieves enough
popularity, it would then become a de facto standard rather than a
standard designed by committee.

Further, you seem to be conflating ideas:

- Message/warning formatting
- Error code design

The former deals with how the message is printed, while the latter is
far more semantic in how error codes are assigned. The latter will be
far harder to codify than even the former. Again a module to help with
this may work but I would guess that people will be less inclined to
use it than a module which formats the messages for them.

Cheers,
Ian

From florent.xicluna at gmail.com  Sun Jan 19 19:25:09 2014
From: florent.xicluna at gmail.com (Florent)
Date: Sun, 19 Jan 2014 19:25:09 +0100
Subject: [code-quality] Pyflakes forked to Frosted
In-Reply-To: <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>
References: <CANkC=g3ek+0a-wrTjb0SRhrF86iq8Z4A-7_mgsPMsVngpybpgw@mail.gmail.com>
 <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>
Message-ID: <CAPFzasMzUEwUKMC2iSAGaU+zfLkgvjpVVBAFWkvwJbUpxD2NyQ@mail.gmail.com>

Hello,

first, thank you Timothy for your interest in Pyflakes.
Unfortunately I did not have time to look at Frosted yet.

In the first quarter of 2013, I took over the maintenance of Pyflakes,
and I did merge the various contributions into the mainstream
repository.
At the same time, I helped Ian to prepare the new version of Flake8
while making it easier to anyone to write custom extensions. This was
released as Flake8 2.0 which leverages the extension mechanism of the
pep8 tool.

Sadly, for the past 6 months I did have not enough time to prepare a
new release of Pyflakes.
I wish I have some time available soon, and I can review more PRs.

For Pyflakes, I give priority on stability, reliability and
compatibility over new features, though.
As an example, I will probably turn off the feature for doctest
checking by default, because people found it a bit disruptive for
their existing code bases :
https://bugs.launchpad.net/pyflakes/+bug/1223150

With the latest developments in Flake8, the recommended path to
implement a new feature is to write an extension.
Some documentation here: http://flake8.readthedocs.org/en/latest/extensions.html
And see also examples on PyPI (pep8-naming, mccabe, flake8-docstrings).

For the record, there's a numbers' policy for the codification of
Flake8 warnings, which complements the pep8 list:
http://flake8.readthedocs.org/en/latest/warnings.html
You will find codes for the Pyflakes tool on this page too.

Thank you again for your involvement in the development of Frosted.
In one way or another, it will benefit to Pyflakes and the Flake8 tool too.

-- 
Florent


2014/1/19 Ian Cordasco <graffatcolmingov at gmail.com>:
> If you're going to continue to maintain this fork you should join the
> mailing list so your messages do not need to be moderated.
>
> That said, I have a few points of feedback for you:
>
> Error numbers in tools such as pep8 and pyflakes (although flake8 adds
> them to pyflakes) are usually not made to be entirely successive. For
> the most part, there are groupings of errors. The best explanation of
> this is pep8's documentation:
> http://pep8.readthedocs.org/en/latest/intro.html#error-codes
>
> Anything starting with E1 is related to indentation, anything starting
> with E2 is related to whitespace. These are conceptually classes of
> errors. PyLint also follows this convention if I remember correctly
> and you would do well to do the same. The error codes that Flake8 adds
> to PyFlakes follow that convention as well.
>
> This probably also means that if you're following semver that this
> will be a new major version bump since you're changing how items are
> ignored.
>
> On Sun, Jan 19, 2014 at 9:50 AM, timothy crosley
> <timothy.crosley at gmail.com> wrote:
>> Hi Everyone,
>>
>> I just wanted to let you know, after Pyflakes seemed dead for about 5 months
>> I created a fork called Frosted:
>>
>> https://github.com/timothycrosley/frosted
>>
>> While it seems that Pyflakes is somewhat alive again, In the fork a lot of
>> code has been simplified and a lot of necessary but missing features (such
>> as configuration) have been added. Additionally, I've merged in a lot of
>> improvements from the Pyflakes community at large. I will be working hard to
>> improve Frosted further, and any suggestions / feature improvements that are
>> recommended will be met with enthusiasm :).
>>
>> While, I would be willing to merge the two projects at some later point, I
>> think in the short-term the rapid development and freedom working under a
>> new project name will bring - will be very beneficial. I have added Florent
>> Xicluna and Steven Myint as collaborators on the project, as these are both
>> developers I have high regard for, and remove the possibility of me being
>> the single source of failure for unmerged pull-requests.
>>
>> So if you have time, please check out the project, request features, and
>> make pull requests. Lets make a great Python code checker even better!
>>
>> Thanks!
>>
>> Timothy
>>

From timothy.crosley at gmail.com  Sun Jan 19 23:26:02 2014
From: timothy.crosley at gmail.com (timothy crosley)
Date: Sun, 19 Jan 2014 17:26:02 -0500
Subject: [code-quality] Pyflakes forked to Frosted
In-Reply-To: <CANkC=g1qhXTYd4E6GZWRXxnzruX=KCX49Mn2xNbS4QzJVmtn3A@mail.gmail.com>
References: <CANkC=g3ek+0a-wrTjb0SRhrF86iq8Z4A-7_mgsPMsVngpybpgw@mail.gmail.com>
 <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>
 <CANkC=g1qhXTYd4E6GZWRXxnzruX=KCX49Mn2xNbS4QzJVmtn3A@mail.gmail.com>
Message-ID: <CANkC=g0nqdOmkMXG=d+qL1C0oj=N2NL9izkOGF+Y1OJnqR3WGw@mail.gmail.com>

Just released version 1.1.0 which categorizes as suggested, and includes
many other community driven improvements.

Thanks!

Tim


On Sun, Jan 19, 2014 at 12:00 PM, timothy crosley <timothy.crosley at gmail.com
> wrote:

> Hi Ian,
>
> I do plan on maintaining this fork, and I had just subscribed and verified
> my email. I'm not sure why it still required moderation - is there a
> waiting period? Different subscription modes?
>
> In any case,
> Thanks for the helpful feedback! I will implement this conceptual error
> codes, as I agree it is more logical and standard.
> I am following semantic versioning so it will mean incrementing to new
> major version - but it shouldn't be too big of a deal as frosted does not
> yet have a large group of users.
>
> Thanks!
>
> Timothy
>
>
> On Sun, Jan 19, 2014 at 11:35 AM, Ian Cordasco <graffatcolmingov at gmail.com
> > wrote:
>
>> If you're going to continue to maintain this fork you should join the
>> mailing list so your messages do not need to be moderated.
>>
>> That said, I have a few points of feedback for you:
>>
>> Error numbers in tools such as pep8 and pyflakes (although flake8 adds
>> them to pyflakes) are usually not made to be entirely successive. For
>> the most part, there are groupings of errors. The best explanation of
>> this is pep8's documentation:
>> http://pep8.readthedocs.org/en/latest/intro.html#error-codes
>>
>> Anything starting with E1 is related to indentation, anything starting
>> with E2 is related to whitespace. These are conceptually classes of
>> errors. PyLint also follows this convention if I remember correctly
>> and you would do well to do the same. The error codes that Flake8 adds
>> to PyFlakes follow that convention as well.
>>
>> This probably also means that if you're following semver that this
>> will be a new major version bump since you're changing how items are
>> ignored.
>>
>> On Sun, Jan 19, 2014 at 9:50 AM, timothy crosley
>> <timothy.crosley at gmail.com> wrote:
>> > Hi Everyone,
>> >
>> > I just wanted to let you know, after Pyflakes seemed dead for about 5
>> months
>> > I created a fork called Frosted:
>> >
>> > https://github.com/timothycrosley/frosted
>> >
>> > While it seems that Pyflakes is somewhat alive again, In the fork a lot
>> of
>> > code has been simplified and a lot of necessary but missing features
>> (such
>> > as configuration) have been added. Additionally, I've merged in a lot of
>> > improvements from the Pyflakes community at large. I will be working
>> hard to
>> > improve Frosted further, and any suggestions / feature improvements
>> that are
>> > recommended will be met with enthusiasm :).
>> >
>> > While, I would be willing to merge the two projects at some later
>> point, I
>> > think in the short-term the rapid development and freedom working under
>> a
>> > new project name will bring - will be very beneficial. I have added
>> Florent
>> > Xicluna and Steven Myint as collaborators on the project, as these are
>> both
>> > developers I have high regard for, and remove the possibility of me
>> being
>> > the single source of failure for unmerged pull-requests.
>> >
>> > So if you have time, please check out the project, request features, and
>> > make pull requests. Lets make a great Python code checker even better!
>> >
>> > Thanks!
>> >
>> > Timothy
>> >
>> > _______________________________________________
>> > 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/20140119/07f4a97f/attachment-0001.html>

From kay.hayen at gmail.com  Mon Jan 20 01:04:44 2014
From: kay.hayen at gmail.com (Kay Hayen)
Date: Mon, 20 Jan 2014 01:04:44 +0100
Subject: [code-quality] Error codes (Was: Pyflakes forked to Frosted)
In-Reply-To: <CAN-Kwu3HNP1ymYAeOnnFyEr=vkVMV3mpU159+qT=ESq-85hgXQ@mail.gmail.com>
References: <CAN-Kwu3HNP1ymYAeOnnFyEr=vkVMV3mpU159+qT=ESq-85hgXQ@mail.gmail.com>
Message-ID: <CAMEZBDJQsHkjp-PLmmNVGcQ4nSFpFX_rj_Zznrn9fm+tv2hseg@mail.gmail.com>

Hello Ian,

> Basically, I am saying, why isn't this some kind of standard. And can we
> > make it
> > one.
>
> Standardizing anything is difficult. People rarely agree on anything.
> One way to achieve your standard, however, may be to write a package
> (ideally permissively licensed like Nuitka) that provides formatters
> for the more popular options, i.e., pep8 and pyflakes. Then simply
> encourage those writing similar tools to use that to reduce code
> duplication and possible errors. If your module achieves enough
> popularity, it would then become a de facto standard rather than a
> standard designed by committee.
>

I was not suggesting it any other way. Of course in code.

But thinking of it, that subjective thing bears fruits. But for mere
statements
of facts, I wouldn't worry as much. Of course, already when it makes
suggestions, then likely it is going to be deviating. I for one wouldn't
worry even people use "map" in their code or list contractions. Such
hints could be kept separate from the statement of fact.

I would of course be willing to make the result freely licensed, but that
would require allowance from PyLint.


> Further, you seem to be conflating ideas:
>
> - Message/warning formatting
> - Error code design
>
> The former deals with how the message is printed, while the latter is
> far more semantic in how error codes are assigned. The latter will be
> far harder to codify than even the former. Again a module to help with
> this may work but I would guess that people will be less inclined to
> use it than a module which formats the messages for them.
>

The formatting doesn't matter as much, PyLint now offers an option to
control the output and the colorizing for interactive terminals isn't really
all that hard. It's now even easy to use with Emacs compilation mode.

For the design, yes, that is where I would be the most benefit for my
project, because PyLint messages, that is what people already know
and recognize, and where other people will continue to put more and
more thought into.

Using the same message catalog will also make it easier to compare
the tools.

That said, without such a standard, I would love to follow PyLint in what
it does. There isn't to the user not that much benefit to it doing the same
outputs, they will still use PyLint, but there even more clearly is no
benefit
to using different wordings for the same facts.

Plus, it would then be natural to use the same comments to enabled and
disable messages. The same options to control warnings, and the same
configuration file formats. Lots of benefits to me that will turn out as
benefits to my users as well.

Basically I want to do as little thinking, documenting, heck, I could even
use the tests of PyLint (hoping they exist).

But these benefits can not only apply to me. Shared messages and test
cases must be good for everybody doing this kind of stuff.

Yours,
Kay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20140120/b0cdecb4/attachment.html>

From sylvain.thenault at logilab.fr  Mon Jan 20 09:20:51 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Mon, 20 Jan 2014 09:20:51 +0100
Subject: [code-quality] Pyflakes forked to Frosted
In-Reply-To: <CAMEZBDKk4tV0fkkHVXrpYKT2uvEUNjxn22HG6TFBvzJio_ZBFw@mail.gmail.com>
References: <CANkC=g3ek+0a-wrTjb0SRhrF86iq8Z4A-7_mgsPMsVngpybpgw@mail.gmail.com>
 <CAN-Kwu0VNiX5Be6+9bBRAY6VS19KLpGe1+=EGLthfY_K2tL9kg@mail.gmail.com>
 <CAMEZBDKk4tV0fkkHVXrpYKT2uvEUNjxn22HG6TFBvzJio_ZBFw@mail.gmail.com>
Message-ID: <20140120082051.GE2570@logilab.fr>

On 19 janvier 18:12, Kay Hayen wrote:
> Hello,

Hi,
 
> Error numbers in tools such as pep8 and pyflakes (although flake8 adds
> > them to pyflakes) are usually not made to be entirely successive. For
> > the most part, there are groupings of errors. The best explanation of
> > this is pep8's documentation:
> > http://pep8.readthedocs.org/en/latest/intro.html#error-codes
> >
> > Anything starting with E1 is related to indentation, anything starting
> > with E2 is related to whitespace. These are conceptually classes of
> > errors. PyLint also follows this convention if I remember correctly
> > and you would do well to do the same. The error codes that Flake8 adds
> > to PyFlakes follow that convention as well.
> >
> 
> So for my compiler Nuitka, there are very few warnings so far, mostly
> because
> it is very limited in its tracing abilities, but I am expanding this now,
> and so far
> I was kind of clueless on how to properly format error and warning messages.
> 
> It probably will a while, before I find the need to expand it, but it would
> be good
> to have a common ground, reusable data. For PyLint, these texts seem spread
> out in the variables files.
> 
> Is there an easy way to access the PyLint warning/error message texts. Would
> you be OK with me to grep these out of PyLint or Wiki, and use them under
> ASF2
> in my project as well. I would of course prefer, for these to exist a place
> that makes
> reuse easier.
> 
> Basically, I am saying, why isn't this some kind of standard. And can we
> make it
> one.

as Pylint author I would say it's fine by me but warn that in Pylint we're
slowly but surely moving from numercial ids (E0601, W0402...) to symbolic ids
(bad-indent, bad-name) which carry slightly less information but are much more
easy to read and remember.

-- 
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 zunbeltz at gmail.com  Mon Jan 20 09:17:18 2014
From: zunbeltz at gmail.com (Zunbeltz Izaola)
Date: Mon, 20 Jan 2014 09:17:18 +0100
Subject: [code-quality] pylint and gtk3
In-Reply-To: <20140117130845.GO2604@logilab.fr>
References: <52D7A744.3090002@gmail.com> <20140117064200.GC2604@logilab.fr>
 <52D8F54A.6020101@gmail.com> <20140117094540.GJ2604@logilab.fr>
 <52D8FDF7.8080603@gmail.com> <20140117100558.GL2604@logilab.fr>
 <52D9024C.5040106@gmail.com> <20140117130845.GO2604@logilab.fr>
Message-ID: <52DCDB8E.8050907@gmail.com>

or., 2014.eko urtren 17a 14:08(e)an, Sylvain Th?nault(e)k idatzi zuen:
> do you have the py2gi.py file into astroid/brain ? 

Yes, the file is located in

/usr/local/lib/python2.7/dist-packages/astroid/brain/py2gi.py

-- 
Zunbeltz Izaola


From vijaybaskar08 at gmail.com  Fri Jan 24 10:43:06 2014
From: vijaybaskar08 at gmail.com (VIJAY BASKAR)
Date: Fri, 24 Jan 2014 15:13:06 +0530
Subject: [code-quality] pylint installation
Message-ID: <CAFXTLM=2EtRWPeFTTX_Wbivb34NUyfedBiZmhH-=FCRHNzvhkQ@mail.gmail.com>

Hi,

      I am trying to use pylint for my unit testing. And so I downloaded
the latest patch of pylint from the link "
http://download.logilab.org/pub/pylint/". So when I started running pylint
on my python file, it throws me an error. I have attached the screenshot of
that error page.

     Moreover, should I install the dependencies(astroid and logilab)
manually??
     Or will it be auto-installed when am installing Pylint?

      So please help me out of this. If I have to install the dependencies
too, please send me the links for downloading the dependencies.

  Thanks in advance

Regards,
Vijay A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20140124/29fef48c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error_screenshot.png
Type: image/png
Size: 57948 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/code-quality/attachments/20140124/29fef48c/attachment-0001.png>

From marc at rintsch.de  Fri Jan 24 13:21:23 2014
From: marc at rintsch.de (Marc 'BlackJack' Rintsch)
Date: Fri, 24 Jan 2014 13:21:23 +0100
Subject: [code-quality] pylint installation
In-Reply-To: <CAFXTLM=2EtRWPeFTTX_Wbivb34NUyfedBiZmhH-=FCRHNzvhkQ@mail.gmail.com>
References: <CAFXTLM=2EtRWPeFTTX_Wbivb34NUyfedBiZmhH-=FCRHNzvhkQ@mail.gmail.com>
Message-ID: <52E25AC3.7090405@rintsch.de>

On 24/01/14 10:43, VIJAY BASKAR wrote:

>       I am trying to use pylint for my unit testing. And so I downloaded
> the latest patch of pylint from the link
> "http://download.logilab.org/pub/pylint/". So when I started running
> pylint on my python file, it throws me an error. I have attached the
> screenshot of that error page.

You could have selected just the text in that window and pasted it as
text into the mail.  Smaller mail and less likely to end up in a spam
filter.  :-)

>      Moreover, should I install the dependencies(astroid and logilab)
> manually??
>      Or will it be auto-installed when am installing Pylint?    

This depends on how you have installed Pylint.  If you download the
source manually and do ``python setup.py install`` in the unpacked
directory then you have to install the dependencies manually too.

If you use an installer like ``pip`` then the dependencies will be
automatically resolved/installed.

>       So please help me out of this. If I have to install the
> dependencies too, please send me the links for downloading the dependencies.

My first stop is always the Python package index (pypi):

  http://pypi.python.org/

You'll find the dependencies there and links to download locations, or
you may search for ``pip``, install that, and then use it to (re)install
Pylint including the dependencies.

Ciao,
	Marc 'BlackJack' Rintsch
-- 
?Optimization hinders evolution.?  -- Alan J. Perlis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/code-quality/attachments/20140124/615a2eb9/attachment.sig>

From carl.crowder at gmail.com  Sun Jan 26 21:41:24 2014
From: carl.crowder at gmail.com (Carl Crowder)
Date: Sun, 26 Jan 2014 21:41:24 +0100
Subject: [code-quality] Python2 brackets for print statements (C0325)
Message-ID: <13495955-FF0D-4C3F-B012-7F753976D4FC@gmail.com>

Hi all,

I wanted to canvas your opinion about something.

Currently, if you have a print statement with brackets in Python2, pylint will raise a comment C0325. This is suppressed if "from __future__ import print_statement" is used.

My question is whether or not using print statements with parentheses in python2 should result in a warning. This was brought up as a bug for prospector (see here: https://github.com/landscapeio/prospector/issues/11) and I'm not sure what to decide. On the one hand, without the explicit print function import, the parentheses are superfluous. On the other hand, it is a valid way of making code 2 and 3 compatible. 

My own thoughts are that the correct way of ensuring Python 2 and 3 compatibility is to use the 'from __future__' import, however that's not compatible with 2.5 and lower.

Any thoughts or comments here?

Cheers,
Carl

From s at sashahart.net  Mon Jan 27 04:14:14 2014
From: s at sashahart.net (Sasha Hart)
Date: Sun, 26 Jan 2014 21:14:14 -0600
Subject: [code-quality] Python2 brackets for print statements (C0325)
In-Reply-To: <13495955-FF0D-4C3F-B012-7F753976D4FC@gmail.com>
References: <13495955-FF0D-4C3F-B012-7F753976D4FC@gmail.com>
Message-ID: <CABrLX28=2_L0pf1Y6dU+7frq7YDKKCJXkVs1FDXZ-_yY6JREdg@mail.gmail.com>

I think print(arg) with one argument in python2 should be accepted.
Assuming one argument, the behavior is the same between versions, making
the question all but pointless - but its usefulness for doing single-source
is a strong practical argument for allowing it. The problem comes when you
use 0 or 2+ arguments - print(arg1, arg2) and so on - since these do
generate different behavior between versions. So in an ideal world, when
there is no __future__ import, I think I'd flag print(foo, bar) and print()
but not print(foo).


On Sun, Jan 26, 2014 at 2:41 PM, Carl Crowder <carl.crowder at gmail.com>wrote:

> Hi all,
>
> I wanted to canvas your opinion about something.
>
> Currently, if you have a print statement with brackets in Python2, pylint
> will raise a comment C0325. This is suppressed if "from __future__ import
> print_statement" is used.
>
> My question is whether or not using print statements with parentheses in
> python2 should result in a warning. This was brought up as a bug for
> prospector (see here: https://github.com/landscapeio/prospector/issues/11)
> and I'm not sure what to decide. On the one hand, without the explicit
> print function import, the parentheses are superfluous. On the other hand,
> it is a valid way of making code 2 and 3 compatible.
>
> My own thoughts are that the correct way of ensuring Python 2 and 3
> compatibility is to use the 'from __future__' import, however that's not
> compatible with 2.5 and lower.
>
> Any thoughts or comments here?
>
> Cheers,
> Carl
> _______________________________________________
> 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/20140126/3c485411/attachment.html>

From olivier.cayrol at logilab.fr  Thu Jan 30 16:12:45 2014
From: olivier.cayrol at logilab.fr (Olivier CAYROL)
Date: Thu, 30 Jan 2014 16:12:45 +0100
Subject: [code-quality] Python coding standard checks
In-Reply-To: <20140129171131.0ce79a740feef408fe2d9490db78635d.50a5be962e.wbe@email15.secureserver.net>
References: <20140129171131.0ce79a740feef408fe2d9490db78635d.50a5be962e.wbe@email15.secureserver.net>
Message-ID: <52EA6BED.7070605@logilab.fr>


Dear sir,

Thanks for your interest in pylint. pylint is a free software published
under the terms of the GNU General Public License version 2. I believe
you can find the answers to all your questions inside this license.

http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

If you have any further questions about pylint, you can write to the
mailing list: code-quality at python.org

Regards,

  O. CAYROL.

Le 30/01/2014 01:11, vreddy at baseinfosec.com a ?crit :
> Hi,
>    My name is Varada. I am planning to use Pylint in our framework which
> will be made available commercially. We are in development stage. Please
> let us know what are the things that I need to consider in order to use
> Pylint in our framework.
> 
> Thanks
> Varada

-- 
Olivier CAYROL                       LOGILAB - Paris / Toulouse (France)
                                               Olivier.Cayrol at logilab.fr
Logiciels libres innovants pour le Web et les Sciences |Python  CubicWeb
Innovative free software for Web and Sciences          |SaltStack Debian