On Wed, Apr 9, 2008 at 12:43 PM, Dick Moores <[EMAIL PROTECTED]> wrote: > I'd never used Pylint until yesterday, when I discovered that Ulipad > had a Pylint plugin that enabled me to run Pylint on scripts within > Ulipad. But I'm wondering about some of the results. I noticed that > it was complaining that my variable names violated convention. Here's > an image of running Pylint on a script with only 7 lines: > <http://www.rcblue.com/Misc/PylintInUlipad.jpg> > > Since when is 'az' a bad variable name? And 'AZ' is OK?
Note: I've never used pylint before, so this is all speculation based on a bit of reading of the pylint web page[1] and PEP 8 [2]. In your code snippet, az is a global variable. Pylint has a regular expression that determines if a global variable name matches your coding convention. By default, that regex is (([A-Z_][A-Z1-9_]*)|(__.*__))$. At a guess, that's because pylint's author believes the only global variables you should have are psuedo-constants, and that they should have all uppercase names. That seems reasonable to me, if a bit strict. That particular check does not line up with the PEP 8 coding conventions, which just suggest that global variables follow the same naming rules as functions. I haven't gone through pylint in a lot of detail, but it looks like most of the other regular expressions are designed to default to the PEP 8 coding style conventions, or something close to them. If your coding conventions are different from the defaults pylint assumes, you'll probably need to do some setup. > And I tried Pylint on an official Python module file, calendar.py. > Look what I got when all the checkboxes are > checked!!: <http://www.rcblue.com/Ulipad/PyLintOnCalendar.py.jpg> > > Comments? Most of that looks like valid complaints about calendar.py. The one exception that jumps out at me is the warning about a relative import from __future__. At lot of the other warnings probably depend on the context. For instance, the single-character variable names are ugly, but if they're used inside a loop or a list comprehension they are probably fine. Other than the fact that it's a long list, did *you* have any comments? You present this list like it's a bad thing, but it seems to me that pylint is doing exactly what it should. Do you think that there's something wrong with pylint? Are you just surprised that calendar.py doesn't adhere to pylint's coding guidelines? 1: http://www.logilab.org/card/pylintfeatures 2: http://www.python.org/dev/peps/pep-0008/ _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor