From skip at pobox.com Tue Apr 1 21:59:45 2014 From: skip at pobox.com (Skip Montanaro) Date: Tue, 1 Apr 2014 14:59:45 -0500 Subject: [code-quality] Warning from pylint about its own code? Message-ID: Lately, whenever I run pylint, I get this warning: /opt/local/lib/python2.7/site-packages/pylint/reporters/text.py:79: UserWarning: parseable output format is deprecated. This is equivalent to --msg-template={path}:{line}: [{msg_id}({symbol}), {obj}] {msg} 'to --msg-template=%s' % (self.name, self.line_format)) Thinking my 1.0.0 install was just out-of-date, I just updated to 1.1.0, but I continue to get this warning. Here are my details (note the message appears there as well): % pylint --version /opt/local/lib/python2.7/site-packages/pylint/reporters/text.py:79: UserWarning: parseable output format is deprecated. This is equivalent to --msg-template={path}:{line}: [{msg_id}({symbol}), {obj}] {msg} 'to --msg-template=%s' % (self.name, self.line_format)) pylint 1.1.0, astroid 1.0.0, common 0.60.0 Python 2.7.2 (default, Nov 14 2012, 05:07:35) [GCC 4.4.6 [TWW]] Is this something I'm doing wrong? I didn't find ParseableTextReporter mentioned anywhere except for the class definition. My ~/.pylintrc and ~/.pylint.d files/directories are similarly devoid of references. Clues appreciated. Thx, Skip From skip at pobox.com Tue Apr 1 22:05:18 2014 From: skip at pobox.com (Skip Montanaro) Date: Tue, 1 Apr 2014 15:05:18 -0500 Subject: [code-quality] Warning from pylint about its own code? In-Reply-To: References: Message-ID: > Lately, whenever I run pylint, I get this warning: > > /opt/local/lib/python2.7/site-packages/pylint/reporters/text.py:79: > UserWarning: parseable output format is deprecated. This is equivalent > to --msg-template={path}:{line}: [{msg_id}({symbol}), {obj}] {msg} > 'to --msg-template=%s' % (self.name, self.line_format)) Okay, I see where I've gone wrong. I have output-format=parseable in pylintrc. I was searching everywhere for the name of the class. Skip From keith.derrick at lge.com Thu Apr 17 01:12:39 2014 From: keith.derrick at lge.com (Keith Derrick) Date: Wed, 16 Apr 2014 19:12:39 -0400 Subject: [code-quality] Is the pep8-naming project moribund? Message-ID: <534F0E67.4040107@lge.com> There are numerous issues open, and at least one pull-request (mine). there has been no activity by the owner for at least a year. Right now the official pypi version (2.2.1) is broken for Python 3.4. My PR (https://github.com/flintwork/pep8-naming/pull/11) is working well for me in my own fork, but I'm working up a library of my own and don't want to use my fork as an installation requirement when I finally publish to pypi. How do we re-invigorate the project? And, out of curiosity, if the owner of a published package has 'gone away' (i.e. abandoned the project), how does someone else take it over? Forking is easy enough, but you would eventually need to publish the new version on pypi. Is that protected (so that people can't hijack a trusted package like paramiko or pycrypto, for example)? It could be always be published with a different package name, but then existing users don't get the bug-fix automatically. Keith From florent.xicluna at gmail.com Thu Apr 17 01:45:29 2014 From: florent.xicluna at gmail.com (Florent) Date: Thu, 17 Apr 2014 01:45:29 +0200 Subject: [code-quality] Is the pep8-naming project moribund? In-Reply-To: <534F0E67.4040107@lge.com> References: <534F0E67.4040107@lge.com> Message-ID: Hello, thank you for your interest in this project. Actually, I've created the pep8-naming package one year ago as a proof-of-concept for a pep8 extension. It evolved quickly as the first extension to flake8 2.0. At this time I declared that I don't intend to maintain it, and I asked for a volunteer to continue the effort : https://github.com/jcrocholl/pep8/issues/44#issuecomment-14000874 So I welcome you on-board, and I just gave you write access to the repository. -- Florent 2014-04-17 1:12 GMT+02:00 Keith Derrick : > There are numerous issues open, and at least one pull-request (mine). > there has been no activity by the owner for at least a year. > > Right now the official pypi version (2.2.1) is broken for Python 3.4. My > PR (https://github.com/flintwork/pep8-naming/pull/11) is working well > for me in my own fork, but I'm working up a library of my own and don't > want to use my fork as an installation requirement when I finally > publish to pypi. > > How do we re-invigorate the project? > > And, out of curiosity, if the owner of a published package has 'gone > away' (i.e. abandoned the project), how does someone else take it over? > Forking is easy enough, but you would eventually need to publish the new > version on pypi. Is that protected (so that people can't hijack a > trusted package like paramiko or pycrypto, for example)? It could be > always be published with a different package name, but then existing > users don't get the bug-fix automatically. > > Keith > _______________________________________________ > code-quality mailing list > code-quality at python.org > https://mail.python.org/mailman/listinfo/code-quality From keith.derrick at lge.com Thu Apr 17 15:40:41 2014 From: keith.derrick at lge.com (Keith Derrick) Date: Thu, 17 Apr 2014 09:40:41 -0400 Subject: [code-quality] Is the pep8-naming project moribund? In-Reply-To: References: <534F0E67.4040107@lge.com> Message-ID: <534FD9D9.7090408@lge.com> Yep, guess I asked for that Keith Derrick | Manager Core OS Platform and SCM/Build | Engineering LG Silicon Valley Lab | 5150 Gt America Parkway, Santa Clara, CA 95054 Office: 408.610-5746 | Mobile: 831.383.9567 | LG.com On 04/16/2014 04:45 PM, Florent wrote: > Hello, > > thank you for your interest in this project. > > Actually, I've created the pep8-naming package one year ago as a > proof-of-concept for a pep8 extension. > It evolved quickly as the first extension to flake8 2.0. > > At this time I declared that I don't intend to maintain it, and I > asked for a volunteer to continue the effort : > https://github.com/jcrocholl/pep8/issues/44#issuecomment-14000874 > > So I welcome you on-board, and I just gave you write access to the repository. > > From sylvain.thenault at logilab.fr Tue Apr 22 12:03:39 2014 From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=) Date: Tue, 22 Apr 2014 12:03:39 +0200 Subject: [code-quality] =?utf-8?q?=5BANN=5D=C2=A0Pylint_1=2E2_released?= Message-ID: <20140422100339.GA9494@logilab.fr> Hi there, Pylint 1.2 has been uploaded to pypi by the end of the last week! More info on this heavy release on http://www.logilab.org/blogentry/240019. As usual, feedback and comments welcome. Enjoy! -- 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 skip at pobox.com Wed Apr 23 15:44:02 2014 From: skip at pobox.com (Skip Montanaro) Date: Wed, 23 Apr 2014 08:44:02 -0500 Subject: [code-quality] Alerting to unused module globals, instance attributes, etc? Message-ID: If I write a standalong script/program, it looks just like a module to the outside world (as long as I name it correctly), though it might have a #! line at the top. Otherwise, to a static analyzer, it still looks like a module, which means anything it defines might be visible from the outside. Consequently, if I happen not to use module globals or instance attributes, tools like pylint won't complain. I think it would be nice if I could tell such tools either: 1. The thing I'm feeding you is a standalone program. Nobody else might reference this stuff, so complain about unused names. 2. This particular thing I'm defining is either public or private. So, if I have this block of "constants": ONE_SECOND = 1000 # ms ONE_MINUTE = 60 * ONE_SECOND ONE_HOUR = 60 * ONE_MINUTE ONE_SECOND_DELTA = datetime.timedelta(seconds=1) ONE_MINUTE_DELTA = datetime.timedelta(minutes=1) ONE_DAY_DELTA = datetime.timedelta(days=1) ONE_YEAR_DELTA = 365 * ONE_DAY_DELTA EPSILON = 1e-10 it would be nice if I was told if any were unused. Similarly, if an attribute of a class is defined but not used elsewhere within the class (or perhaps within the defining module), I'd like to know if it's unused. At a minimum, if I've defined an instance method with a leading underscore in its name, it would be real nice if I was told about lack of use within the class. For classes where most of the API is public, it might be nice to mark the class as public then explicitly mark any private attributes: # public class Point: def __init__(self): self.x = self.y = 0.0 # private self.r = self.theta = 0.0 # private def convert_to_polar(self): self.r = math.sqrt(self.x**2 + self.y**2) self.theta = math.atan2(self.y, self.x) Do any existing static analysis tools support anything like this? I'm certainly not married to the notion of annotating attributes. Also, I should note that I am still using Python 2.7. If there are any features of Python 3 that facilitate this, I'd love to hear about it. Thx, Skip From indigo at bitglue.com Wed Apr 23 16:28:12 2014 From: indigo at bitglue.com (Phil Frost) Date: Wed, 23 Apr 2014 10:28:12 -0400 Subject: [code-quality] Alerting to unused module globals, instance attributes, etc? In-Reply-To: References: Message-ID: <5357CDFC.6040206@bitglue.com> On 04/23/2014 09:44 AM, Skip Montanaro wrote: > [...] > So, if I have this block of "constants": > > ONE_SECOND = 1000 # ms > ONE_MINUTE = 60 * ONE_SECOND > > it would be nice if I was told if any were unused. > > [...] it might be nice to mark the > class as public then explicitly mark any private attributes: > [...] > Do any existing static analysis tools support anything like this? pyflakes does exactly this first thing: tells you if any names are unused. It does this the same way whether you are writing a module or a stand-alone program. It requires modules which wish to expose constants and such to declare them explicitly in __all__. It does not have any mechanism for "private" versus "public" class or instance attributes, because it is difficult to tell if they are used or not by anything short of running the program. Reflect: __metaclass__ = OhNoes class Foo: bar = 1 def __init__(self): self.baz = 2 def frob(self): if moon_phase() > 0.5: self = 15 print self.baz Rather than make guesses that are right 90% of the time and yield 10% false positives, pyflakes takes the PEP 20 approach: """ In the face of ambiguity, refuse the temptation to guess. """ It is the opinion of pyflakes that determining the correctness of your program in such complex situations is better served by unit tests. From skip at pobox.com Wed Apr 23 17:39:13 2014 From: skip at pobox.com (Skip Montanaro) Date: Wed, 23 Apr 2014 10:39:13 -0500 Subject: [code-quality] Alerting to unused module globals, instance attributes, etc? In-Reply-To: <5357CDFC.6040206@bitglue.com> References: <5357CDFC.6040206@bitglue.com> Message-ID: On Wed, Apr 23, 2014 at 9:28 AM, Phil Frost wrote: > Rather than make guesses that are right 90% of the time and yield 10% > false positives, pyflakes takes the PEP 20 approach: ... > It is the opinion of pyflakes that determining the correctness of your > program in such complex situations is better served by unit tests. Thanks for the response. How would a unit test tell me a particular method or data attribute is unused within the module? And if the attribute used to be used, but no longer is (and should be deleted to ease maintenance), does a unit test keep it alive? The main Python code base I work with is now more than 10 years old, and was not designed at the outset to easily support the creation of unit tests. (Numbers-wise, it's nearly 50kloc in over 200 Python files.) It also grew organically as requirements and focus of the code changed. I'm sure there's now a ton of unused code in there I could just discard. Finding it can be a challenge. Just because an attribute isn't used within a module doesn't mean it's dead, but in certain situations it would be nice if a checker could at least warn me, "hey, I see that you assigned to 'self.foo', but I don't see any obvious uses of that attribute within the class or module." I would be more than happy with a 90% hit rate on such stuff. I don't care about perfection here. I don't care about the craziness of assigning something bizarre to "self" or use of getattr and its cousins. I also would be happy if I needed to set a config variable or add a command line flag to enable such behavior. And if we are using the Zen of Python as our guide: Special cases aren't special enough to break the rules. Although practicality beats purity. I'm looking for practicality here, not purity. Skip