Is isinstance always "considered harmful"?

[Bengt Richter]

On Sun, 15 May 2005 14:31:21 -0400, "Terry Reedy" <tjreedy at udel.edu> wrote:

>
>"Jordan Rastrick" <jrastrick at student.usyd.edu.au> wrote in message 
>news:1116157672.683839.49700 at o13g2000cwo.googlegroups.com...
>
>> I've read arguments, here and elsewhere, to the effect that in Python
>> isinstance should be avoided like the plague, except in a few very
>> specific and narrow circumstances.
>
>Putting it like this is rather extreme.
>
>> Roughly speaking, due in part to
>> Python's dynamic nature its better to concern yourself only with the
>> interface an object provides, and not whether it happens to inherit
>> from a given base class.
>
>To my mind, your example of using isinstance to select a better (such as 
>speedier) subalgorithm for a special case is not just fine, but good 
>programming.  (Selecting a subalgorithm that works more robustly is also a 
>good reason for special casing.)  It is an internal matter whose externally 
>visible effect is to improve performance.
I agree, but I am also a little uncomfortable about such performance tuning,
unless the assumptions it depends on are prominently documented or even
validated with an assert or explicit warning. Otherwise the next version
of the interpreter or a library module could change the optimal decision,
and a bad optimization decision could be locked in for the new version.

Maybe there should be another testable condition like __debug__ except for
testing (e.g. __testing__ ;-) which could be used to introduce temporary
alternative code (such as alternate optimization decisions) so that system
tests could be used to validate locking in one decision or another for a
new system version being tested.

For trivial personally maintained code, a one-line version check with a
reminder exception to re-visit the optimization or whatever decision
(and revise the version check for next time) could cheaply prevent hidden
lock-in of bad optimization etc.

>
>Using isinstance to unnecessarily narrow the domain is quite different.  It 
>has the externally visible effect of degrading performance (to a nullity) 
>for arguments that the user might reasonably want to work.
Agreed, but the key thing there is to define "unnecessarily" ;-)

Regards,
Bengt Richter