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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
