Email RE: [Python-projects] PyLint results

Sylvain -

Here is the pyparsing module in its entirety, you should be able to see the Line too long problem in the docstring right at the top.

-- Paul


-----Original Message-----
From: Sylvain.Thenault@logilab.fr [mailto:Sylvain.Thenault@logilab.fr]
Sent: Tuesday, August 24, 2004 3:11 AM
To: Alexandre
Cc: python-projects@lists.logilab.org; paul@alanweberassociates.com
Subject: Re: [Python-projects] PyLint results


On Monday 23 August à 08:53, Alexandre wrote:
> On Sun, Aug 22, 2004 at 11:24:22PM -0500, paul@alanweberassociates.com wrote:
>  
> > Here are some comments:
> > 
> > W: 29: Line too long (1409/80)
> > Actually, this line is defined using a """'ed string.  The string is
> > probably about 1400 characters long, but I assure you it is broken up
> > across multiple lines!
> 
> Looks like a bug to me. We'll look into this. 

I can't reproduce this one. Would you send a small file demonstrating
the problem ?
 
> > W371 - Many complaints about my variable names, using mixed lower and
> > upper case (also known as "camel case") - PyLint really shouldn't
> > complain about variable and method names such as "setName",
> > "setDebug", etc.  but the regexp used to test the names does not allow
> > capital letters.  I modified base.py to use the following regexps:
> > FUNC_NAME_RGX = re.compile('[a-z_][a-zA-Z0-9_]*$')
> > METH_NAME_RGX = re.compile('[a-z_][a-zA-Z0-9_]*$')
> > VAR_NAME_RGX = re.compile('[a-z_][a-zA-Z0-9_]*$')
> 
> This is part of Logilab's coding standard. Pylint was originally written
> to help us enforce it in our projects. You can customize it using 
> --function-rgx, --method-rgx, --variable-rgx with the suitable regular
> expressions. The --generate-rcfile option will pring a configuration
> file to standard output based on the current command line options, and
> will save you typing and frustration for the following runs. 
 
yep, you should just be able to customize it for your needs without
modifying the code.
 
> > E: 96:ParseException.__str__: Access to undefined member 'column'
> > 'column' is actually a pseudo-attribute, handled in a custom
> > __getattr__ method.  Not sure how you would test for this, but it
> > isn't really an error in my code.
> 
> Hmm, there is actually no way for pylint to know this. we could check
> for the existance of the __getattr__ method and lessen the Error to a
> Warning. 
 
I think it should stay as it is to discourage the use of __getattr__ /
__getattribute__ black magic, which really make the code more difficult
to understand. If you don't want the error, you can disable this check,
globally or just for one or more modules.
 
> > Overall, I got a 6.90 score.  Too many complaints for not leaving
> > spaces after my commas, I guess...
> 
> 6.90 is not too bad. Pylint can give out negative scores :-)
> 
> If you don't like spaces after commas, I'm pretty sure there's an option
> somewhere, though I can't find it right now (and though I realy thin it
> improves readability). 

hum, this part is too complex to configure for now, so you can only
disable it.

-- 
Sylvain Thénault                               LOGILAB, Paris (France).

http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org