Sylvain Thénault | 3 Jan 10:23 2011
Picon

Re: pylint thinks tab is 2 spaces

On 21 décembre 12:02, Marijn Schouten wrote:
> Hi,

Hi,

> pylint-0.22.0 thinks tab is 2 spaces, causing carets to be in the
> wrong place. I've created a small testfile with a tab character on the second
> line and a style issue:
> 
> $ cat linttest.py
> def f():
>         i=1
> 
> Notice that pylints output includes a line with the single character '^' which
> should point to the '=' character in the line above, but doesn't do so, because
> pylint has indented it by 2 spaces instead of a tab.
> 
> $ pylint --reports=n linttest.py 
> No config file found, using default configuration
> ************* Module linttest
> W:  2: Found indentation with tabs instead of spaces
> C:  1: Missing docstring
> C:  1:f: Invalid name "f" (should match [a-z_][a-z0-9_]{2,30}$)
> C:  1:f: Missing docstring
> C:  2:f: Operator not preceded by a space
>         i=1
>   ^
> W:  2:f: Unused variable 'i'

would you please file a ticket on the pylint project page for this pb?
(Continue reading)

Sylvain Thénault | 3 Jan 10:54 2011
Picon

Re: Warn about unused instance attributes?

Hi Skip,

On 30 décembre 13:45, skip <at> pobox.com wrote:
> Is it possible to set a flag for pylint so that it will complain about
> instance attributes which appear to be unused within the methods defined by
> the class?  If we were examining local variables, a typo might well result
> in one or two messages (unused or undefined).  I'd like similar protection
> for instance attributes.  I realize that lack of use is not necessarily
> incorrect, but it might well suggest a problem.  False positives are fine.
> It's probably not something I would enable all the time.

everything is possible :) And I agree this could be interesting, as well
as variation on this (eg, class, function, etc... unused).
Would you file a ticket for this so we don't forget it?

--

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
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

_______________________________________________
Python-Projects mailing list
Python-Projects <at> lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
Sylvain Thénault | 3 Jan 11:07 2011
Picon

Re: Patch required for epylint on Windows

On 30 novembre 11:51, vijayendra bapte wrote:
> Hi,

Hi,

> I have configured epylint for Emacs on my Windows machine. But I have made a
> small change in
> Python26/Lib/site-packages/pylint-0.21.0-py2.6.egg/pylint/epylint.py and now
> epylint is working fine for me.
> 
> Herewith I have attached a .diff file so that you can verify the patch and
> include it in next release.

patch applied, thanks.

--

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
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

_______________________________________________
Python-Projects mailing list
Python-Projects <at> lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
vijayendra bapte | 4 Jan 05:57 2011
Picon

Re: Patch required for epylint on Windows

Thanks Sylvain.

-Vijayendra.

On Mon, Jan 3, 2011 at 3:37 PM, Sylvain Thénault <sylvain.thenault <at> logilab.fr> wrote:
On 30 novembre 11:51, vijayendra bapte wrote:
> Hi,

Hi,

> I have configured epylint for Emacs on my Windows machine. But I have made a
> small change in
> Python26/Lib/site-packages/pylint-0.21.0-py2.6.egg/pylint/epylint.py and now
> epylint is working fine for me.
>
> Herewith I have attached a .diff file so that you can verify the patch and
> include it in next release.

patch applied, thanks.

--
Sylvain Thénault                               LOGILAB, Paris (France)
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


_______________________________________________
Python-Projects mailing list
Python-Projects <at> lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
Chris Torek | 4 Jan 16:08 2011
Picon

astng patches to make object.__new__ work with pylint on python2.5

I don't know if any of this is needed for later versions of python,
but I have an old Python 2.5 installation, and running pylint on
code using __new__ instead of __init__ in class definitions
resulted in complaints like this:

    ************* Module pylinttest
    E: 10:PylistTest.show: Instance of 'PylistTest' has no 'arg' member

when the contents of pylinttest.py are:

    "doc"
    class PylistTest(object):
	"doc"
	def __new__(cls, arg):
	    self = object.__new__(cls)
	    self.arg = arg
	    return self
	def show(self):
	    "doc"
	    print 'self.arg =', self.arg
	def another(self):
	    "doc"
	    pass

