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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
