[Tutor] recursive problem

[Roelof Wobben]

----------------------------------------
> From: rwobben at hotmail.com
> To: wprins at gmail.com
> Subject: RE: [Tutor] recursive problem
> Date: Sat, 11 Sep 2010 18:05:12 +0000
>
>
>
>
> ________________________________
>> Date: Sat, 11 Sep 2010 19:01:39 +0100
>> Subject: Re: [Tutor] recursive problem
>> From: wprins at gmail.com
>> To: rabidpoobear at gmail.com
>> CC: rwobben at hotmail.com; tutor at python.org
>>
>>
>> That's the whole point! You don't WANT to know what type it is. You
>> want to just use it how you want, an if it behaves properly, who cares
>> what type it is?
>>
>> See when you type check you are forcing the user to use those types.
>> What if they want to derive a subclass from list? Is there really a
>> reason why you should prevent them from using that subclass with your
>> function?
>> If there is a valid reason, type checking is fine. But if there isn't,
>> type checking is just making your code more inflexible.
>>
>>
>> Well, I would submit that if were going to do type checking in such a
>> context you'd probably check for a base class, so deriving a subclass
>> wouldn't break entirely. Your point still stands however, we don't
>> even want to require from users to derive from class list. We'd be
>> quite happy to work with any object that "walks like a list" and
>> "quacks like a list", that's the beauty of duck typing...
>>
>> I guess the question to ask/consider is: How can be establish whether a
>> particular object supports a particular interface/set of behaviours
>> that we require? E.g. how do we most pythonically check whether some
>> object "walks like a list" and "quacks like a list" without tying such
>> code to explicit type checking?
>>
>> Walter
>
> Exactly what I mean.
>
> With the knowlegde I have from the few chapters of thinking like a computer scientist I don't know the answer to the last question.
>
>
> Roelof
>
>