lint for Python?

[Bruno Desthuilliers]

Pat a écrit :
> Bruno Desthuilliers wrote:
>> Pat a écrit :

(snip)

>>>  How you catch these types of errors?
>>
>> Just like any other type of errors : testing, testing, and then add 
>> some more tests.
>>
> 
> I haven't gotten into unittesting.  I've just started learning Python.
> 
> It also dawned on me why my original question is a bit lame.

I wouldn't qualify it as 'lame' - even if it could have been expressed 
on a slightly less controversial tone !-)

>  Python 
> supports default arguments; something that is new to me.

Then prepare for quite a lot of new things...

>  How could lint 
> possibly know the correct number of arguments passed to it?  Unless, of 
> course, lint knew which functions had default arguments or not.

import inspect
inspect.getargspecs(func)


Python is incredibly strong at introspection - even if that doesn't 
solve the kind of "problems" one can possibly have with dynamic typing, 
and yes, dynamism (and not only applied to typing) has its own share of 
drawbacks, like the one you evoked (almost no compile time checking 
except for syntax) and quite a few others. Like any other design 
choices, it's a trade-off. You lose a bit here, and possibly (depending 
on the kind of application and how your neurons are connected) win quite 
a lot there.

 From a very pragmatic POV (and Python is mostly a pragmatic language), 
Python is pretty good at getting out of the way while you get the job 
done - which is perhaps why more and more 'major companies' are using 
it. The "downside" is that you lose in (perceived ?) "security" what you 
gain in freedom and flexibility. Some like it, some just can't get used 
to it, and there's no judgement call involved - it's just a matter of 
what better fits your own brain.

wrt/ your question, it's indeed a fact that Python (like any other 
dynamic language FWIW) can't catch this class of errors at compile time. 
So the question 'how do I avoid this kind of error' is mostly sensible.

OTHO, not even Ada would catch the following :
  foo(userid, password, host)
at compile time - unless you define specific distinct types for each 
argument, which might be a bit overkill (well, IMHO at least - YMMV !-).

IOW :  you *do* have to test, whatever the language and type system.

Practically and most of the time, given Python's very quick edit/run 
cycle, you don't even have to write unit tests to catch this kind of 
silly errors - my experience at least. But having unit tests is still 
the best way to ensure you didn't break anything with your last edit. 
While unit testing is not a panacea neither (hint: there's no silver 
bullet), it's really an invaluable tool.


> I'll come back with more intelligent questions after I've actually 
> learned some Python.

You can even ask "not that intelligent" questions while learning - in 
the worst case, you'll have no anwer at all, but most probably you'll at 
least have a short answer with a link to the relevant documentation.

Welcome onboard !-)