This turned out to be due to two things:

  - the builtin module scanner tossed out functions like __new__
    because their module names come up as "None":

    Python 2.5.1 (r251:54863, Sep  1 2010, 22:03:14)
    [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> print object.__new__.__module__
    None
    >>>

  - Having worked around that, a call to object.__new__ resulted
    in an "unbound method" instance that had no way to look at
    the supplied argument (cls) and extract it back from the
    original arguments (cls,arg).  This was easy enough to add
    although the method I used is not particularly pretty.

Having fixed that, no changes to pylint were required: running
pylint on the test file now gets a 10/10 score for the 10
analyzed statements.

Here's the (rather lightly tested -- I ran it over more than
just the above example, but not over a lot of code) patch.

Chris

From c313da803ed2b2e676b6cad472874e41af998ac8 Mon Sep 17 00:00:00 2001
From: Chris Torek <chris.torek <at> gmail.com>
Date: Tue, 4 Jan 2011 07:43:07 -0700
Subject: [PATCH] handle builtin object.__new__

The builtin object.__new__ function takes a class and returns
an object of that type, i.e., we should infer the result has
whatever type we can find from the first argument.

To make this work (with Python2.5 at least), we need to note
that built in functions whose __module__ is None are really
in the __builtin__ module.
---
 logilab/astng/bases.py   |    9 +++++++++
 logilab/astng/builder.py |    2 ++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/logilab/astng/bases.py b/logilab/astng/bases.py
index f03a13e..5b6fec5 100755
--- a/logilab/astng/bases.py
+++ b/logilab/astng/bases.py
 <at>  <at>  -264,6 +264,15  <at>  <at>  class UnboundMethod(Proxy):
             return iter((self._proxied,))
         return super(UnboundMethod, self).igetattr(name, context)

+    def infer_call_result(self, caller, context):
+        # If we're unbound method new of builtin __object__,
+        # the result is the class (the single argument).
+        frame = self._proxied.parent.frame()
+        if (self._proxied.name == '__new__' and
+                frame.qname() == '__builtin__.object'):
+            return caller.args[0].infer()
+        raise InferenceError()
+

 class BoundMethod(UnboundMethod):
     """a special node representing a method bound to an instance"""
diff --git a/logilab/astng/builder.py b/logilab/astng/builder.py
index 7aa0f24..a58f016 100755
--- a/logilab/astng/builder.py
+++ b/logilab/astng/builder.py
 <at>  <at>  -199,6 +199,8  <at>  <at>  class ASTNGBuilder:

     def _member_module(self, member):
         modname = getattr(member, '__module__', None)
+        if modname is None:
+            modname = '__builtin__'
         return self._dyn_modname_map.get(modname, modname)

--

-- 
1.7.0.3
Sylvain Thénault | 5 Jan 14:58 2011
Picon

Re: astng patches to make object.__new__ work with pylint on python2.5

On 04 janvier 08:08, Chris Torek wrote:
> I don't know if any of this is needed for later versions of python,
> but I have an old Python 2.5 installation, and running pylint on
> code using __new__ instead of __init__ in class definitions
> resulted in complaints like this:
[snip] 
> Here's the (rather lightly tested -- I ran it over more than
> just the above example, but not over a lot of code) patch.

Nice :) I've checked in a slightly improved version of your patch which
suffered from two problems:

* infer_call_result should actually return an Instance of the class, not
  the class itself
* it should fallback to _proxied.infer_call_result if the 'if' branch is
  not matched.

Also, I've added some basic test based on your example.

Good work anyway, thanks a lot.
--

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
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

_______________________________________________
Python-Projects mailing list
Python-Projects <at> lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
Sylvain Thénault | 5 Jan 19:18 2011
Picon

Re: Pylint doesn't find modules even if they are in the pythonpath

On 16 décembre 11:42, Naty Bidart wrote:
> Hi Sylvian,

Hi,

