__slots__

[Antoon Pardon]

Op 2006-03-27, Georg Brandl schreef <g.brandl-nospam at gmx.net>:
> Antoon Pardon wrote:
>> Op 2006-03-25, John J. Lee schreef <jjl at pobox.com>:
>>> aleaxit at yahoo.com (Alex Martelli) writes:
>>> [...]
>>>> you should be using pychecker or pylint
>>> [...]
>>>
>>> I'm curious, as somebody who doesn't regularly use these tools: How do
>>> they fit into your workflow?  Do you run them every few hours, every
>>> day, every time you run functional tests, every release, every so
>>> often, on gut feeling about when it's likely to catch problems...?
>>>
>>> How do you cope with spurious warnings?  Does it involve tweaking code
>>> to quell warnings?  Keeping suppression lists?  Maintaining special
>>> invocations of pychecker / pylint per-project?  Do they cope well with
>>> other people's code who do not use these tools?
>> 
>> IMO they don't cope well unless you adapt to what they expect.
>> 
>> I just tested the two.
>> 
>> pylint gave me countless warnings because I use two space to indent
>> instead of four. It also didn't like that I used uppercase letters
>> in my identifiers. That there was no space after a comma or
>> around an operator was a problem too.
>
> Pylint knows different types of issues, these are "code style" issues
> and can be
>  - turned off
>  - configured to what you like.
> They help getting your coding style consistent and default to PEP8 style.

I have been on their website in the documentation section and found
nothing that could easily help me here.

>> That I use the same name for the index variable of for loops in
>> different scopes is also warned about.
>
> Well, everything that _could_ be problematic _or_ confuse a reader is
> warned about. Pretty good in my eyes.

No it isn't. If most of these line are in fact not problematic
or confusing at all then people will in general no longer
take notice of those kind of lines.

If I use a specific variable like "i" only as an index in for
loops, there is no reason to think this is problematic or confusing
even if those loops are in different scopes. And all those lines
reporting something that is not a problem will detract from the
few lines that may be a real problem.

>> Pychecker also warns about these shadowed variable. Pychecker
>> goes even so far to warn you that a local variable in an imported
>> module is shadowing a global variable of yours. Like the following
>> line:
>> 
>> /usr/lib/python2.3/random.py:247: Local variable (i) shadows global
>> defined on line 43 in file demo1a.py
>
> That's odd. How are the two modules related?

the program demo1a.py contains the following line:

  from random import Random, randint, sample

>
>> So it seems pychecker thinks I shouldn't use something like
>> 
>> for i in lst:
>>   ...
>> 
>> in my code at the global level because some module in the standard
>> library has a function with a local i.
>> 
>> Pychecker also froze on my system.
>
> Pychecker imports the modules. Thus these things can happen when a
> module expects not to be imported as-is.

I still find it unacceptable.

-- 
Antoon Pardon