On 20 juin 14:55, Skip Montanaro wrote:
> > I cloned logilab-common, pylint and astroid. Installed in ~/.local,
> > then tried pylint with PYTHONPATH set, but no command line args. No
> > luck:
> >
> ...
> > pkg_resources.DistributionNotFound: logilab-astroid>=0.24.3
>
> I believe I have this fi
> I cloned logilab-common, pylint and astroid. Installed in ~/.local,
> then tried pylint with PYTHONPATH set, but no command line args. No
> luck:
>
...
> pkg_resources.DistributionNotFound: logilab-astroid>=0.24.3
I believe I have this figured out. Pylint appears to be requiring a
package nam
> There is an unused-variable message in the variables checker
> (pylint/checkers/variables.py).
> This is probably worth reading indeed, though in this particular case in
> should rather
> go in the classes checker (pylint/checkers/classes.py).
Thanks for the pointer. I think I have a notion of
On 19 juin 10:41, Skip Montanaro wrote:
> On Wed, Jun 19, 2013 at 2:37 AM, Sylvain Thénault
> wrote:
> > On 07 juin 09:18, Martin Pool wrote:
> >> On 7 June 2013 06:49, Skip Montanaro wrote:
> >>
> >> > If I never refer to self.x or self.y within the class's methods it
> >> > would be nice to be
On 19 June 2013 17:37, Sylvain Thénault wrote:
>
> Hey guys, today is your last chance to contribute this to the pylint 10th
> anniversary sprint ;)
> And to get it in forthcoming 1.0...
>
> Monday and tuesday reports:
> https://www.logilab.org/blogentry/146924
> https://www.logilab.org/blogentry
On Wed, Jun 19, 2013 at 2:37 AM, Sylvain Thénault
wrote:
> On 07 juin 09:18, Martin Pool wrote:
>> On 7 June 2013 06:49, Skip Montanaro wrote:
>>
>> > If I never refer to self.x or self.y within the class's methods it
>> > would be nice to be alerted.
>> >
>>
>> +1, and that seems feasible to add
On 19 juin 06:59, Ned Batchelder wrote:
> I don't think I can make an actual patch, but can I suggest a very
> simple change? This message:
>
> Invalid name "f" for type variable (should match
> [a-z_][a-z0-9_]{2,30}$)
>
> would be simpler and clearer without the word "type". I always read
I don't think I can make an actual patch, but can I suggest a very
simple change? This message:
Invalid name "f" for type variable (should match
[a-z_][a-z0-9_]{2,30}$)
would be simpler and clearer without the word "type". I always read it
first as "f is not a valid name for a type".
On 07 juin 09:18, Martin Pool wrote:
> On 7 June 2013 06:49, Skip Montanaro wrote:
>
> > If I never refer to self.x or self.y within the class's methods it
> > would be nice to be alerted.
> >
>
> +1, and that seems feasible to add to pylint.
Hey guys, today is your last chance to contribute th
On 7 June 2013 09:32, Skip Montanaro wrote:
>
> Correct, but I would just like to be alerted that perhaps I should
> consider narrowing my API. Some of the code base I work on was around
> before Python 2.2 was available. Over time, people have started to
> add property-based setters and getter
>> Here's the other problem I'd like to catch:
>> class X(object):
>> ...
>> def get_foo(self):
>> return self._foo
>> foo = property(get_foo)
>> The problem here is that I have violated this Zen of Python dictum:
>> There should be one-- and preferably o
On 7 June 2013 06:49, Skip Montanaro wrote:
> If I never refer to self.x or self.y within the class's methods it
> would be nice to be alerted.
>
+1, and that seems feasible to add to pylint.
>
> Here's the other problem I'd like to catch:
> class X(object):
> ...
> def get_
These features may already be possible with some tools. If so,
pointers appreciated.
When a class evolves over a long period of time, it's quite possible
for methods or data attributes to fall into disuse. While I realize
that attributes which don't start with an underscore are implicitly
part o
13 matches
Mail list logo