(sorry for the long delay, I've been in holidays for a while)

> Thanks for your answer. Even using the --init-hook swicth I can not
> make pylint notice the ubuntuone modules, as I can show you here:
> 
> nessita <at> dali:~/canonical/u1/cp/trunk$ pylint --init-hook="import
> ubuntuone" ubuntuone/controlpanel/dbus_client.py
> 
> ************* Module ubuntuone.controlpanel.dbus_client
> F0401: 27: Unable to import 'ubuntuone.clientdefs'
> E0611: 27: No name 'clientdefs' in module 'ubuntuone'
> F0401: 28: Unable to import 'ubuntuone.platform.linux'
> E0611: 28: No name 'platform' in module 'ubuntuone'
> F0401: 29: Unable to import 'ubuntuone.platform.linux.tools'
> E0611: 29: No name 'platform' in module 'ubuntuone'

too bad :(

> May I ask why the patch submitted in
> http://www.logilab.org/ticket/8796 has not been merged or used?

because no one found the time to ensure the patch isn't breaking some
other things that currently work.

Making pylint able to understand the python import machinery and its
extensions (eg zip, eggs file & co) *without actually import things*
is definitly a mess. We'll have to do something as some point since
it is higly desirable, though we don't use that features at Logilab
so other things usually take priority other it.

--

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
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

_______________________________________________
Python-Projects mailing list
Python-Projects <at> lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
Jürgen Hermann | 10 Jan 13:00 2011
Picon

Re: Pylint doesn't find modules even if they are in the pythonpath

sylvain.thenault <at> logilab.fr: " Making pylint able to understand the python import machinery and its
extensions (eg zip, eggs file & co) *without actually import things*
is definitly a mess. We'll have to do something as some point since
it is higly desirable, though we don't use that features at Logilab
so other things usually take priority other it. "

Hi, how about isolating pseudo-import machinery in pylint into a single interface (class) and make the
implementation to be used configurable in pylint.rc? I.e. something like "importer =
pylint.importing:DefaultImporter". This would allow easy 3rd party experimentation outside of the
core code (until a stable alternative version can be contributed back), and also has no impact on people
not needing such features.
Julien Jehannet | 10 Jan 13:41 2011
Picon

Re: logilab-common 0.53.0 and pylint 0.22.0 packages failed to build as RPM

Hello Pete,

> * Hans-Peter Jansen <hpj <at> urpla.net> [10-janv.-2011 09:25]:
> 
> while setup.py claims, it had compiled the files under test/data, 
> they're missing in the build dir and hence, in the final 
> installation?!? Does they appear in your local installations?

Not sure but try to comment `include_dirs` in __pkginfo__.py.
We did a rmtree that must be too intrusive in install class.

> (...)
> The other question is, how much sense does compiling the test cases make 
> (especially the failed ones..)?

I think it's to be able to run 2to3.py hook automatically in build
process. Note there should be no failed ones ;-)

FYI, I will work on RPM version of Logilab packages in few days.
Don't hesitate to ping me for another issues.
--

-- 
Julien JEHANNET                                          LOGILAB, Paris (France)
http://www.cubicweb.org                 CubicWeb, le cadriciel du web sémantique
http://www.logilab.org             Dépôt des logiciels libres conçus par Logilab
http://www.logilab.fr       Informatique scientifique & Gestion de connaissances
_______________________________________________
Python-Projects mailing list
Python-Projects <at> lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
Sylvain Thénault | 10 Jan 14:31 2011
Picon

Re: Pylint doesn't find modules even if they are in the pythonpath

Hi,

On 10 janvier 13:00, Jürgen Hermann wrote:
> sylvain.thenault <at> logilab.fr: " Making pylint able to understand the python import machinery and its
> extensions (eg zip, eggs file & co) *without actually import things*
> is definitly a mess. We'll have to do something as some point since
> it is higly desirable, though we don't use that features at Logilab
> so other things usually take priority other it. "
> 
> Hi, how about isolating pseudo-import machinery in pylint into a single interface (class) and make the
implementation to be used configurable in pylint.rc? I.e. something like "importer =
pylint.importing:DefaultImporter". This would allow easy 3rd party experimentation outside of the
core code (until a stable alternative version can be contributed back), and also has no impact on people
not needing such features.

I would be fine with such a solution. 

--

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
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

_______________________________________________
Python-Projects mailing list
Python-Projects <at> lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects

Gmane