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

[Bruno Desthuilliers]

Joel Hedlund wrote:
>> 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!

The first thing I tried to do when I discovered Python (coming from
statically typed langages) was to try to forcefit it into static typing.
Then I realized that there was a whole lot of non-trivial Python apps
and libs that did just work, which made me think about the real
usefulness of static typing. Which is mainly optimisation hints for the
machine. As you probably noticed, declarative static typing imposes much
boilerplate and somewhat arbitrary restrictions, and I still wait for a
proof that it leads to more robust programs - FWIW, MVHO is that it
usually leads to more complex - hence potentially less robust - code.

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

As long as your code is correctly documented, yes. All attempts to write
idiot-proof librairy code as failed so far AFAICT, so just let idiots
suffer from their idiocy and focus on providing good tools to normal
programmers. My own philosophie of course...

> I can dig that. :-)
> 
> Hmmm... So. I should build grimly paranoid parsers for external data,

Most of the time, you'll find they already exists. FormEncode is not
just for html forms - it's a general, powerful and flexible (but alas
very badly documented) bidirectional data converter/validator.

> use duck-typed interfaces everywhere on the inside,

Talking about interfaces, you may want to have a look at PyProtocols
(PEAK) and Zope3 Interfaces.

> and simply callously
> disregard developers who are disinclined to read documentation? 

As long as you provide a usable documentation, misuse of your code is
not your problem anymore (unless of course you're the one misusing it !-).

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

Then you probably want to read the relevant chapter in DiveIntoPython.

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