On 1/14/07, Jeff Hinrichs - DM&T <[EMAIL PROTECTED]> wrote:
On 1/14/07, goff <[EMAIL PROTECTED]> wrote:
>
> Point taken. I must admit that I rather concentrated on getting the
> score up than on submitting bugs and patches to TG, but I think the
> work was not wasted. I really think that a standard quickstart project
> should come with a pylint level of 10/10, and although it doesnt say so
> explicitly the current topic shows the way for that.
>
> For R0201 (looks like function): I cant see why controller classes
> should access their self at all, that's why I decided to disable that
> warning. It would be nice if pylint could read its settings not only
> from a rc file but from the parsed file too. Thus one could disable
> certain warnings for specific files (like R0201 for controllers)
>
> For the rest of your comments: Your probably right (except for spaces
> instead of tabs of course :-) ), that's why it's a wiki page: go ahead
> and fix it!
>
> If time permits I'll try to build a  patchset against TG 1.0 to get the
> quickstart projects a shiny pylint level of 10.
>
> Best regards,
>
> mfg
>
>
> > goff,
I misspoke when I boasted that I had model.py linting out at 10.  The
true score I've attained is 5.74/10.  mea culpa!

R0201 - agreed for controllers but not all classes in general.
I've emailed pylint's developer to ask about the possibility of adding
a feature where you could turn off a specific warning/error/etc for a
specific line.  To quiet messages like R0904 too many public methods.
Anything that subclasses SQLObject will set that off, but it still
could be a helpful message in another part of my code.  Same for
invalid name messages for sqlmeta and the the "has no" errors for
things like by_visit_key and _SO_set_password.
(see my pps below for good news about this)

Googling pylint turned up a link to pylint integrated into eclipse and
the ability to "in-line" ignore statements for a given line and
warning without turning them off globally.

As for the wiki, I wasn't comfortable editing it until there was a
chance for discussion here on the list, so that we could come to a
consensus before I made edits to your contributions.  My opinion
carries no more weight than anyone else's.  And at this point, I
haven't linted enough of TG to have more than opinion.<g>

-jeff

p.s. I agree with your desire to have a quickstart project lint out at
10 -- but there will be some work between here and there.

pps. More googling has resulted in finding how to disable a specific
message(s) for a specific line.  For instance:
...
class User(orm.SQLObject):  #pylint: disable-msg=R0904
    ...
disabled the "too many public methods" message for the User class.
While still leaving the message for the rest of the code.  So we can
explicitly quiet a message for a specific section of code.  Nothing we
can do about the number of public methods in an SQLObject so that is a
valid reason to squelch that particular message.

So it looks like we can refactor first and then explicitly silence
those things that are beyond TG's control.

As an exercise, I've uploaded an example of model.py that pylints out
to 10 using the default configuration for pylint and in-line
suppression of specific occurrences of messages.

http://paste.turbogears.org/paste/851

Those things that are under the direct influence of TG project have
been refactored and those things outside the sphere (sqlobject) have
been explicitly masked with in-line suppressions.

I will note that the sqlmeta for the Visit class appears to be
unnecessary.  (Lines 23-28 in the pasted example)  This would be a
candidate for removal to refinish the refactoring, but beyond the
scope of the current exercise.

Comments?

-Jeff

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to