"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4