asserting types

[Alex Martelli]

"Paul Prescod" <paulp at ActiveState.com> wrote in message
news:mailman.987815312.13601.python-list at python.org...
> Mick wrote:
> >
> > What is the cleanest way to assert a class type?  for example if one has
a

assert isinstance(obj,cls)

or

assert issubclass(cls,super)

depending on what you mean (a class object, or an instance object?).  But
as everybody's observing, they're normally best not used.


> > function that uses a particular class object then what is the nicest way
to
> > assert within the function that the class is of the correct type?  I
assume
> > this is simple, so I guess more the question is this the wrong way to
think?
> > should I be trying to organise things in a different way so as to
generate
> > "compile" time errors?
>
> It is generally considered bad form to try to assert a particular class.
> In Python it is more profitable to presume that the users of your module
> know what they are doing. If they give you a class that is not a
> subclass of yours, they may do it for a good reason (i.e. it is a
> C-module for speed, or it is an object from another module that
> implements the right interface).

Right!  See for example

http://www.activestate.com/ASPN/Python/Cookbook/Recipe/52295

for a nice useful idiom that gets destroyed if client code uses such
assertions -- and a resulting impassioned plea not to use typetests:-).


> If you want to do a sanity check, the best thing is to check that the
> methods you expect to be available are available. Even just one or two
> suffices as a sanity check. If they implement those one or two but not
> other important ones then again, they may feel that they know what they
> are doing (i.e. a particular code path is known not to call the other
> methods) and you should just trust them.

Generally, just trying all the operations you need is OK -- your code
may or may not need to trap exeptions that may result (it may leave
that task to the caller).  Sometimes you do need to make sure that
certain state alterations are not *partially* performed -- if some of
them are done, all must be; being passed an object that hase some
but not all of the needed methods may then be pernicious.  If the
state being altered is under your control, you might save a state
portion, do the work in a try/except, restore the state saved if the
operation didn't fully work out.  Problem is stickier when state is
being altered in objects you don't fully control, so saving/restoring
state is not an option.

For those cases, only, accurate checking may be worthwhile, but
even then it's rarely going to be a type-check (only, perhaps, as
a simpler and known to be inaccurate stand-in for checking what
you really need to know; you could for example use it for a first
'fast-path' check -- "if the object isinstance of X I'm surely fine,
else let's check if it does have what I really specifically need").

http://www.activestate.com/ASPN/Python/Cookbook/Recipe/52291
gives an example of "accurate checking" -- the discussion there
needs to be expanded, but even as it stands it may help put
things in this perspective.


Alex