Passing objects to a function

[bruno modulix]

Holger Türk a écrit :
> 
> 
> 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.

We can discuss the point... But to summarize what I have in mind : 
testing for a *specific* type is fighting against the very dynamic 
nature of Python instead of taking advantage of it (IMHO etc...)

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

Not being psychic, I can't say what the programmer actually had in mind 
when writing this specific piece of code !-) But whatever, the fact is 
that the code needs a 'Hand-like' object, not a 'Hand' object. The 
important word here is 'like'.

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

But this require source-code modification.

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

it's as easy to write :
def BlackJackValue(hand):
    """expects a Hand-like object"""
   [...]

Because assert (or any other type-specific check) prevents from using 
the same code with object of other types supporting the same protocol, 
it's recommended to *not* use'em that way unless there is a *compelling* 
reason to do so.

> In this special case, Thomas clearly wanted to express that the
> parameter hand should be an instance of Hand.

Whatever he 'clearly' wanted to express, what he *needs* to express is 
that the parameter 'hand' should be an instance of any object responding 
to the messages that will be send to it. And the good news is that there 
is no need to explicitely check for this, as if the object fails to do 
so, an AttributeError will be raised.

> So why shouldn't it
> be documented and checked this way?

See above.

> Greetings,
> 
> Holger
> 
Peace
Bruno
-- 
bruno - modulix
onurb ta xiludom tod gro
--