Passing objects to a function

Holger Türk htx1 at gmx.de
Mon May 10 17:55:51 EDT 2004



bruno modulix wrote:
> Holger Türk a écrit :
> (snip)
> 
>>
>> This could be supported by an assert statement:
>>
>> def BlackJackValue(hand):
>>     """BlackJackValue(Hand_instance) -> int\n\nReturn an integer, which
>> is the value of the Hand according to the rules of BlackJack."""
>>
>>     assert isinstance (hand, Hand)
>>
>>     [...]
>>
>> The method will throw an AssertionError if hand is not
>> an instance of Hand. Assertions can be turned off later for
>> performance reasons; with -O I guess.
> 
> 
> Note that this is also highly unpythonic since you won't be able to pass 

Unpythonic? That's a matter of taste. So: maybe.

> objects that implements the Hand interface but do not subclass Hand. 
> This may not be a problem in this specific case, but this probably 
> should not be recommanded in the general case unless there is a very 
> compelling reason to do so...

The assert statement, as it is used in the example above, describes
the assumptions the programmer had in mind when writing the function
it is written in. In addition, the expression happens to be understood
by the interpreter, too. So the assumption can be checked. It's a pity
documentation cannot be generated therefrom.

Programs are not written into stone. When the need arises, the assert
statement can be modified, e.g. to check an interface
(hasattr (hand, containsCard), or something else), or even removed.

Because documentation regularly turns out to be neglected and assert
statements are easily written, it's recommended to use them unless
there is a good reason to drop them.

In this special case, Thomas clearly wanted to express that the
parameter hand should be an instance of Hand. So why shouldn't it
be documented and checked this way?

Greetings,

Holger




More information about the Python-list mailing list