Thoughts on using isinstance

[Bruno Desthuilliers]

Matthew Woodcraft a écrit :

I certainly agree that the description of the function's requirements on
its parameters is best placed in the docstring.

This is another place where the "don't validate, just try running the
code anyway" approach can cause problems: what should you put in the
docstring?

I don't think anyone would like to be fully explicit about the
requirements: you'd end up having to write things like "A string, or at
least anything that's iterable and hashable and whose elements are
single character strings, or at least objects which have an upper()
method which ...".

So in practice you end up writing "a string", and leave the rest of the
'contract' implicit.

Python's doc (and third-part modules too) are full of 'string-like',
'dict-like', 'file-like' etc...

But that can lead to difficulties if people working
on the code have different ideas of what that implicit contract is -- is
it "a string, or anything else which works with the current
implementation", or perhaps "you may pass something other than a string
so long as you take responsibility for making it support all the
necessary operations, even if the implementation changes", or is there
some project-wide convention about how much like a string such things
have to be?
>
I think this kind of vagueness can work well within a lump of code which
is maintained as a piece, but it's good to divide up programs into
components with more carefully documented interfaces. And it's at that
level that I think doing explicit parameter validation can be helpful.

I'm afraid your strong ADA background shows up here... When I started
using Python some 7 years ago, I strongly believed in strong static
typing, and spent monthes fighting against the language.

And ?

Which is quite explicit

And what's the problem ? You have a full traceback, and since you know
which code is yours and which is not, it's usually quite easy to spot
where you passed something wrong.

I'm not sure that you intended that as a serious question,

Deadly serious.

but I'll
answer it anyway.

In an ideal world, the stack backtrace is there to help me work with
code that I'm maintaining. It isn't there to help me grub around in the
source of someone else's code which is giving me an unhelpful error
message. Just as, in an ideal world, I should be able to determine how
to correctly use someone else's code by reading its documentation rather
than its source.

The backtrace is here to help understanding what went wrong, and it's
usually quite good at it. And remember that Python has an interactive
interpreter that let you try out how a module works - which is usually
enough.

I think this is a 'quality of implementation' issue. When you start
using Python you pretty rapidly pick up the idea that a message like
'len() of unsized object' from (say) a standard library function
probably just means that you didn't pass the value you intended to; but
that doesn't mean it's a good error message. These things do add up to
make the daily business of programming less efficient.

Strange enough, we see quite a few experimented C/C++/Java programmers
explaining how much Python (or Ruby FWIW) improved their productivity...

I don't see that either of those things remove the issues I described.



Right. But using Python there is a position between 'writing layers and
layers of adapters and wrappers' and 'never validate anything': put
explicit checks in particular functions where they're likely to do most
good.

Did I say otherwise ? Now the question is "where will explicit checks do
most good ?" !-)

For example, it's often helpful to explicitly validate if you're going

.... to use data coming from the outside world.

I disagree. What C or C++ will do, very often, is produce a segmentation
fault.

If that's all you get, then lucky you. What's funny with UBs is that
they are, well, undefined !-)

That may well turn out to be hard to debug, but it's considerably
more likely to be detected early than a successful exit status with
incorrect output.

Don't you test your programs ?

 

[Terry Hancock]

abcd a écrit :



Yes - unless you have a *very* compelling reason to do otherwise.

Some compelling reasons:

1) Some action of the function is irreversible (for example, deletion of
data)

2) The function will get many wrong parameters in normal use, and the
function's action is expensive (disk accesses, re-writing flash memory,
fetching things from remote servers, whatever)

3) The inputs are from a web form or other insecure source, and you
want to reduce the number of unexpected cases you have to deal with.
(proof against error is not the same as proof against deliberate malice)

4) The function DOESN'T fail with a certain wrong parameter, but instead
does something it shouldn't. Catch the failing case and deal with it, or
if there are many, insist on the successful case.

Even when you do have to validate, it usually promotes flexibility of
the code to check for functionality (e.g. presence of necessary methods)
rather than specific inheritence.

Using "isinstance" is one of those practices that can really help in
quick testbed code or in a prototype, but you usually want to take it
out later.

Cheers,
Terry

 

[Dennis Lee Bieber]

I'm afraid your strong ADA background shows up here... When I started

What does the American Dental Association (or the Americans with
Disabilities Act) have to do with programming? <G> The purists on that
side emphasize it is a /name/: Ada <G>
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/