lint for Python?
bdesth.quelquechose at free.quelquepart.fr
Mon Oct 6 23:16:49 CEST 2008
Pat a écrit :
> Bruno Desthuilliers wrote:
>> Pat a écrit :
>>> 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 !-)
> 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.
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 !-)
More information about the Python-list