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

Joel Hedlund yohell at ifm.liu.se
Fri Sep 1 06:24:43 EDT 2006


> I'm not sure that trying to fight against the language is a sound
> approach, whatever the language. 

That's the very reason I posted in the first place. I feel like I'm fighting 
the language, and since python at least to me seems to be so well thought 
out in all other aspects, the most obvious conclusion must be that I'm 
thinking about this the wrong way. And that's why I need your input!

>> > 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.

That approach is quite in line with the "blame yourself" methodology, which 
seems to work in most other circumstances. Sort of like, developers who feed 
bad data into my code have only themselves to blame! I can dig that. :-)

Hmmm... So. I should build grimly paranoid parsers for external data, use 
duck-typed interfaces everywhere on the inside, and simply callously 
disregard developers who are disinclined to read documentation? I could do that.

 > if you're really serious, unit tests is the way to go - they can check
 > for much more than just types.

Yes, I'm very much serious indeed. But I haven't done any unit testing. I'll 
have to check into that. Thanks!

> My 2 cents.

Thankfully recieved and collecting interest as we speak.

Cheers!
/Joel



More information about the Python-list mailing list