Python style: to check or not to check args and data members

[Bruno Desthuilliers]

Joel Hedlund wrote:
>> Short answer: Use Traits. Don't invent your own mini-Traits.
> 
> Thanks for a quick and informative answer! I'll be sure to read up on
> the subject. (And also: thanks Bruno for your contributions!)
> 
>> Types are very frequently exactly the wrong thing you want to check for.
> 
> I see what you mean. Allowing several data types may generate unwanted
> side effects (integer division when expecting real division, for example).
> 
> I understand that Traits can do value checking which is superior to what
> I presented, and that they can help me move validation away from
> functional code, which is always desirable. But there is still the
> problem of setting an approprate level of validation.
> 
> Should I validate data members only? This is quite easily done using
> Traits or some other technique and keeps validation bloat localized in
> the code. This is in line with the DRY principle and makes for smooth
> extensibility, but the tracebacks will be less useful.
> 
> Or should I go the whole way and validate at every turn (all data
> members, every arg in every method, ...)? This makes for very secure

...and inflexible...

> code and very useful tracebacks, but does not feel very DRY to me... Are
> the benefits worth the costs? Do I build myself a fortress of
> unmaintainability this way? Will people laugh at my modules?

I'm not sure that trying to fight against the language is a sound
approach, whatever the language. If dynamic typing gives you the creep,
then use a statically typed language - possibly with type-inference to
keep as much genericity as possible.

> Or taken to the other extreme: Should I simply duck-type everything, and
> only focus my validation efforts to external data (from users, external
> applications and other forces of evil). 

IMHO and according to my experience : 99% yes (there are few corner
cases where it makes sens to ensure args correctness - which may or not
imply type-checking). Packages like FormEncode are great for data
conversion/validation. Once you have trusted data, the only possible
problem is within your code.

> This solution makes for
> extremely clean code, but the thought of potential silent data
> corruption makes me more than a little queasy.

I've rarely encoutered "silent" data corruption with Python - FWIW, I
once had such a problem, but with a lower-level statically typed
language (integer overflow), and I was a very newbie programmer by that
time. Usually, one *very quickly* notices when something goes wrong. Now
if you're really serious, unit tests is the way to go - they can check
for much more than just types.

My 2 cents.
-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"